6
$\begingroup$

I'm watching "SSL, TLS, HTTPS Explained" by ByteByteGo on YouTube and at the end, starting around 5:15, there are two points that are interesting:

in TLS 1.3 RSA is no longer supported as the a method for key exchange Diffie-Hellman is a more common way nowadays for exchanging session keys Diffie-Hellman is complicated but in a nutshell it uses some advanced math involving large prime numbers to derive a shared session key without ever transmitting a public key over the network

My two questions are:

  1. Does TLS 1.3 longer support RSA? Why?

  2. DH uses math involving large prime numbers to derive a share session key without ever transmitting a public key over the network.

Wait, what? Isn't that what DH and RSA both do?

Improve this question
$\endgroup$
1
  • 1
    $\begingroup$ That was one of the worst pieces of information regarding TLS that I've seen so far. Nothing about PKI and trust stores. All algorithms in the cipher suites are "encryption", nothing about key agreement, key derivation or MAC algorithms. We encrypt the session keys used for encryption with the public key? Interesting because we first share a master secret and derive the session keys instead. Maybe the public key in DH is sometimes hidden in plain sight as it is sometimes called the public component or something similar, but in the end it requires two public keys for DH. $\endgroup$
    – Maarten Bodewes ♦
    Jan 3 at 16:16

2 Answers 2

Reset to default
6
$\begingroup$

  1. It just means that RSA is no longer used for establishing a shared secret. It can still be used for authentication, e.g., by signing the (EC)DH public key (along with other handshake data).

  2. This is just wrong. While some may consider a D-Log power not a "formal" public key in a strict sense, it still functions as one. For example, in a KEM (Key Encapsulation Mechanism) API,

    • a server generates a public key and a private key;
    • a client generates a ciphertext and a shared secret using the public key and sends the ciphertext to the server;
    • the server the recover the shared secret from the ciphertext using the private key.

    In such a setup, the ciphertext and the public key can both be considered D-Log power. Such an API design allows key agreement schemes of more diversity to be used under a unified paradigm.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thanks. Good to know that my hunch that RSA and DH are both asymetric key encryptions was right. $\endgroup$
    – c_idle
    Jan 3 at 3:40
  • 3
    $\begingroup$ I won't say DH does assymetric key encryption. It does key agreement. The result is the same a new key where both parties have the key and an evesdropper does not. $\endgroup$
    – Meir Maor
    Jan 3 at 6:58
  • 1
    $\begingroup$ @MeirMaor I used "ciphertext" and "public key" per conventional terminology of general KEM API. Using alternative terms to describe what was being used just feels alienated and awkward. See This IETF draft for precedence. $\endgroup$
    – DannyNiu
    Jan 3 at 7:04
  • $\begingroup$ For 1. The signature doesn't only cover the DH key share but the transcript hash (so far). Otherwise, authentication in TLS 1.3 would be broken in a "active" attacker model. $\endgroup$
    – Marc Ilunga
    Jan 3 at 9:27
  • $\begingroup$ In a KEM, the client generates a random field element, applies the public-key operation to that element, and sends the "ciphertext" to the server. The client applies a KDF to the field element to create the shared secret key. The server applies the private-key operation to the "ciphertext" and then the same KDF to the result to get the same shared secret key. The exchanged message (the secret key) is arguably the plaintext, but it was never actually encrypted but instead derived from the field element. The "ciphertext" terminology is standard, but can cause confusion. $\endgroup$
    – SAI Peregrinus
    Jan 3 at 19:16
3
$\begingroup$
  1. RSA is no longer supported for key establishment, but is still supported for digital signatures. The reason that it is no longer supported for key establishment is a lack of forward secrecy. RSA keys are usually generated and used for a relatively long time involving multiple sessions, if at some point in the future the private key of an RSA modulus is compromised and in the possession of an adversary, then previous messages can be read.

For reasons such as this, the only key establishment methods supported in TLS 1.3 are:

  • ephemeral elliptic curve Diffie-Hellman (a particular form of the Diffie-Hellman key exchange with good bandwidth and computational efficiency) or ephemeral finite field Diffie-Hellman modulo five specific primes of 2048+ bits
  • pre-shared keys, or
  • a hybrid of both pre-shared keys and ephemeral (elliptic curve) Diffie-Hellman.

The ephemeral adjective means that the private keys associated with the exchange are only used once and generated afresh with every key establishment which provides forward secrecy. Pre-shared keys can be refreshed/ratcheted for forward secrecy.

  1. This is a poor choice of words. As you correctly note, Diffie-Hellman does require the generation of a public value. The distinction between the RSA and Diffie-Hellman public values is that an RSA key is typically static (i.e. unchanging between key establishments) and the elliptic curve public value is ephemeral (i.e. generated afresh with each connection). As Diffie-Hellman can use system parameters, generation of ephemeral keys is much simpler than it would be for RSA. Conversely, it isn't really possible to use certificates without long-lived keys and so RSA is still permitted for signing. There is also forward secrecy as future compromise of a signing key does not compromise a past key establishment.
Improve this answer
$\endgroup$
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.