3
$\begingroup$

In order to use AES256 encryption, we will need a 256 bit key, and 128 bit iv. We will need some kind of salt and hashing function to convert a password to the desired key.

However, let's assume the password is automatically generated for every file anyway. This means that we can theoretically skip the salt and hash (e.g. pbkdf2), and just generate a random 256 bit key and 128 bit iv. Is there any security implication which might be generated from this?

$\endgroup$
  • 3
    $\begingroup$ I'm slightly confused about what your question is. The salting and hashing is for converting a human generated password into an AES key. What you have described is generating a random key for AES, which is normal and more secure. $\endgroup$ – Ninja_Coder Jul 24 '17 at 1:12
  • $\begingroup$ i would offer that the hash and salt won't hurt, but unless there's a flaw in your random (which is possible), it won't help either. $\endgroup$ – dandavis Jul 24 '17 at 4:54
  • $\begingroup$ No need for salt or hash. Just be sure to use a CSPRNG as opposed to a PRNG. $\endgroup$ – hunter Jul 24 '17 at 8:08
  • $\begingroup$ @Ninja_Coder exactly, that's what I thought as well, just wanted to make sure I am not missing anything here. $\endgroup$ – Rowanto Jul 24 '17 at 8:09
  • $\begingroup$ @dandavis I am not sure about not hurting part. Doing unnecessary stuff might risk it to become less secure. $\endgroup$ – Rowanto Jul 24 '17 at 8:13
4
$\begingroup$

We know that you can't invert the AES encryption to determine it's key at present. So you're fine there, as long as you are able to generate all 256 bits in the uniformly distributed way. Any decent random number generator will be able to do this as long as it can be seeded correctly. If there is some mathematical relationship between the files (you derive from) and the key, you'll need to make sure that the file entropy fits into the random number generators state space. This can be a little tricky sometimes, and there are examples like the seeding mechanism of RC4 that's quite poor and can lead to /induce weak states. This then has a detrimental effect on the generator's output. Similarly, correctly seeding a large state generator like the Mersenne Twister is difficult. This is all however an implementation issue.

One security issue lies with the IV. This is stored in plain form. In order to maintain security, the IV must be generated from a cryptographically secure generator. Otherwise it might be quite simple to determine an insecure generator's state and thereby predict all IVs. Since you need a CSRNG for the IV, you might as well use the same generator for the 256 bit key. The same issue of correct seeding still remains however.

The other issue is if you transmit the same file repeatedly. The purpose of the IV is to make sure that the cipher text is unique per transmission, even if the plain text is the same. If the IV /key pair are directly (and only) related to the encrypted file contents, the cipher text will always be identical. This may not be an issue for disk storage, but can be for copying /transmission as it leaks some information.

My sense would be to have some form of salt anyway. Without it, the system feels very predictable as all the information is there in hard coded form. Something that only you know would improve the security.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.