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?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
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.

Improve this answer
$\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, 2021 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, 2021 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, 2021 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, 2021 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, 2021 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.

Improve this answer
$\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, 2021 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, 2021 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, 2021 at 16:55

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.