3 ms·

NTRU Prime was written by Dan Bernstein, who also had a strong hand in the creation of ed25519 elliptic curve keys, and the chacha20-poly1305 AEAD cipher. http

by chasil 1y ago

NTRU Prime was written by Dan Bernstein, who also had a strong hand in the creation of ed25519 elliptic curve keys, and the chacha20-poly1305 AEAD cipher. https://news.ycombinator.com/item?id=37520065 https://news.ycombinator.com/item?id=37520065 https://www.metzdowd.com/pipermail/cryptography/2016-March/028824.html https://www.metzdowd.com/pipermail/cryptography/2016-March/0... The first version of NTRU Prime in an SSH server was implemented in TinySSH and later adopted by OpenSSH. Bernstein provided new guidance, and OpenSSH developed an updated algorithm that TinySSH implemented in return. The NIST approval process was fraught, and Bernstein ended up filing a lawsuit over treatment that he received. I don't know how that has progressed. https://news.ycombinator.com/item?id=32360533 https://news.ycombinator.com/item?id=32360533 While Kyber may have been the winning algorithm, there will be great preference in the community for Bernstein's NTRU Prime.

tptacek 1y ago
No, there won't. The world will standardize on MLKEM, at least until some important new piece of knowledge is uncovered. The process wasn't at all fraught. Who's the highest-profile cryptographer or cryptography engineer you can think of who took Bernstein's claims about the process seriously?
throw0101a 1y ago
> While Kyber may have been the winning algorithm, there will be great preference in the community for Bernstein's NTRU Prime. There's IETF WG drafts for use of Kyber / ML-KEM, but none for NTRU, so I'm not sure about that: * https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ * https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ * https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-desig... * https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-ml... And given that NTRU made it to the third round, and NTRU Prime is labelled as an alternative, I'm not how strong a claim Bernstein can make to being ill-treated by NIST.
- chasil 1y ago
  The djb suites are well-represented both in TLS and SSH. While NTRU Prime is not implemented in TLS, if it has even half the lifespan of DSA in SSH then it will be quite long lived.
  - throw0101a 1y ago
    The context of the conversation is "Bernstein's NTRU Prime", which is not present for TLS in any draft, and for SSH there are only personal / non-WG drafts. So while some SSH folks just happened to pick NTRU after looking at the options at a particular point in time, some of the other most widely deployed systems (TLS, IPsec) will not be using it. So I'm not quite sure how defendable the "great preference" claim is.
    - chasil 1y ago
      The first SSH server that chose it was TinySSH. Have you ever visited their site? https://tinyssh.org/ https://tinyssh.org/ I use this in a variety of ways, thousands of logins per day. I don't see much love for AES.
      - throw0101a 1y ago
        > The first SSH server that chose it was TinySSH. Yes, I know. I mention this timeline in another one of my comments: * https://news.ycombinator.com/item?id=44866802 https://news.ycombinator.com/item?id=44866802 > I use this in a variety of ways, thousands of logins per day. I don't see much love for AES. So? Given its focus on low(er)-performance systems, perhaps on chips without AES-NI, it's no surprise that TinySSH does not have AES. Further, Dropbear, another implementation often used on smaller footprints, does have AES and recently added ML-KEM: * https://github.com/mkj/dropbear/commit/1748ccae5090d511753c0b659be87ebaa3d69e86 https://github.com/mkj/dropbear/commit/1748ccae5090d511753c0... PuTTY added ML-KEM in 0.83 earlier this year. So I'm not sure how talking about a niche SSH implementation supports your claim that "there will be great preference in the community for Bernstein's NTRU Prime." The evidence appears to me that implementation have been adding NIST's choice(s) since they have become available.

by chasil 1y ago

tptacek 1y ago

No, there won't. The world will standardize on MLKEM, at least until some important new piece of knowledge is uncovered. The process wasn't at all fraught. Who's the highest-profile cryptographer or cryptography engineer you can think of who took Bernstein's claims about the process seriously?

throw0101a 1y ago

> While Kyber may have been the winning algorithm, there will be great preference in the community for Bernstein's NTRU Prime. There's IETF WG drafts for use of Kyber / ML-KEM, but none for NTRU, so I'm not sure about that: * https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ * https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ * https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-desig... * https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-ml... And given that NTRU made it to the third round, and NTRU Prime is labelled as an alternative, I'm not how strong a claim Bernstein can make to being ill-treated by NIST.

chasil 1y ago
The djb suites are well-represented both in TLS and SSH. While NTRU Prime is not implemented in TLS, if it has even half the lifespan of DSA in SSH then it will be quite long lived.
- throw0101a 1y ago
  The context of the conversation is "Bernstein's NTRU Prime", which is not present for TLS in any draft, and for SSH there are only personal / non-WG drafts. So while some SSH folks just happened to pick NTRU after looking at the options at a particular point in time, some of the other most widely deployed systems (TLS, IPsec) will not be using it. So I'm not quite sure how defendable the "great preference" claim is.
  - chasil 1y ago
    The first SSH server that chose it was TinySSH. Have you ever visited their site? https://tinyssh.org/ https://tinyssh.org/ I use this in a variety of ways, thousands of logins per day. I don't see much love for AES.
    - throw0101a 1y ago
      > The first SSH server that chose it was TinySSH. Yes, I know. I mention this timeline in another one of my comments: * https://news.ycombinator.com/item?id=44866802 https://news.ycombinator.com/item?id=44866802 > I use this in a variety of ways, thousands of logins per day. I don't see much love for AES. So? Given its focus on low(er)-performance systems, perhaps on chips without AES-NI, it's no surprise that TinySSH does not have AES. Further, Dropbear, another implementation often used on smaller footprints, does have AES and recently added ML-KEM: * https://github.com/mkj/dropbear/commit/1748ccae5090d511753c0b659be87ebaa3d69e86 https://github.com/mkj/dropbear/commit/1748ccae5090d511753c0... PuTTY added ML-KEM in 0.83 earlier this year. So I'm not sure how talking about a niche SSH implementation supports your claim that "there will be great preference in the community for Bernstein's NTRU Prime." The evidence appears to me that implementation have been adding NIST's choice(s) since they have become available.