# Differences between the terms “pre-master secret”, “master secret”, “private key”, and “shared secret”?

Both crypto.SE and security.SE have excellent Q&As about how TLS generates session keys (I have linked some at the bottom).

In reading these threads I'm having troubles with terminology since the following terms seem to be used with overlapping contexts, though they are clearly different concepts. Reading definitions is only partially helpful since they don't show the differences between their usages.

• pre-master secret
• master secret
• private key
• shared secret / session key

As I understand it, the pre-master secret is related to private keys, but is algorithm independent, and the master secret is (often?) used as the session key. But I'm sure there's more nuance to the definitions.

Related Questions:

• +5 Sometimes I wish we could give extra rep points for really good questions. Who would have thought, someone actually searched around and read related questions before posting :) – mikeazo Jul 24 '15 at 16:46
• @mikeazo Thanks *blush. It's not that I searched around, but rather that I'm quite active on security.se, and this has been bothering me for a while. – Mike Ounsworth Jul 24 '15 at 17:26
• What research have you done? Have you read the TLS spec? The official spec would be the obvious place to check, and I believe it's all defined in there. Reading questions here isn't a substitute for checking the primary sources. – D.W. Jul 24 '15 at 19:36
• @D.W. Thanks? I'm certainly aware of, for example RFC 5246 - 7.3. Handshake Protocol Overview, but the sheer volume of semi-familiar terms and concepts makes my head swim :$– Mike Ounsworth Jul 24 '15 at 19:56 • Pre-master secret: tools.ietf.org/html/rfc5246#page-58. Computation of master secret, and how it differs from pre-master secret: tools.ietf.org/html/rfc5246#page-64. The session keys are defined and used in the record layer: tools.ietf.org/html/rfc5246#page-16. If you want to know how TLS works, reading the entire spec is a great exercise! – D.W. Jul 24 '15 at 20:15 ## 2 Answers Simplified SSLv3/TLS from this book Note,$R_{(Alice|Bob)}$is a random nonce chosen by Alice or Bob respectively, and$\{S\}_{Bob}$is encryption with Bob's public key. # pre-master secret As stated in one of the answer you link to, "The point of a premaster secret is to provide greater consistency between TLS cipher suites." In the figure above, the premaster secret is$S$(in message 3). In this case, it is randomly generated. It could come from a diffie-hellman exchange, or some other method, depending on the agreed upon cipher suite. It isn't really "related to the private keys" but how it is generated/agreed upon depends on the cipher suite chosen in the second message of the figure. # master secret In the figure above, the master secret is$K$. Shown on the sides, it is a function of the pre-master secret and the two random values sent in the first two messages. # private key I'm not really sure where this comes from. It could refer to the Bob's private key for the certificate sent in message 2. It could also refer to private keys used in a diffie-hellman key exchange. If doing client authentication, it could refer to the client's private key associated with their certificate. # shared secret / session key This is what is referred to in the last step of the figure. The session key is referred to as "keys derived from K". Many keys are actually derived from K. This could be the encryption key, integrity protection keys (for say HMAC), IVs for the ciphers, etc. And, it is usually a different set for each direction. • +1 Thanks! About "private keys"; I was under the impression that each party presented a premaster secret, and that if the server uses a Diffie-Hellman certificate, then it will always use the same premaster secret (somehow related to the cert). From your answer I am getting that there is only one premaster secret S, and the thing in the DH cert is R_bob. Is that correct? – Mike Ounsworth Jul 24 '15 at 17:36 •$R_{bob}\$ would be a new random number every time, AFAIK. So it wouldn't be anything in the cert. Though things can change quite a bit for specific cipher suites. If there is a specific cipher suite you are interested in, I'd ask that as a separate question. My answer most relates to the RSA cipher suite. – mikeazo Jul 24 '15 at 17:44
• @MikeOunsworth DH certs are only used for "fixed" aka "static" (integer) DH which essentially nobody uses. The ECC equivalent is very rare. Fixed-[EC]DH combined with client authentication (also rare) does produce a fixed premaster secret, which is still handled by including nonces in the master secret derivation. What is common is ephemeral DH or ECDH, combined with cert-based authentication (RSA, DSS or ECDSA respectively); SSL/TLS spells these DHE and ECDHE. – dave_thompson_085 Jul 24 '15 at 23:37

When a TLS/SSL session starts(after the hellos and cipher decisions) the server gives the client it's cert. The key in the cert could perform different actions depending on the key-agreement algorithm decided on by the client and server.

Let's say they agree on RSA key agreement. This means the cert contains the server public RSA key and the server has a private RSA key used for decryption, hence private key. The client generates a random sequence called the pre-master secret. The client uses the public RSA key on the cert to encrypt the PMS. The server decrypts the message and gets the PMS. The server and client then perform some random mixing on the PMS, could be a KDF. That Master secret is used to derive keys for symmetric encryption and MAC.

Another option is the server and client could perform Diffie-Hellman key exchange in which the client must also generate a public-private DH pair used to exchange AND generate(due to the way DH works the client doesn't choose the PMS) the PMS. The MS is derived as above. A more modern approach is to use session keys in which the server cert contains it's public key for verifying a signature algorithm(RSA-SHA, ECDSA) that it used to sign either an RSA or DHE (the E means one-time use keys or session keys) public key for key-agreement. Thus the server is not reusing it's key-agreement public key. This provides perfect forward secrecy . In which finding the PriK (Long-lived key) of the signature algorithm the server uses to sign its keys does not make all the session keys vulnerable. In addition finding a session key should allow you to obtain information that would allow you to decrypt traffic that used another session key(The PMS could also be considered a "session key") You could look up a PKI to understand more about how a cert verification works which I did not explain. This is where the client makes sure the cert is valid.

Asymmetric crypto is used for key-agreement (keys are smaller than messages) due to the high processing power required and symmetric crypto is used for encryption and authentication of the resulting cipher text. Also the term key-agreement is different than key-exchange (more general). Key-agreement means that there is no trusted-third party involved in the actual exchange of keys, which is true in the case of SSL/TLS

• Ephemeral DH (DHE) keyexchange has been signed with RSA or DSA(DSS) using the server cert (and if applicable client cert) since SSLv3 in about 1999, and ephemeral ECDH (ECDHE) similarly since ECC was added in 2006; these are not "more modern". The only keyexchange with an ephemeral RSA key signed by the cert -- or even used at all -- is for some "EXPORT" suites which are only in versions before 2006 (and were widely discouraged before 2000). RSA signing of keyexchange (DHE-RSA or ECDHE-RSA) uses a nonstandard combination of MD5+SHA1 through TLSv1.1 and a negotiated hash in TLSv1.2. – dave_thompson_085 Jul 24 '15 at 23:40
• @dave_thompson_085 Are there still situations in which the key on the server's cert is a Long-lived RSA not ephemeral which the client uses to encrypt and send a Pre-master secret to the server. Where the RSA key is not signed by the cert, it is the key on the cert? Or is that even older than the ephenumeral RSA you mentioned ? – dylan7 Aug 1 '15 at 4:02
• Yes, "plain" RSA keyexchange is in all versions of the protocol and is still used, but many users and/or admins nowadays (post-Snowden and other public breaches) don't prefer it because it doesn't provide Forward Secrecy, and some prohibit it for that reason. I didn't make any criticism of that paragraph. – dave_thompson_085 Aug 5 '15 at 3:33