# Emphemeral key creation from a long term shared secret (without DH)

Assuming I cannot use DH scheme, and the long term key is known to both sides, is there a known algorithm / standard that defines how to derive a short term key from a long term key?

• Such a short term key is often called a "session key". Feb 5 '19 at 11:20
• Feb 5 '19 at 13:48
• @MaartenBodewes assuming the keys are same, using KDF to generate next key by a counter-salt should be a solution? But Stange is strange :) Feb 5 '19 at 15:27

Let's create a simple scheme that includes authentication and the dependence of the session secret on both the long term secret $$K$$ as well as random generators of both sides:

1. generate and store random $$R_A$$ at A;
2. send random $$R_A$$ from A to B;
3. generate and store random $$R_B$$ at B;
4. send $$(R_B, MAC(K, R_B \| R_A \| B \| A))$$ to A;
5. let A validate that the MAC authentication tag is correct and that B, therefore, controls key $$K$$;
6. send $$MAC(K, R_A \| R_B \| A \| B))$$ to B;
7. let B validate that the MAC authentication tag is correct and that A, therefore, controls key $$K$$;
8. let both sides calculate $$Info = R_A \| R_B$$ and $$K_S = KDF(K, Info)$$

Here $$A$$ and $$B$$ are identity strings of the entities A and B respectively.

Currently only one session key is calculated, but it is easy to add e.g. a label and identity to the $$Info$$ structure to calculate specific keys (so to create a message authentication key for A, you could create $$Info = R_A \| R_B \| \text{"Auth"} \| A$$ where $$\text{"Auth"}$$ is the label and $$A$$ is the identity of A, for instance, a serial number. Using separate session keys for specific uses and entities is highly recommended.

The above mixes a challenge / response protocol with session key establishment. There are many variations for such schemes.

You can just swap randoms, calculate and create session keys as above, and use one of them to authenticate the parties, instead of relying on $$K$$ for authentication.

You can, of course, skip the authentication of the parties entirely. But then you would not know that you're communicating with a legit party. You would be sure of the authenticity of the entity when you'd receive the first authenticated message protected by the newly established session key. However, I would strongly advise against mixing entity and message authentication - if just for the error handling if the authentication does not succeed (but there are more issues than just that).

Yet another variation would be to rely on a random value generated by a single party. This is more efficient and could remove one handshake message from the protocol. However, the resulting session key now only depends on the correctness of one random number generator.

Note that these purely symmetric schemes do not provide forward security. That means that the security - especially the confidentiality - of the messages depends fully on the confidentiality of the key $$K$$. If it ever gets known then an adversary can simply decrypt stored sessions. Don't forget to destroy your keys when they are not needed anymore.

There are of course standards for these kind of schemes, but I'll quote Andrew S (Andy) Tanenbaum on standards: "The nice thing about standards is that you have so many to choose from..."

I noted ratchets as well in the comments; I didn't go into that as I think it is more targeting creating the next long term key rather than an ephemeral session key.