1

As i understand it, PKI with an asymetric key approach is much more secure than a symetric key encryption. The keys are much bigger but it takes more CPU power to en- and decrypt. So why do we exchange the pre-master secret? couldnt we just encrypt the shared secret (key for symetric encryption)? The client could come up with a random key, encrypt it with the public key (found within the public certificate) and the server could decrypt it with the private key. So if we dont trust that the PKI is save, there is no point in using it in the first place. It smells a bit like the transition from DES to 3DES as DES got viewed as weak. I can think of 3 reasons why it isnt done this way.

  1. The key exchange ensures the use of PFS which in return means that PFS is used in all TLS connections (which i think is true for TLS 1.3)
  2. The PKI thing is only used for verification that the cert comes from where it says it comes from (denying a man in the middle attack)
  3. It would be viewed as a secure way, but the key exchange was implemented to increase the security, should some process fail in the future
3
  • 4
    I think, you already answered your question.
    – Crypt32
    Oct 17, 2021 at 14:37
  • 3
    "... couldnt we just encrypt the shared secret ..." - what you describe is the essence of RSA key exchange, which is deprecated for the very reason you mention in your first point. Apart from that the method will not work with ECDSA certificates anyway since there is no "decrypt it with private key" possible. Oct 17, 2021 at 16:50
  • Asymmetric is NOT generally stronger than symmetric; both asymmetric and symmetric schemes vary in strength, and the ones used in TLS are chosen to be roughly equal. Symmetric is much more efficient, but (pure) symmetric can only be used among entities with frequent-enough physical contact -- e.g. US submarines communicating with US Navy headquarters. For the Internet nearly all communications are between entities with no physical contact, so we use a hybrid system with asymmetric key exchange and authentication. Oct 18, 2021 at 2:47

2 Answers 2

2

As i understand it, PKI with an asymetric key approach is much more secure than a symetric key encryption.

This is wrong. If anything, asymmetric cryptography is less secure than symmetric cryptography: it's harder to do implement asymmetric cryptography than symmetric cryptography (I'm not going to compare the internal design of the algorithms), and more attacks threaten asymmetric cryptography (for example, if we figure out how to make quantum computers, that will break all the asymmetric cryptography that's in use today, whereas for symmetric cryptography we'll just need to stop using small keys).

But mostly symmetric cryptography and asymmetric cryptography solve different problems, so you can't compare them that way.

In particular, for TLS, the usual setup is that the client knows what server it wants to connect, but the server doesn't know anything about the client that's connecting to it. And at a minimum, the security goal is that the client knows what server it has actually connected to, to avoid a man-in-the-middle attack. In this scenario, symmetric cryptography is not enough: the client needs to know some cryptographic value that's specific to the server. This can't be a secret key that's already shared between the client and the server because the server doesn't know anything about the client. And it can't be a secret key that's shared with many clients in addition to the server because that would allow the client to impersonate the server when talking to other clients. Therefore the only solution is to use asymmetric cryptography, where the client knows a public key of the server which does not allow it to reconstruct the private key that only the server knows. A public key infrastructure is a way for the client to find out the server's public key from the server's name.

So why do we exchange the pre-master secret?

The client and the server need to decide on a secret key. The client knows the server's public key, and needs to be able to construct the pre-master secret (the shared secret key) from the server's public key plus whatever data the server sends. The server knows its private key and needs to be able to construct the pre-master secret from that plus whatever the client sends. There are several ways to do that.

couldnt we just encrypt the shared secret (key for symetric encryption)? The client could come up with a random key, encrypt it with the public key (found within the public certificate) and the server could decrypt it with the private key.

Yes, that's possible, with an asymmetric cryptography construct that can do asymmetric encryption (encrypt with a public key, decrypt with the corresponding private key). Since only the server has a public key, this means the client generates a random key, encrypts it, and sends it to the server, which decrypts it. An attacker who sees or even changes the messages in transit won't be able to obtain the shared key since it can't decrypt the shared secret chosen by the client. Note that it is still necessary to protect against other attacks, such as repeating a server's messages; I won't go into what this requires in terms of protocol design.

This method exists in TLS: that's how the cipher suites that use RSA but not (EC)DH work. It has several downsides, which led to this method being abandoned in TLS 1.3:

  • In terms of security, this approach lacks forward secrecy. This is the property that if an attacker records all communications that a server makes, and later manages to breach the server and obtain its private key, then the attacker can decrypt all past communication. This is fundamentally possible with any approach where the client chooses the shared key on its own, since the only secret data that the server has to calculate the shared key is its private key.
  • Similarly, this approach allows a middle-box to decrypt traffic if it knows the server's private key. Whether this is a good thing depends if you're a security administrator who is more concerned with knowing exactly what information is exfiltered from your organization (middle-box good) or anyone else (middle-box bad). Anyone else includes a security administrator who's concerned about the organization being vulnerable to impersonated servers: that's harder to defend against when a middle-box gets involved.
  • In addition, asymmetric decryption is intrinsically difficult to implement securely. The decryptor uses its private key on a message which is coming from outside and could be coming from an attacker. Any design flaw in the algorithm or in the implementation can give a way for the attacker to obtain information about the private key. Signature is safer in this respect because the private key is used on a message that is generated internally and so has a known format.
  • To make matters worse, TLS standardized a particular method for RSA encryption which is extremely hard to implement securely: PKCS#1 v1.5. This approach is vulnerable to a padding oracle attack, known as Bleichenbacher's attack (one of them, and by far the most far-reaching one). Refinements on this attack have been present in real-world applications for more than 20 years. And even if you manage to implement PKCS#1v1.5 decryption as a secure black box, the way TLS uses it is itself vulnerable to the same attack. In contrast, OAEP (a more modern RSA-based encryption scheme) is vulnerable to a similar attack, but there's a much smaller core that it's sufficient to get right. And standard RSA-based signatures, including PKCS#1v1.5 signature, are not vulnerable to any similar attack, for the reason I explain in the previous bullet point.
  • Today, a lot of systems use elliptic-curve cryptography instead of RSA and non-EC Diffie-Hellman. ECC has significantly faster private-key operations, smaller signatures (so less data to exchange), but slower public-key operations. In terms of performance, RSA is only preferable to ECC if signature/decryption speed doesn't matter, encryption/verification speed is critical, and message size isn't a concern. Thus ECC is almost always preferable for performance. And ECC doesn't have a way to directly encrypt a message the way RSA does: the way to encrypt data with ECC, standardized as ECIES, is to do a key agreement and then encrypt the data with the resulting shared secret — which you can bypass if your only goal is to establish a shared secret.

The key exchange ensures the use of PFS which in return means that PFS is used in all TLS connections (which i think is true for TLS 1.3)

That's true for all TLS cipher suites that use ephemeral Diffie-Hellman (whether using elliptic curves or classic finite fields), i.e. all TLS ≤1.2 cipher suites with DHE or ECDHE in their name, and all TLS 1.3 cipher suites.

The PKI thing is only used for verification that the cert comes from where it says it comes from (denying a man in the middle attack)

That's correct. The DH key exchange establishes a shared key, and the client uses its knowledge of the server's public key to check that the shared key was indeed established with the desired server, rather than with a man-in-the-middle attacker.

It would be viewed as a secure way, but the key exchange was implemented to increase the security, should some process fail in the future

Decryption-based TLS is not fundamentally insecure as far as the basic properties of TLS are concerned (resistance against man-in-the-middle attacks), but it's hard to get right and there's a security property (PFS) it cannot achieve at all.

1
  • Thank you so much for this detailed response. Especially the bit where you explain where symetric and asymetric encryption are used and why. The ECC topic using less resources sounds very interesting as well.
    – Mario Jost
    Oct 20, 2021 at 12:26
3

"Client generates a value, encrypts it with the public key from the certificate, sends it to the server, and server decrypts it" is the core of the RSA key exchange, widely used in all SSL/TLS versions prior to TLSv1.3 (though declining even before 1.3). It has three main weaknesses:

  1. It doesn't allow for forward secrecy, meaning an attacker who records the key exchange and then later obtains the server's private key can decrypt the entire communication. As you yourself noted, this is one of the disadvantages of RSA key exchange, and TLS has moved toward ephemeral Diffie-Hellman (including elliptic curve Diffie-Hellman) key exchanges for years now to combat this threat.
  2. RSA is extremely inefficient. It is NOT inherently more or less secure than symmetric ciphers, or than other asymmetric ones, but achieving equivalent security requires using massive key sizes that are expensive to perform operations with. Beyond the performance impact, some old network hardware (load balancers and the like) just couldn't handle certificates over a certain size, which posed a problem for using very large RSA keys.
  3. Non-RSA public key algorithms mostly don't support encryption. In particular, DSA (the older Digital Signature Algorithm) and ECDSA (its elliptic curve variant) do not support encryption - only signing - and some certificates only contain a DSA/ECDSA key. It's obviously not sufficient for the server to sign (but not encrypt) a key (or pre-master secret) that it's transmitting. However, you can secure a DH/ECDH key exchange this way, with the server signing the (generally ephemeral) public parameter it sends to the client (and the client validating it using the public key in the certificate). This works with RSA certificates as well, of course, since RSA can be used for signing too.

As for why we use symmetric keys at all (as opposed to just using asymmetric encryption for the data going back and forth), the second and third reasons above are both relevant (too computationally expensive, can't use ECDSA certs) but there's another reason too: how would the server secure the content of its responses? In TLS, the client usually does not have its own private key, or offer a public key for the server to encrypt with. It could generate one, encrypt it (if the server uses an RSA certificate), and send it to the server, and with enough work you could make this secure against man-in-the-middle attacks, but that's incredibly wasteful compared to just sending an AES key (or pre-master secret for turning into an AES - or any other symmetric cipher - key), which as mentioned above is how RSA key exchange works.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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