2

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 ?

otus
  • 32,132
  • 5
  • 70
  • 165
3isenHeim
  • 200
  • 10
  • Your method of IV generation seems dangerously flawed at first glance – Richie Frame Sep 17 '15 at 10:18
  • @Richie - That's why I only thought of it ;) – 3isenHeim Sep 17 '15 at 10:20
  • Are you only using MasterSecret once? Then you can just use zero IV. – otus Sep 17 '15 at 10:24
  • 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 ? – 3isenHeim Sep 17 '15 at 10:26
  • I meant, will you use the key only once? Then zero IV is fine. If not, how are you deriving the IVs for subsequent messages? – otus Sep 17 '15 at 10:30
  • Probably no. We will encrypt several messages... And must the iv be different from one message to another ? Must it only be used once ? – 3isenHeim Sep 17 '15 at 11:21
  • @EisenHeim, yes. GCM fails bad if you ever reuse an IV with the same key for two messages. – otus Sep 17 '15 at 11:56
  • 1
    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. – user4982 Sep 17 '15 at 15:58

1 Answers1

3

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.)

Community
  • 1
Ilmari Karonen
  • 46,120
  • 5
  • 105
  • 181