Packetizer Forums

I maintain an Mac/iOS AES library called RNCryptor (https://github.com/rnapier/RNCryptor). I'd been lamenting my need to create "yet another" encrypted file format, and one of my readers pointed to the AESCrypt format as a possible option. I was reviewing it, and had some concerns that I wanted to kick around.

The biggest concern is the custom KDF. PBKDF2, while perhaps not perfect, is well-vetted, analyzed, and standardized. Is there any analysis of the strength of the 8k hashing approach that you're using?

I'm also somewhat concerned with the key reuse between encryption and HMAC. My recommendation is to generate separate keys for these functions. Using PBKDF2, it is easy to generate two keys using different salts.

In general, this file format is growing on me and I'd like to investigate bringing it to iOS and Mac-native (i.e. using the built-in CommonCryptor functions). The RNCryptor page includes a list of my security design goals.

A couple of other notes:

* It would be useful if the file format documentation explained how the various fields are generated and what they mean. I had to crawl through the code to figure out what was actually happening (which I *assume* is what is intended to be happening). That said, it is very easy to read code.

* It would also be useful if the format could handle raw keys rather than a password. Passwords have a very compressed key space, so for machine-to-machine communication it is useful to use shared secret keys rather than passwords. (For similar reasons, it would be useful if the format could handle other key sizes; I know this is on the wish list).

I don't think an analysis (at least nothing published) has been done on the 8K hashing loop. In theory, that loop should not even be needed, because one would use a good password and have a good random number generator (RNG). These iterations exist only to help make the data look more random and should hide any weaknesses in the RNG.

As for the rest of the file format, there have been a few noted security issues, most are minor. Those are on the "wish list" page. The one that bothers me most is the fact that the file modulo octet at the end of the file is not included in the HMAC computation. It was supposed to be, but that's a bug. So, somebody could alter that bytes and cause the decryption logic to produce a file that is the wrong size. I think producing a "version 3" of the file format would be a good way to do that.

The file format is not dependent on use of passwords at all. That's just what is taken as input. One could certainly use this same file format and use a key file as the input, versus a password. That's another requested feature that I would personally like to have.

Another thing I would like to see in v3 is support for different key sizes. Presently, we use only a 256-bit key. I would like the format to indicate whether a 256-bit, 384-bit, 512-bit, etc. key is used.

We could work on adding those things, though the transition to a new file format at this point will be a bit painful and slow. AES Crypt has always maintained backward compatibility, even with version 0. I'd like to ensure we still do that.

So, any new file format we introduce, I would like it to have a minimal number of changes. There must be changes, of course, but I'd prefer nothing too radical.