# Why are ephemeral/session/temporary keys useful?

One reason that communication protocols use ephemeral keys is to help with implementing Perfect Forward Security.

They're also used in SSL to go from using RSA to using a faster symmetric encryption.

Why else are ephemeral keys used? In particular, if I don't care about Perfect Forward Security, and I already have two machines that have a shared symmetric key, is there any reason to use ephemeral keys?

In AES-GCM, is a 96-bit IV sufficient to not require temporary keys?

Why else are ephemeral keys used?

Ephemeral keys are not a specific form of keys, they are just short lived keys within a key establishment protocol. Usually they are not directly trusted as they are generated on the fly.

ECIES may also use an ephemeral private key, to name a single other usage.

In particular, if I don't care about Perfect Forward Security, and I already have two machines that have a shared symmetric key, is there any reason to use ephemeral keys?

You may want to generate symmetric session keys that can only be used for a specific session. Ephemeral-ephemeral DH key agreement would work fine for that, although other schemes are also possible. You may also want to use separate keys for different senders and for different purposes (such as encryption and MAC).

Otherwise you could for instance replay messages encrypted with the masterkey. Again, there would be other methods that protect against such a situation, but establishing session keys is a common way to do this.

In AES-GCM, is a 96-bit IV sufficient to not require temporary keys?

Unless you define ephemeral simply as short lived keys the AES keys themselves are not really ephemeral. They are generally used for multiple messages, not just during key establishment.

AES-GCM can, within reasonable bounds, be used with one key for multiple messages. And yes, the nonce can help with that. The bounds have been defined in NIST SP800-38D which specifies the GCM mode for use in US Federal Agencies.

There are good reasons to use session keys within a transport protocol regardless of the security of the cipher, as already mentioned in the second paragraph.

• Thank you! I notice your first section just defines ephemeral keys. Your second section mentions that a ephemeral keys help guard against replay attacks. Is that really true? Your third part mentions AES-GCM can be used "within reasonable bounds". What bounds? Perhaps Thomas has the answer. You also mention using ephemeral keys for "different senders and for different purposes". Can you describe more why you would want different keys in these situations? – theicfire Jun 20 '17 at 6:08
• I've tried to clear things up a bit, could you have a look and see if this helps? – Maarten Bodewes Jun 20 '17 at 6:56
• Thank you again! Section 8.2.2 of NIST SP800-38D states that an IV field of 96 bits or greater can be generated via a secure random bit generator (RBG). I wonder why they don't specify the amount of messages sent though. – theicfire Jun 20 '17 at 17:36
• I also understand now how session keys can stop against replay attacks -- when correctly negotiating keys, there aren't ways to replay keys, and therefore there aren't ways to replay messages with those keys (because the receiver will reject them). Overall, I'd like to summarize your answer to two points: 1) Session keys help guard against replay attacks. 2) Session keys help to guarantee IV/nonce uniqueness, which is required in some protocols. – theicfire Jun 20 '17 at 17:43
• Keys are unpredictable if a random or pseudo random function is used to create them. There is nothing wrong with keys generated on the fly, but e.g. you cannot create TLS server keys on the fly because a certificate authority needs to sign the certificate - with includes the public key - for the server to be trusted by a browser. – Maarten Bodewes Mar 10 '19 at 17:39

It's often about the storage of state associated with the key. If you use your long term shared key to encrypt and send messages then you either should be sending notably less than $2^{48}$ messages for random 96 bit GCM IVs or you'll need to store the IV if it's based on a counter. Failure to do so will likely result in the system re-using the same key and IV thus causing catastrophic compromise of authentication and notable confidentiality issues. Ephemeral keys, generated properly based on KE with the long term secret, protect us from these issues.

• Thanks! This ends up being 281 Petabytes * the average message length of messages to hit this limit. Which in nearly all cases won't be hit (only for massive websites). – theicfire Jun 20 '17 at 6:03
• I said "notably less". Feel free to work the probabilities. From a bin of $2^{96}$ how many balls, pulled randomly with replacement, can you grab before a 1 in $2{^80}$ chance of a repeat? Now rework that equation with your actual desired security level. – Thomas M. DuBuisson Jun 20 '17 at 6:17
• Having given the mathy answer, one engineering responses is that random ivs are not always possible or preferable. – Thomas M. DuBuisson Jun 20 '17 at 6:18
• Maarten mentioned NIST SP800-38D which gives a good answer to this in 8.2.2 (I summarized the point in a comment above). To my understanding, os.urandom in python is an example of a secure random bit generator, so I posit that random ivs are frequently possible (but I agree, not always) – theicfire Jun 20 '17 at 17:46
• The fact that you mention Python suggests you are thinking largely of code running on desktops or servers - which is certainly a significant user space. Expand that thinking to include ASICs on satellites, DVR systems, 802.11 hardware, etc. There's a lot in the world of crypto that isn't on a general purpose computer. – Thomas M. DuBuisson Jun 20 '17 at 20:11