2
$\begingroup$

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?

$\endgroup$
3
$\begingroup$

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.

$\endgroup$
6
  • $\begingroup$ "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? $\endgroup$
    – Maarten Bodewes
    Mar 1 at 21:47
  • 1
    $\begingroup$ @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. $\endgroup$
    – poncho
    Mar 1 at 21:53
  • $\begingroup$ OK, so that leaves basically only the (public key) size issue and hybrid encryption. Oh, and the "guessing" of the algorithm possibly. $\endgroup$
    – Maarten Bodewes
    Mar 2 at 8:32
  • $\begingroup$ @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... $\endgroup$
    – poncho
    Mar 2 at 16:15
  • $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes
    Mar 2 at 16:24
2
$\begingroup$

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.

$\endgroup$
3
  • 1
    $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes
    Mar 2 at 8:30
  • $\begingroup$ It was proposed an TLS handshake without signatures by using a non-interactive key exchange (NIKE) like CSIDH. $\endgroup$
    – jmr
    Mar 3 at 22:07
  • 1
    $\begingroup$ 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). $\endgroup$
    – Maarten Bodewes
    May 11 at 16:55

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.