← Back to context

Comment by chasil

3 years ago

The main concern that I have is the NIST refusal to consider a hybrid design as described in the blog, coupled with the fact that OpenSSH has disregarded NIST and standardized on hybrid NTRU-Prime.

There had to be substance to accomplish this, and it moves all of UNIX plus Microsoft away from crystals. It would seem hugely damaging to crystals as the winner of the latest round.

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.

      2 replies →

Repeating this here. We (OpenSSH) have not disregarded NIST, we just added a PQ algorithm before NIST finished their competition and we'll almost certainly add support for the finalist fairly soon.