Information about encryption

[tamula]

Hi guys,

sorry, if this is already answered somewhere else, I didn't found it. I just found this website (https://www.aescrypt.com/aes_file_format.html). I'm looking for some infos especially regarding the C# implementation.

- What is the key size?
- Can you change the key size? (I guess not, since its not in the file format)
- How are the IV's generated?
- Why is the second IV (to encrpyt the message) encrypted and not stored in plaintext?

Thanks for your help!

[paulej]

The key size is fixed at 256 bits.
Key size can't be charged, and 256 bits is the largest key size supported by AES.
I didn't write the C# code, but the C code generates the IVs from random data. These must be random, so I trust they are.
The second IV is encrypted only because I designed the file format that way. It doesn't have to be encrypted, but it never hurts to hide information.

[tamula]

looks like its done by time and MAC adress:
https://github.com/kenkendk/sharpaescry ... pt.cs#L616

OMG....

edit: generation of IV2 looks better: https://github.com/kenkendk/sharpaescry ... pt.cs#L681
m_crypt.GenerateIV(); sounds like a CSPRNG...

[paulej]

What the author appears to be doing is using the Mac along with the current time, the producing a hash (which I assume is SHA-256, but I didn't check). If that's the case, then there would be fairly random values.

I think that's OK. The IV needs to be random, but it's also not a secret value. Be mindful of the purpose for the IV. It's purpose is to "scramble" the first plaintext block. It would already get scrambled by AES, but XORing the plaintext with the random IV ensures that, encrypting the same file over and over using the same key will not produce the same ciphertext.

Why is that important? Well, suppose you always use the same password (and, thus, key) to encrypt a file over and over. AES will always produce random output, but if the IV is constant and the key is constant, the ciphertext is constant. With that, I could start to figure out some information when I see a few samples. Throwing in a random IV prevents an attacker from seeing such patterns.

So as long as the function to which you referred is always producing different output on every call, that's OK. Hash functions are often used as pseudo random number generators.

[tamula]

Thanks for your reply. Since the MAC is fixed and deosn't change, the IV1 is generated by hashing the time. So if you encrypt more than one file a second you are reusing that IV1...
It seems pretty weird to me to use the correct implementation for IV2 (although hashing is not needed I guess), but to implement the IV1 on your own.
In practice this doesn't matter I guess, because IV1 is used for random data (random IV2 + random key2), so the ciphertext will be unique...

another theoretical quesiton: would it be safe to just hash a counter for the IV? Like this it will be unique, and "randomness" is done by the hash algorithm?

[paulej]

Since windows ticks are in units of 100 nanoseconds, it would have to be two encryption operations with the same key at literally the same time. I'll venture to guess that's not going to happen on the same machine. It could, but chances are close to zero.

The time field is 8 bytes. The MAC is 6 bytes. So, there is still room to throw in a random value to increase the probability that the IV is unique. But, I think it might be worth trying to call that ticks() call twice and get the same value. I bet you won't. I'm sure the author took that into consideration.

If you hashed a counter, yes it would be safe. However, that requires a lot of state and possible conflict with parallel processes. You don't want two processes using the same value.

Seriously, I'd explore that ticks call to see if it's even possible to get the same tick value when called consecutively or with two process running in parallel.

[Tentos]

Hello,

A question similar to tamula's was asked on the Duplicati mailing list:
https://groups.google.com/forum/#!topic ... HZsPgrKgaA

The programmer of SharpAESCrypt (kendendk, aka Kenneth Skovhede) is one of the developers of Duplicati, where SharpAESCrypt is used to encrypt the backup files. Long story short: this implementation also uses (pseudo-)random bits to derive the IV1. In fact, the return statement of GenerateIv1() calls the function DigestRandomBytes(iv, 256) where the additional randomness is added:
https://github.com/kenkendk/sharpaescry ... pt.cs#L644

The Java implementation seems to do the same.

By the way, I was also curious and sent an e-mail to kenendk, and he kindly wrote me a short answer. Good work!