2

As there don't seem to be any PQC alternatives for Diffie-Hellman (DH / ECDH), DH must have been replaced by key encapsulation using an ephemeral key pair. However, since TLS 1.3 always performs ephmemeral key agreement during the handshake I think that it is not possible to directly replace DHE / ECDHE with key encapsulation.

Which changes have been made in the protocol for adjusting it for Post Quantum Cryptography during the testing phase, e.g. using liboqs? Does this alter the TLS specification significantly?

Maarten Bodewes
  • 88,868
  • 12
  • 146
  • 304

2 Answers2

3

As there don't seem to be any PQC alternatives for Diffie-Hellman (DH / ECDH), DH must have been replaced by key encapsulation using an ephemeral key pair.

I don't believe that is correct; a postquantum Key Encapsulation Method (KEM) would appear to be the natural replacement for DH/ECDH within TLS. In the KEM, one side (the client) produces a KEM public key, the other side (the server) produces a response, and they both generate a 'shared secret'; this is what TLS 1.3 needs.

Now, the server can't have a static key (because, unlike DH, the server response depends on the client public key). On the other hand, TLS 1.3 currently doesn't assume that.

All of the NIST public encryption candidates can work like this; except for the ones that make it problematic by having huge key sizes, they all can fit within the current TLS 1.3 architecture.

poncho
  • 138,335
  • 11
  • 217
  • 344
  • "I don't believe that is correct; a postquantum Key Encapsulation Method (KEM) would appear to be the natural replacement for DH/ECDH within TLS" uh, that's what I said more or less. "One side (the client) produces a KEM public key, the other side (the server) produces a response". OK, so in the DH replacement the client always generates the key pair (not just the public key I suppose :) ) and the response is send using the first handshake by the server. So the server response replaces the server's public key? – Maarten Bodewes Mar 01 '21 at 21:47
  • 1
    @MaartenBodewes: well, yes; the protocol itself doesn't make a distinction between the server's DH public key, and the server's KEM response; in both cases, they are opaque octet strings that need to be carried to the other side, and have similar security properties. – poncho Mar 01 '21 at 21:53
  • OK, so that leaves basically only the (public key) size issue and hybrid encryption. Oh, and the "guessing" of the algorithm possibly. – Maarten Bodewes Mar 02 '21 at 08:32
  • @MaartenBodewes: as for size issue, given that there are several round 3 finalists and alternatives that easily fit in a 16k record, that's not an immediate concern. As for hybrid encryption (using both conventional and postquantum key exchanges), I believe the current thinking in the TLSWG is just do the two in parallel (concatenating the key shares), and stirring both shared secrets together. I have no idea what you mean by "guessing" the algorithm; the algorithm identifier is exchanged in the clear... – poncho Mar 02 '21 at 16:15
  • I meant sending the public key in the initial message guessing/hoping that the server will support the algorithm, saving a round trip. As for the data size: generally you'd try and fit things into common MTU's. Although TCP does of course allow any size streams and TLS does in principle support fragmenting, reality is that implementations may still try and use a single packet. And then there is dTLS of course. – Maarten Bodewes Mar 02 '21 at 16:24
  • @MaartenBodewes: as for the initial algorithm guessing, TLS allows the client to send several key shares (with different algorithms);; so you can send both postquantum and conventional ones (of course, the bandwidth used is the total of both). As for data size, with TCP you can send several segments (MTU sizes) at once without waiting for a reply; this means that sending an initial large record is not a problem, as long as you don't go over the TCP window, which might be 10 MTU sizes. Performance tests have shown that this does not cause a significant slowdown. – poncho Mar 02 '21 at 16:37
2

CSIDH can serve as a drop-in replacement for the (EC)DH key-exchange protocol while maintaining security against quantum computer.

Moreover, OQS modified openssl library to use the liboqs. The TLS was modified not following the standards, as you said.

jmr
  • 85
  • 5
  • 1
    Upvoted your answer as CSIDH is a nice addition to my library of algorithms, but I don't see any indication that it has been used for TLS. If that is the case please point it out in the answer. – Maarten Bodewes Mar 02 '21 at 08:30
  • It was proposed an TLS handshake without signatures by using a non-interactive key exchange (NIKE) like CSIDH. – jmr Mar 03 '21 at 22:07
  • 1
    For other readers: non-interactive means **static-static** according to the page defining CSIDH, so it is not the same thing as ephemeral-ephemeral (ECDHE) used for TLS 1.2 and by default in TLS 1.3 (jmr, happy to be corrected on this though). – Maarten Bodewes May 11 '21 at 16:55