Comment by tptacek

3 years ago

I don't think you understand what's going on here. The point of the PQC "contest" is to figure out which PQC constructions to use. It's not to design hybrid classical/PQC schemes: everybody already knows how to do that. The idea that NIST should have recommended CRYSTALS-Kyber+Curve25519 is a little like suggesting that they should have recommended Rijndael+DES-EDE.

It's simply not NIST's job to tell tls-wg how to fit PQC into HTTPS, or the OpenSSH team how to fit it into SSH.

If you trust the OpenSSH team more than NIST, that's fine. I think that's a reasonable thing to do. Just do whatever OpenSSH does, and you don't have to worry about how corrupt NIST's process is. I don't even think NIST is corrupt, and I still think you'd be better off just paying attention to whatever OpenSSH does.

4 comments

tptacek

Reply
chasil  3 years ago

That would make it seem that the lengthy hybrid discussion in the blog is a misdirection.

I will grant you that this does support your argument.

EDIT: Actually, what you have said does not seem at all correct.

In DJB's Apon complaint, we find this text:

'For example, in email to pqc-forum dated 30 Oct 2019 15:38:10 +0000 (2019), NIST posted technical comments regarding hybrid encryption modes and asked for feedback “either here on the pqc-forum or by contacting us at pqc-comments@nist.gov” (emphasis added).'

If hybrid encryption is entirely beyond the purview of the NIST PQC competition, then why did this discussion and feedback request ever take place?

  • tptacek  3 years ago

    Look, I'm just not going to dignify the argument that there is somehow some controversy over the NIST PQC contest not recommending higher-level constructions to plug PQC KEMs into Curve25519 key exchanges. I get that this seems like a super interesting controversy to you, because Bernstein's blog post is misleading you, but this simply isn't a real controversy.