how strong encrypted archives are ?

[gkweb]

I will try to draw what i understood from the help :

Key generation :
----------------------

user passphrase (UPP)
|
|
SHA256, MD5 and HAVAL256
(over 260 000 rounds operations)
(random bit taken from UPP flipped every 5000)
/ \
/ \
1 RinjDael secret key 1 Twofish secret key
(256 bits) (256 bits)


=> Each time you encrypt a file with your _same_ passphrase, ciphers keys used to encrypt data are always different or always the same ?
I think it's always the same if we want to be able to decrypt data, but since the IV's are always different it's like having different secret key each time ?



CSE archive format :
--------------------------

FILE BEGINING
------------------------------------------ offset = 0
| *Clear Header* |
| IV (RinjDael) IV (Twofish) |
| |
-------------------------------------------
| *Encrypted Main Header* |
| "file offset table" information |
| 2 IV to decrypt "file offset table"|
| number of archive's files |
| random data |
| |
-------------------------------------------
| *Encrypted files data* |
|compressed & encrypted Chunks |
| |
-------------------------------------------
| *File offset table* |
| ALL files informations |
|files offset in [Encrypted files data]|
| |
---------------------------------------------
END OF FILE



Encryption Process ([Encrypted files data] CSE archive area) :
-------------------------------------------------------------------------------

Data (files)
|
|
|

Archive
([Encrypted files data])
|
|
CHUNK (1MB)
-----------------------------------------------------
| [File Block Header IV for rijndael] |
-----------------------------------------------------
| [File Block Header IV for twofish] |
-----------------------------------------------------
| [File Data IV for rijndael] |
-----------------------------------------------------
| [File Data IV for twofish] |
-----------------------------------------------------
| [Encrypted File Block] |
| original plaindata chunk information: |
| - checksum (SHA256) |
| - original size |
| - compressed size |
------------------------------------------------------
| [Encrypted File Data] |
------------------------------------------------------
|
CHUNK (1MB)
|
CHUNK (1MB)
|
[...]



so a quick overview could be :




-------------------------------------- offset = 0
| *Clear Header* |
---------------------------------------
| *Encrypted Main Header* |
---------------------------------------
| *Encrypted files data* |
| Chunks |
| Chunks |
| Chunks |
| Chunks |
| Chunks |
| Chunks |
| Chunks |
| Chunks |
| Chunks |
| Chunks |
| Chunks |
| Chunks |
| Chunks |
| Chunks |
| Chunks |
-----------------------------------
| *File offset table* |
----------------------------------











Archives encryption strenght seems _very_ high.
Even if i'm not a cryptographic expert, i can see that with _one_ password (provided by the user), two key are generated and used with random seed each.
Combined, this lead that the same keys encrypting same data twice will not render the same encrypted form.
So an attacker collecting a lot of encrypted data to help him to guess the secret key won't help him.

Moreover, into the same archive, a same kind of data of a particular file will never be encrypted in the same manner in the next chunk, since random characters are used.

So, at worst, if an attacker knows the protocol (like the CS software itself) he will still be blocked by the well know strong encryption algorithm RinjDael and Twofish, and the randomness of the chunk's encryption dramatically prevents
easy cryptanalyses methods, so the brute force is the last "chance" for the attacker, let say him all together good luck for calculating 2^256 (+/x ?) 2^256 combination !


Please correct me i made mistakes !
i'm sure to have made some ;)

[Wayne - DiamondCS]

gkweb, it's nearly midnight here in Perth so unfortunately I don't have time to look for any possible errors as you requested as I'm about to clock off, but I must say that it's very refreshing to see such a post! I commend you for putting in the time and effort to do some research -- as you can now see for yourself Cryptosuite is extremely strong (we needed an export license from the Department of Defence of Australia before we were able to release it, due to international crypto laws), and we're more than happy to discuss its strengths in full detail (... just not at midnight ... :))
Either myself or Jason will get back to you within the next 12 or so hours, actually Jason might even post here before he retires for the evening

Best regards,
Wayne

[Gavin - DiamondCS]

I too am impressed to see such effort ! bravo :)

[gkweb]

thanks you :)

In fact this post has a double purpose : first to see if i understood well, and second (when it will be corrected) to help anyone to understand better the protocol (including me), i think a draw explains more than words.
In addition, from what i read in the help file, i'm amazed to see a so strong protocol, so let's show it to the world ;)
(i already used those algorithm in personal programs, but i never used a so sophisticated protocol, and never see one too).

The last hidden purpose is to train my cryptographic related english a little ;)

But eh, you aren't sleeping yet ? how do you want to improve your software if you don't sleep sometimes ? i know you already sleeps one time last week, but you need to sleep each day.
What ? you don't believe me :D

[Jason_R0]

Hi gkweb, as Wayne said, it is refreshing to see this post :) . I will explain it in an easier way than it is in the helpfile (I hope).

Each encryption that takes place first has one of the ciphers used on it, then the other. Every encryption has 2 IV's generated for it randomly, one for each cipher.

*edit* Also each time something is added/changed/removed from a CSE archive, all the headers are first filled with new random characters and new IV's generated each time.

**KEY GENERATION**
1. Passphrase given by user
2. Two seperate keys are generated from the passphrase, one for the RIJNDAEL cipher and one for the TWOFISH cipher. The passphrase is passed through a HAVAL256 or SHA256 checksum for 262144 rounds with one random bit based on passphrase being flipped every 5000+ rounds.
3. Two 256bit keys are now ready to be used for encryption/decryption


**CSE FORMAT**
CryptoSuite's archive format looks like the following.

[Clear Header] - Not encrypted, identifying it as a CSE archive, supplys 2 IV's for the next header
[Encrypted Main Header] - Contains the "file offset table" offset, size of that table, number of files, some random data, and 2 IV's for file offset table
[Encrypted File Data] - All the compressed and encrypted data for the files is stored here
[File Offset Table] - Stores actual "file information", file name, size, attributes, etc about each file in the archive, also contains the position in the [Encrypted File Data] section for each file.


**How encrypted file data is stored**
File data is read from the original plaintext file in "Chunks". Data is read from the file in 1MB(megabyte) chunks. If the file is smaller than 1MB the whole file is read. After the chunk has been filled with the data, it is compressed, any data which does not fall on a 32byte boundary is randomized to prevent attacks. This compressed data is then encrypted. This occurs until the end of the original plain file is reached. Each encrypted chunk has the following format below.


[File Block Header IV for rijndael]
[File Block Header IV for twofish]
[File Data IV for rijndael]
[File Data IV for twofish]
[Encrypted File Block] - Contains information about the original plaindata chunk, such as its checksum (SHA256), original size and compressed size
[Encrypted File Data] - A chunk of the file OR the whole file depending on its size, encrypted


And that is about it. :)

Feel free to ask any questions, I may have missed something it is a bit late. Thanks for the question.

*edit* Actually I have just explained it a bit better than the helpfile did with words. With the information I gave you could probably construct a slightly better drawing as you did. I might add what you gave to the helpfile. :)

-Jason-

[gkweb]

I think your post Jason is well detailed, more may than the help file.
I tried to convert it in a graphic form, but not easy :-\

I updated my first post.
Me too i will think about all of that tomorrow, i didn't sleep more than 3hours this night, i have difficulties now to use my brain :(

[Jason_R0]

gkweb, that is great. I will add what you have given there to the new version's helpfile with credit to you. IM me if you would prefer your real name or another alias used.

I will also update the helpfile with my posting here. Thanks gkweb.

-Jason-

[Q Section]

Greetings O Great Cypher Gurus!

We were going to ask if the keys were static or dynamic but we can see the answer from the above posts.

Now if we can figure out a way to defend against a WPA DDoS attack after the VPN has been breached!

Congratulations and best wishes!

[Peter2150]

My brain is strained at 2^256 bits trying understand some of the detail.

First what is an IV. My guess is its a seed based on the password used to get the final key for encryption.

I gather if I encrypt the same file twice, the result would be the same because the key's change. Is this correct.

Also am I correct in that the IV(??) is store in the archive, and the key is later derived from the password and IV.

Is my confusion/lack of understanding obvious???

[Jason_R0]

I.V = Initialization Vector

Basically an IV allows each encryption with the same key to be different. It is a "starting seed" of sorts that increases the security of symmetric encryption. Each IV in CryptoSuite is 100% generated randomly everytime an encryption occurs, which is the thorough and secure way of using IV's. The IV is not based on the passphrase and vice versa.

-Jason-