2
$\begingroup$

I'm currently implementing, with crypto++, and AES tranmsission system, whose key is based on a previous MasterSecret of 256 bits (which has been expanded using PBKDF2).

This MasterSecret is then split into a key and an iv, to encrypt a message using AES-GCM.

I must work with AES-256, so my key must be 256-bit long. The iv for GCM is always 128-bit long.

So, briefly, I must extract from a 256-bit MasterSecret a 256-bit key and a 128-bit IV.

How to do it ?

I thought of taking the MasterSecret as the key, and then hashing the key to get then the iv of the desired length.

Is there a more efficient/elegant way to obtain 384 bits from a 256 bit MasterSecret ?

$\endgroup$
  • $\begingroup$ Your method of IV generation seems dangerously flawed at first glance $\endgroup$ – Richie Frame Sep 17 '15 at 10:18
  • $\begingroup$ @Richie - That's why I only thought of it ;) $\endgroup$ – EisenHeim Sep 17 '15 at 10:20
  • $\begingroup$ Are you only using MasterSecret once? Then you can just use zero IV. $\endgroup$ – otus Sep 17 '15 at 10:24
  • $\begingroup$ Yeah, it's just used to provide the keys for the AES. After that all communications will be encrypted with this key. Isn't it weaker for the security, to use a zero IV ? $\endgroup$ – EisenHeim Sep 17 '15 at 10:26
  • 1
    $\begingroup$ Is there a good reason to require exactly 128-bit IV? The default IV length for AES-GCM is 96 bits. Larger IV lengths than that will be (a bit) less efficient. See NIST SP 800-38D, section 8 for some discussion on choosing IV for GCM. $\endgroup$ – user4982 Sep 17 '15 at 15:58
3
$\begingroup$

You don't actually need 384 bits of key material. The IV for GCM does not need to be secret, and may be chosen deterministically, e.g. as an incremental counter. Thus, you only need 256 bits for the AES key, which you already have.

That said, if you did actually need more key material, you could use any standard KDF to expand your 256 bits. Since you presumably already have a 256-bit hash function available (for PBKDF2), I'd personally suggest using HKDF-Expand. Since your master secret is already a pseudorandom bit string, you may safely skip the Extract part of HKDF; see §3.3 of the RFC.

(You could also request more bytes directly from PBKDF2, but this is rather needlessly inefficient. If you need more than one hash block of output from PBKDF2, it's better to combine it with a key-based KDF such as HKDF. Technically, you could also use a second PBKDF2 pass with an iteration count of 1 instead of HKDF, but this feels a bit "untidy", as PBKDF2 was not really designed to be used like this.)

$\endgroup$
  • $\begingroup$ HKDF ins't implemented yet in crypto++. I think I'll generate an iv every time I need one, without using bits of the MasterSecret. $\endgroup$ – EisenHeim Sep 17 '15 at 11:26
  • 2
    $\begingroup$ That's a good choice. That said, HKDF is pretty easy to implement yourself. $\endgroup$ – Ilmari Karonen Sep 17 '15 at 11:51
  • $\begingroup$ Oh, didn't see that ! Thanks a lot ! And must the iv be the same for the two users ? I'm a bit confused. If I generate a new iv each time I encrypt a message, should I send the iv too ? $\endgroup$ – EisenHeim Sep 17 '15 at 12:39
  • $\begingroup$ Yes, or derive the IV from something unique that you do send with the message, such as a message ID. (In fact, GCM accepts IVs of any size, so you can just use the message ID directly as the IV if you want.) Also, if two (or more) users are using the same key to encrypt messages, you'll need to ensure that they don't use the same IVs, e.g. by having one of them only use even IVs, and having the other use only odd IVs. $\endgroup$ – Ilmari Karonen Sep 17 '15 at 12:55
  • $\begingroup$ OK thanks. I think I'm gonna add a message ID on 2 bytes, that each increment (even/odd). Thanks again ! $\endgroup$ – EisenHeim Sep 17 '15 at 13:03

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.