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.
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?
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.
Hopefully, the judge will help, as before.
1 reply →