Score:6

Crypto

Is RSA longer supported in TLS 1.3 and are RSA and DH fundamentally different?

stacksonstacksonstackoverflow

1/3/24, 2:53 AM

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:

Does TLS 1.3 longer support RSA? Why?
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?

1478

2 + 1

diffie-hellman

Maarten Bodewes

1/3/24, 4:16 PM

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.

Score:6

Crypto

DannyNiu

1/3/24, 3:36 AM

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).
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.

+ 5

stacksonstacksonstackoverflow

1/3/24, 3:40 AM

Thanks. Good to know that my hunch that RSA and DH are both asymetric key encryptions was right.

Meir Maor

1/3/24, 6:58 AM

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.

DannyNiu

1/3/24, 7:04 AM

@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](https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-03.html#section-2) for precedence.

Marc Ilunga

1/3/24, 9:27 AM

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.

SAI Peregrinus

1/3/24, 7:16 PM

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.

Score:3

Crypto

Daniel S

1/3/24, 7:54 AM

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.

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.

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Is RSA longer supported in TLS 1.3 and are RSA and DH fundamentally different?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.