Packetizer Forums

There seem to be 2 flaws in design. First I don't know why the encrypted key needs to be placed in the encrypted file as well. Like TrueCrypt that never stores a hash of password or the encrypted key.

Secondly, key is randomly created can be a problem which means the key is not actually dependent on the password but the entropy of the system of that time which can be severely compromised and the Windows CryptoAPI is not even open source unlike dev/random, urandom in Linux. Can you explain it to me why you chose this particular design of AES Crypt. Thanks.

AES Crypt uses two different keys. One key is derived from the user's password (call that K-1). In order to perform the encryption, we also need an initialization vector (call it IV-1), a value that also needs to be randomly generated in order to improve security. We then generate a second key (K-2) and initialization vector (IV-2).

We take K-1 and IV-1 and use those to encrypt K-2 and IV-2. Those are stored in the file, which you have observed. Given a strong password (and coupled with the way in which we derive K-1), this should be well protected.

We then take K-2 and IV-2 and encrypt the file.

So, to be able to break AES Crypt, one needs to be able to get K-2 and IV-2. This should be virtually impossible unless there is a weakness in the random number generation. Likewise, breaking K-1 and K-2 in order to then decrypt the file should be virtually impossible, assuming one used a reasonably strong password. Since we use SHA-256 as a part of the K-1 derivation, one can easily argue that it also depends on the strength of SHA-256. We're not aware of any weaknesses in that algorithm, and certainly not aware of anything that can be observed from 8192 rounds of SHA-256.

In short, I see nothing insecure about storing K-2 and IV-2 in encrypted form in the file encrypted using another 256-bit key that is equally strong. If that key can be so easily obtained, then it should be equally as easy to decrypt the entire file had we used K-1 and IV-1. So, I think we can dismiss that as a flaw.

Now, to your point about the random number generator...

Encryption absolutely requires a strong random number generator (RNG). In that, there is no doubt. You are correct that many systems do not have enough entropy to generator too many random numbers, which is another reason why we hash the numbers we do get with SHA-256. The objective is to try to offset any weaknesses in the RNG by hashing the values with at least some numbers that are random, this avoiding the possibility that we have sequences of digits in the key of IV that are characteristic of a particular RNG implementation. We do assume that the operating system can generate some numbers that might be viewed as cryptographically strong, but we cannot introduce a better random number generator in software. The underlying operating system absolutely is the best place to generate and maintain entropy data. Thus, we rely on /dev/random and the Windows crypto APIs.

The biggest weakness in this approach, we believe, is that the RNG on a system could be compromised. Perhaps it generates a fixed, known sequence of integers. If it did that, then that would mean I could fairly easily determine IV-2 and K-2, the most important data that is securing the file. After all, if I knew the sequence in which numbers would be generated, then I would know exactly what the values for K-2 and IV-2 are. I would not need to know K-1 or IV-1.

The issue here, though, is that this weakness is the result of the system being compromised. If somebody has a system that has been compromised, then absolutely no security software is going to protect you. You may have a stealth random number generator and and use a perfectly random 256-bit key. But, all I would need to do is get access to your key. I could do that by logging your keystrokes or even reading through memory of an executing program.

So, while we do not rely on Microsoft or other third parties to perform the encryption function, we do rely on the operating system to be a source of random numbers. You may classify that as a weakness and I wish we had a better source of random numbers, too. But the fact remains that if the operating system cannot be trusted to provide random numbers, then it cannot be trusted, period. There is nothing we can do to address a system that has been compromised and that's really the only concern I have with the approach we take.

Yes that seemed to bother me a bit! Master key should be dependent somehow on the password. Maybe instead of using SHA-256 you can use SHA-512 derived from password and random salt (8192 times ofcourse) and cut the 512 bit output into 2 256 bit keys K-1 and K-2 in future designs maybe! That way the master key K-2 is dependent on the password and even if the OS RNG is flawed or doesn't have enough entropy (like mobiles or servers), we still can add entropy from the password...

PS: I am making a software just for fun that uses two hash algorithms SHA-512 and Whirlpool. The hashes are then XORed to each other to produce K-1 and K-2! Will that compromise security?

Getting access to the master key (K-2) is dependent on the password (and, thus, K-1). If one were to somehow guess at K-2 should not bother you. The fact that K-2 is used to encrypt the file does not compromise security, assuming one has a secure system with a reasonably good RNG; there's simply no way to guess at K-2. Given that most users do not use strong passwords, K-2 is definitely the more secure key. With a strong password, K-2 is equally strong. It's perhaps worth noting that AES Crypt was not the first encryption tool to use this approach. As one example, PGP did the same thing:
http://en.wikipedia.org/wiki/Pretty_Goo ... dentiality

PGP use a public/private key pair as a "K-1" where we use a symmetric key K-1. However, PGP's "session key" is more-or-less the same as AES Crypt's K-2. In both PGP and AES Crypt, "K-2" is encrypted using "K-1".

With your use of hashing functions (SHA-512 and Whirlpool) to create a key, you should be mindful of the fact that hashing functions are not encryption functions. They just take input and create something that looks random. However, the output of a hash function is definitely not random. Given random input, though, the output random. Given predictable input, the output is predictable. So, you can certainly use the hashing functions as you propose to generate a K-1 or K-2, but the input to those functions needs to be random.