Re: [saag] sntrup761x25519-sha512

[John Mattsson <[e-mail]>]

+1 for SECDISPATCH
+1 for Kyber instead
+1 for IND-CCA (unless made specifically for a protocol only needing IND-CPA)

Regarding draft-kampanakis-curdle-ssh-pq-ke: Not sure that there is any reason to standardize P-256, P-384, P-521 anymore when X25519 and X448 are NIST approved and CNSA 2.0 removed P-384. Also, I think the use of SHA-2 makes no sense as Kyber use SHA-3 internally. Why require a second hash function?

My view is that that the only combinations worth doing IETF standards track for are final standardized Kyber with X25519 or X448 and SHAKE.

NTRU and NTRU Prime are not good backup algorithms to Kyber as they also use structured lattices. If IETF wants backup algorithms, then ”FrodoKEM” och "Classic McEliece” recommended by many European countries are more conservative choices. Unfortunately, they are currently being standardized in paywalled ISO, which I think make them unacceptable for use.



(For signatures Sphinx+ is a very conservative alternative to Dilithium and Falcon)

Cheers,
John

From: saag <[e-mail]> on behalf of Eric Rescorla <[e-mail]>
Date: Tuesday, 23 May 2023 at 15:18
To: Simon Josefsson <simon=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [saag] sntrup761x25519-sha512


On Tue, May 23, 2023 at 12:32 AM Simon Josefsson <simon=[e-mail]<mailto:[e-mail]>> wrote:
"Kampanakis, Panos" <kpanos=[e-mail]<mailto:[e-mail]>> writes:

> Hi Simon,
>
> I have asked this question to the ADs 3-4 years back and reopening
> CURDLE was not an option. Introducing PQ algorithms to SSH has also
> been discussed in SAAG before and the outcome was that there is no WG
> to do this work right now. So, imo AD-sponshorship is your only
> option.

Paul, Roman, what is your decision on AD-sponsoring
draft-josefsson-ntruprime-ssh?

If you are asking for AD sponsorship then this should go through th
SECDISPATCH process in SFO. That would structure this discussion
properly.


From your other message:

> One point of my draft is to give IETF change control.  The process was
> the same with RFC 8731 when we documented how Curve25519 was used in
> OpenSSH at the time.  Many implementations (including OpenSSH) now use
> the RFC 8731 algorithm identifier that is under IETF change control.

So to clarify, if the IETF decided to change the use of SNTRU in some way,
for instance, by changing the encoding, then the SSH community would expect
to change over to that code point and use?

-Ekr