3 ms·

OpenSSH appears to have disregarded NIST, and made their own determination on a pq-kex. Should NIST be disregarded? NTRU-prime is not a finalist, but OpenSSH

by chasil 4y ago

OpenSSH appears to have disregarded NIST, and made their own determination on a pq-kex. Should NIST be disregarded? NTRU-prime is not a finalist, but OpenSSH has decided that the NIST designation is irrelevant. https://www.openssh.com/releasenotes.html https://www.openssh.com/releasenotes.html ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default ("sntrup761x25519-sha512@openssh.com"). The NTRU algorithm is believed to resist attacks enabled by future quantum computers and is paired with the X25519 ECDH key exchange (the previous default) as a backstop against any weaknesses in NTRU Prime that may be discovered in the future. The combination ensures that the hybrid exchange offers at least as good security as the status quo. We are making this change now (i.e. ahead of cryptographically- relevant quantum computers) to prevent "capture now, decrypt later" attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available.

tptacek 4y ago
I personally think NIST should be disregarded, but you can disregard NIST and still end up with CRYSTALS-KYBER as your default PQC KEM, on its own merits, which can include the fact that NIST's standardization spurs so much implementation of CRYSTALS-KYBER that it becomes a de facto standard in addition to a de jure standard. (Same for signatures, and so on). People with qualms about NIST might also reasonably have qualms about AES. And there is a common cipher that people use outside of AES --- Chapoly. But it would be downright weird to use, like, Serpent or Twofish; it would be the cryptography equivalent of a "code smell". Chapoly and AES are the de facto standards, and OpenSSH supports both. Again though: my question is just, what does this (frankly weird) Bernstein complaint have to do with any of it? Bernstein himself is a NISTPQC participant; he's on one of the (large) winning signature teams. (I think all the technical details here are super interesting, but not especially motivating; I'm not a cryptographer and you should disregard me as well, but my basic take on QC crypto attacks is "Rodents of unusual size? I don't think they exist.")
- chasil 4y ago
  I agree with your sentiment. I wish NIST had conducted the proceedings more professionally, and this collapse in confidence is their own fault. The OpenSSH decision to promote NTRU-prime from an experimental feature to the preferred key exchange was breathtakingly rapid, and final. It is a tacit assertion that NIST is no longer relevant. DJB was on several teams, and I think that OpenSSH would lend greater credence to him than any other council, deservedly so. We might end up with SPHINCS+, but I will be surprised if KYBER is adopted. This moved very fast.
  - tptacek 4y ago
    I don't wish NIST had conducted the proceedings more professionally, not because I'm a nihilist about standards but because I don't know enough to critique how they ran this. I've read the whole post upthread (by the way: if you're scratching your head, the trick is to read the red text, across several pages, all the way through, and then come back and pay attention to the rebuttals you think are interesting) and don't feel any more equipped to say anything about it. What I will say is that a significant chunk of all the world's public key encryption expertise got sunk into this event. One reason KYBER got standardized quickly is that PQC KEMs are time-sensitive if you believe the quantum attack threat is plausibly material within the next 10-15 years. Your adversary in these attacks will almost certainly be state signals intelligence groups, and the expense involved in building attack hardware dwarfs the expense of collecting traffic today to decrypt in 2034. If you're a PQC believer, you want something out the door soon. I don't understand the special sway you think Bernstein has, versus all the other cryptographers that participate in NISTPQC, with the OpenSSH team. I worry that people believe stuff like this because they know who Bernstein is and what OpenSSH is, and don't off the top of their head know who Tancrède Lepoint is. Note also that the KYBER team includes Peter Schwabe, whose name you should definitely know if you're a Bernstan.
    - chasil 4y ago
      The major question will be what ends up in TLS. Aside from adherence to DJB, the question will be what can be trusted? We have been down this road before. https://lwn.net/Articles/681616/ https://lwn.net/Articles/681616/

by chasil 4y ago

tptacek 4y ago

I personally think NIST should be disregarded, but you can disregard NIST and still end up with CRYSTALS-KYBER as your default PQC KEM, on its own merits, which can include the fact that NIST's standardization spurs so much implementation of CRYSTALS-KYBER that it becomes a de facto standard in addition to a de jure standard. (Same for signatures, and so on). People with qualms about NIST might also reasonably have qualms about AES. And there is a common cipher that people use outside of AES --- Chapoly. But it would be downright weird to use, like, Serpent or Twofish; it would be the cryptography equivalent of a "code smell". Chapoly and AES are the de facto standards, and OpenSSH supports both. Again though: my question is just, what does this (frankly weird) Bernstein complaint have to do with any of it? Bernstein himself is a NISTPQC participant; he's on one of the (large) winning signature teams. (I think all the technical details here are super interesting, but not especially motivating; I'm not a cryptographer and you should disregard me as well, but my basic take on QC crypto attacks is "Rodents of unusual size? I don't think they exist.")

chasil 4y ago
I agree with your sentiment. I wish NIST had conducted the proceedings more professionally, and this collapse in confidence is their own fault. The OpenSSH decision to promote NTRU-prime from an experimental feature to the preferred key exchange was breathtakingly rapid, and final. It is a tacit assertion that NIST is no longer relevant. DJB was on several teams, and I think that OpenSSH would lend greater credence to him than any other council, deservedly so. We might end up with SPHINCS+, but I will be surprised if KYBER is adopted. This moved very fast.
- tptacek 4y ago
  I don't wish NIST had conducted the proceedings more professionally, not because I'm a nihilist about standards but because I don't know enough to critique how they ran this. I've read the whole post upthread (by the way: if you're scratching your head, the trick is to read the red text, across several pages, all the way through, and then come back and pay attention to the rebuttals you think are interesting) and don't feel any more equipped to say anything about it. What I will say is that a significant chunk of all the world's public key encryption expertise got sunk into this event. One reason KYBER got standardized quickly is that PQC KEMs are time-sensitive if you believe the quantum attack threat is plausibly material within the next 10-15 years. Your adversary in these attacks will almost certainly be state signals intelligence groups, and the expense involved in building attack hardware dwarfs the expense of collecting traffic today to decrypt in 2034. If you're a PQC believer, you want something out the door soon. I don't understand the special sway you think Bernstein has, versus all the other cryptographers that participate in NISTPQC, with the OpenSSH team. I worry that people believe stuff like this because they know who Bernstein is and what OpenSSH is, and don't off the top of their head know who Tancrède Lepoint is. Note also that the KYBER team includes Peter Schwabe, whose name you should definitely know if you're a Bernstan.
  - chasil 4y ago
    The major question will be what ends up in TLS. Aside from adherence to DJB, the question will be what can be trusted? We have been down this road before. https://lwn.net/Articles/681616/ https://lwn.net/Articles/681616/