Also, where do I store my salt (can I just store it at the beginning of the encrypted file)?
$\begingroup$
$\endgroup$
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
3
I suppose that what you are trying to do is password-based encryption of some data; you use PBKDF2 to derive the password into an encryption key, and then use the key with AES to encrypt the data. The AES encryption needs an IV, and the PBKDF2 function needs a salt. Both IV and salt should be generated anew for each encryption (even if reusing the same password).
Generically, the salt and the IV can be just encoded in a header for the encrypted file. They are not secret values.
Your question is then: can you use the same value for both the salt and the IV (presumably to save space) ? I do not recommend it. I would be surprised if it really induced a security issue, but who can be sure ? It looks a bit funky, and that's bad enough to avoid it. What you can do, instead, is to store the salt in the file header, and use PBKDF2 to generate both the key and the IV. Thus, the IV needs not be stored anywhere. PBKDF2 is a key derivation function which can produce an output of arbitrary length.
Generating the key and the IV from the same source is what is done in OpenSSL (in its private symmetric encryption format), and also in SSL/TLS (up to TLS 1.0).
I hope that your AES-based encryption mechanism uses a mode with integrated integrity checks, like EAX. Integrity is not an option; it is often overlooked, but it is necessary for security.
answered Nov 20, 2012 at 17:17
-
$\begingroup$ TLS 1.0 computed the IV in a way that was knowable by the attacker, and this led to a "CBCATT" (openssl.org/~bodo/tls-cbc.txt). TLS 1.1 switched to an explicit IV. I don't believe that this undermines the answer, though, but would like to confirm that. $\endgroup$ Commented Jan 22, 2014 at 15:41
-
1$\begingroup$ The problem with the IV in TLS 1.0 (demonstrated a few years ago "in the wild", i.e. as a Youtube video of a Javascript-based attack, under the name "BEAST") was not that the attacker knew the IV, but that the attacker knew the IV before choosing the data which gets encrypted (in a chosen-plaintext attack context). In TLS 1.1 a new IV is generated for each record, and it is in the record, so the attacker can see it all right, but only after having chosen the data, which disables the attack. $\endgroup$ Commented Jan 22, 2014 at 15:47
-
$\begingroup$ Totally agreed; I should have said "predictable by the attacker." I have a more detailed version of this question: crypto.stackexchange.com/questions/12943/… $\endgroup$ Commented Jan 22, 2014 at 15:49