0

I am reading about the Diffie–Hellman key exchange in TLS 1.3. So the first step here is that the two parts Alice and Bob t agree on a large prime p and a nonzero integer g modulo p. Then Alice and Bob make the values of p and g public knowledge.

How the values p and g get public as we are before the client and server hello messages?

Also, the private and public keys that get generated here are the same keys that the server or/and the client use in order to acquire a cc.509 certificate (via a certificate signing request to a trusted certificate authority)?

Z.T.
  • 7,963
  • 1
  • 22
  • 36
loutsi1
  • 51
  • 7

1 Answers1

2

For TLS 1.3, you are limited to a few pre-selected named groups (RFC 7919) and you include the identifier of the group with your key share. See sections of the RFC.

In previous versions of the protocol like TLS 1.2, the server sent the p and g together with the key share in ServerKeyExchange, again see the RFC. The server had to pick some values, either from Oakley group RFCs (RFC 3526) or a random value the server generated in advance using something like openssl dhparam 2048.

To the second part of your question, absolutely not and they have nothing to do with each other. The key exchange part performed by DHE or ECDHE and the authentication part performed by RSA or ECDSA (or theoretically EdDSA) do not share keys. Note how they often use different cryptographic primitives in the same handshake (most popular on the internet now is ECDHE with RSA certificates)!

The fact that the a and b in DH are called "private keys" and g^a mod p is called a "public key" is true, but a little confusing in the context of TLS. These are ephemeral, meaning single use, short term keys. They are the opposite of long term "identity" keys that you would use for authentication.

When you as a client connect to a server, the server has just created a new DHE key when you connected to it. Nobody has ever seen this key before, and when the handshake is over, it will be deleted. How would you use it for authentication? Who will you ask to confirm it?

Static-DH certificates used to exist (at least in theory) a long time ago. They don't exist anymore and are not allowed. They used long term DH keys for authentication and included the public key share in the certificate, but the certificate was signed by the CA using RSA. The key exchange performed ephemeral-static DH to confirm the server. This did not provide PFS and died out in favor of RSA key exchange (which also did not provide PFS) and then ECDHE+aRSA, which finally provided PFS.

Outside the context of TLS, protocols like those based on the Noise Protocol Framework, like WireGuard, use long term ECDH keys for authentication, together with different ephemeral ECDH keys used for key exchange, thus reusing code (less code to review). TLS doesn't do that because you need to confirm the validity of the certificate chain, and for that you need offline signature validation, which you can't do with Noise (as far as I understand, please someone correct me if I'm wrong).

Community
  • 1
Z.T.
  • 7,963
  • 1
  • 22
  • 36
  • @ Z.T hi thank you for the answer but I get little confused. So let me ask you some question and forgive my ignorance. 1) You say that "the authentication part performed by RSA or ECDSA (or theoretically EdDSA) do not share keys". The certificate is signing with the ca private key. The certificate verify message is signed by the entity private key and so the other entity is able to confirm using the public key. Where RSA or ECDSA take place in the authentication part. 2) what if i want to use static keys? Can then have the same keys for key exchange and authentication? – loutsi1 Jan 29 '21 at 14:00
  • 1. That is the authentication part, using the RSA and/or ECDSA public keys to verify the signatures along the chain of certificates. 2. You can't use static DH on your server because no TLS client supports it. You can use RSA key exchange, with TLS 1.2 but not with 1.3, and then there is no DH and you don't use the end-entity certificate's key for signature but for decryption (the client reads the cert, encrypts a new random value to the public key, sends that, the server decrypts, now they have shared value and the client know only server could have decrypted it). It's not allowed in TLS 1.3. – Z.T. Jan 29 '21 at 14:05
  • The keys for the DH part and the keys for the certificate part have nothing to do with each other. They happily use completely different cryptographic systems. ECDHE over NISP P-256 and RSA PKCS#1v1.5 have nothing to do with each other. A single TLS handshake performs both things. An RSA signature signs an ECDHE public key. But the RSA signature doesn't know anything about ECDHE, it's just signing an array of bytes. The key exchange can be replaced with something weird like proposed post quantum cryptosystems, and the cert can remain RSA. Or replace the tech in the cert and keep ECDHE. – Z.T. Jan 29 '21 at 14:11
  • Same way you can replace the symmetric tech from AESGCM or ChaCha20Poly1305 to any other AEAD and the RSA part and the DH part will not need to be changed. – Z.T. Jan 29 '21 at 14:13
  • There are 5 parts in a cipher suite (asymmetric key exchange, asymmetric authentication (digital signatures), symmetric cipher, symmetric message authentication, symmetric key derivation function) and you can replace each one separately from the others and still keep TLS working. SSH and TLS differ in how the parts are negotiated, and in TLS not all combinations are allowed, but it would worked if they were allowed. So just pick one for each of the 5 parts and now you have a "cipher suite". – Z.T. Jan 29 '21 at 14:18
  • Do you ask "why do I need separate RSA key and AES key? Why not use a single key for both?" You don't. Same reason you don't use single key for DH and Certificate. – Z.T. Jan 29 '21 at 14:20
  • thank you very much for your answers. You help me a lot – loutsi1 Jan 29 '21 at 14:25
  • @ Z.T can you help here if you have time https://security.stackexchange.com/questions/243945/symmetric-key-generation-in-tls-1-3 – loutsi1 Jan 29 '21 at 14:30