Score:1

Does deriving a key from a master key and then encrypting with AES-GCM increase the lifetime of the master key?

cn flag

Suppose that we have a symmetric 256-bit master key, and we want to encrypt using AES-GCM with random IVs. I understand that with random IVs, the lifetime of the master key is 2^32 in order to conform to NIST requirements.

Let's assume that we want to increase the lifetime of the master key. Can we do this by adding a key derivation step before the actual encryption? Assuming that we use the master key as input keying material and a random nonce in HKDF, can we extend the master key's lifetime?

In other words, is AES-GCM(HKDF(MasterKey, ...), IV, ...) offering any advantage regarding the total number of messages versus AES-GCM(MasterKey, IV, ...)?

Specifically, assuming that HKDF has a fixed salt and random 128-bit nonce as input, and GCM uses a 96-bit random IV, then I assume that (WK, IV) have a lower collision probability than (IV). If this assumption is correct, how does one go about calculating a bound for the master key's lifetime?

Swashbuckler avatar
mc flag
"I understand that with random IVs, the lifetime of the master key is 2^32 in order to conform to NIST requirements." Yeah, but... GCM is based on CTR mode and there's research that suggests that you should limit the total amount of data encrypted with a single key (irrespective of how many IVs are used) to be about 64 GB (depending on your risk tolerance). "In particular, we show that message-recovery attacks against the CTR mode can be mounted with roughly the same requirements and the same complexity as attacks against the CBC mode." See https://eprint.iacr.org/2018/159.pdf
kelalaka avatar
in flag
Some collision calculations is done here; [Multiple AES Key Derivation from a master key](https://crypto.stackexchange.com/questions/76588/multiple-aes-key-derivation-from-a-master-key/76589#76589) also, is it possible to use AES-GCM-SIV?
Score:1
in flag

Let's assume that we want to increase the lifetime of the master key. Can we do this by adding a key derivation step before the actual encryption? Assuming that we use the master key as input keying material and a random nonce in HKDF, can we extend the master key's lifetime?

Yes, certainly when it comes to the requirements of GCM anyway. There may of course be other considerations because the same master key is still protecting a possibly large amount of messages.

In other words, is AES-GCM(HKDF(MasterKey, ...), IV, ...) offering any advantage regarding the total number of messages versus AES-GCM(MasterKey, IV, ...)?

Potentially yes, it of course depends on the other inputs of HKDF, but as long as the input to HKDF is unique you have a secure one-way function that makes the derived keys independent of each other.

Specifically, assuming that HKDF has a fixed salt and random 128-bit nonce as input, and GCM uses a 96-bit random IV, then I assume that (WK, IV) have a lower collision probability than (IV).

There is no "nonce" defined as an input parameter to HKDF, but you can use one within the Info field.

A "fixed salt" is of little to no use. You can however use an empty salt parameter and use a nonce as part of the Info parameter and be reasonably secure.

With a salt you don't have to think about domain separation (e.g. the use your master key for anything else that might interfere), source independent extraction (e.g. the possible repetition of the nonce or bad entropy of the master key) - but you can do without.

Actually, you can skip a step if you want and just use HKDF-Expand if your master key has enough entropy. In that case, there is no Salt parameter required.

I would recommend having some additional constant string in the Info field that can also be used to derive keys from the master for additional use cases. For instance, the Info field could use a label called "EncapKey". This simply indicates what the use case of the derived subkeys is - it provides some domain separation.

If this assumption is correct, how does one go about calculating a bound for the master key's lifetime?

Let's assume that you output 256-bit keys and use at least SHA-256 as an underlying hash. Then the additional chance of collision can be considered negligible; it depends entirely on the collision properties of the nonce provided.

As indicated, there may be other reasons why you want to refresh your master key now and then, because the security of the messages still depends on that one single key.

user13129201 avatar
cn flag
Thank you for your reply. I am still a bit confused regarding this. In https://rwc.iacr.org/2018/Slides/Gueron.pdf the authors follow a similar approach but their computed boundaries are different. Furthermore, in the original paper they state that AES-GCM with key derivation does not allow for more messages to be encrypted when the IV is chosen randomly (just longer messages). In your reply, are you implying that this is entirely dependent on the HKDF output, or did I misunderstand? HKDF input relies on the same entropy source as the IV, so the birthday problem kicks in in both info and IV.
Maarten Bodewes avatar
in flag
Ah, sorry, yes, if you use a 128 bit **random** nonce then you need to consider the birthday bound for that, obviously. I was put on the wrong foot as you distinguished between a salt and a nonce in your question. Can you indicate what you think is the difference between these two terms?
user13129201 avatar
cn flag
By nonce I basically meant putting 16 random bytes in the info. I would like to generalize this issue outside of the choice of the KDF though. In theory, does appending a KDF step before the AESGCM step make the system handle more than 2^32 messages securely? And if so, is it because it is hard to find (WK, IV) pair collisions than plain IV collisions (i.e., the case of plain GCM with the KDF step)?
Maarten Bodewes avatar
in flag
Yes, the collision would be entirely in the sub-key generation. As the key changes you don't need a random IV at all, as the set key, IV would now rest almost entirely on the strength of the key. So in that sense it makes more sense to put all the random bits in your `Info`. I don't think it matters much, but it makes more sense to me to put all those bits in the salt - that's a per-derivation random value after all - and then use some label in the `Info` field. The disadvantage of that is that you'd have to use the full HKDF though.
millenseed avatar
in flag
Why would it rest on subkey derivation? Wouldn't we have to multiply the collision probabilities of both the subkey and the IV happening together?
Maarten Bodewes avatar
in flag
Yeah, I used some out of the top of my head calculations and I think it doesn't matter all that much, as in the end you will have to multiply them together as you said. However, a collision in the key used seems more dangerous to me than just in the combination.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.