Information about encryption

Discussion related to AES Crypt, the file encryption software for Windows, Linux, Mac, and Java.
Post Reply
tamula
Posts: 3
Joined: Wed Feb 11, 2015 12:30 pm

Information about encryption

Post by tamula » Wed Feb 11, 2015 12:38 pm

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!

User avatar
paulej
Posts: 521
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: Information about encryption

Post by paulej » Thu Feb 12, 2015 1:02 am

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
Posts: 3
Joined: Wed Feb 11, 2015 12:30 pm

Re: Information about encryption

Post by tamula » Thu Feb 12, 2015 10:16 am

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...

User avatar
paulej
Posts: 521
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: Information about encryption

Post by paulej » Thu Feb 12, 2015 12:23 pm

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
Posts: 3
Joined: Wed Feb 11, 2015 12:30 pm

Re: Information about encryption

Post by tamula » Thu Feb 12, 2015 1:09 pm

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?

User avatar
paulej
Posts: 521
Joined: Sun Aug 23, 2009 7:32 pm
Location: Research Triangle Park, NC, USA
Contact:

Re: Information about encryption

Post by paulej » Fri Feb 13, 2015 2:35 am

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
Posts: 1
Joined: Fri Feb 27, 2015 6:42 pm

Re: Information about encryption

Post by Tentos » Fri Feb 27, 2015 6:56 pm

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! :)

Post Reply