0
$\begingroup$

I am encrypting a DEK (data encryption key) with a KEK (key encryption key). The KEK is generated from a password using scrypt with default parameters and a 32 byte randomly generated salt. The encryption algorithm is AES-GCM.

What are the implications for the IV in this case? Let's assume that the IV is initialized to 0 (96 bits of 0s). If I re-use an IV with a key then this is bad news. Since the key is generated from the password it will always be the same. But I do generate a random 32 byte salt each time I re-encrypt the file which should provide a different key each time. I would assume that a 32 byte salt would change the KEK significantly so that the zero initialized IV would not pose an issue for GCM. Is this a valid assumption?

Improve this question
$\endgroup$
4
  • 2
    $\begingroup$ Yes, you are right. And don't forget to pass the salt used at encryption along with the ciphertext, otherwise you won't be able to derive the key from the password for decryption, later. $\endgroup$
    – Lery
    Jun 6, 2017 at 18:03
  • $\begingroup$ @Lery thanks! I am already saving the salt together with the ciphertext so the file can be decrypted later. I was worried about the IV because I am currently not changing it. Is there a security risk for relaying only on the salt to change the encryption key? $\endgroup$
    – Stan Ivanov
    Jun 6, 2017 at 21:42
  • 3
    $\begingroup$ No, the salt will significantly alter the outcome of scrypt. If anything you should look if you can tweak the work factor of scrypt to be as high as workable. And with anything password related, a strong password is still required. A 32 byte salt is - by the way - rather overkill; 16 bytes should be plenty (then again, it doesn't hurt much either, so...). $\endgroup$
    – Maarten Bodewes ♦
    Jun 6, 2017 at 22:07
  • $\begingroup$ @MaartenBodewes thanks for confirming my gut feeling! You make a good point. I will lower the salt size to 16 bytes. $\endgroup$
    – Stan Ivanov
    Jun 7, 2017 at 15:21

1 Answer 1

Reset to default
1
$\begingroup$

If you use the key only once, then there is no danger of reusing a nonce with the same key because you're not even reusing the key!

A collision in the salt and password would lead to the same key, but though the probability of such a collision may be nonzero, it is nevertheless negligible for a 32-byte salt—unless, of course, you roll back your VM state and get the same initial RNG state, or equivalent.

Do make sure to use AES-256, by the way, and not AES-128, if you want a 128-bit security level.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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