Re: [saag] sntrup761x25519-sha512

["Kampanakis, Panos" <[e-mail]>]

Hi John,

+1 on Rene’s comment about X25519 for key agreement. Ed25519 was recently approved for signatures in FIPS 186-5, but not X25519 for key agreement.

+1 on Rene’s comment about removal of P384 too. Maybe after 2033 for CNSA 2.0. But still, for those with FIPS requirements (not selling equipment for NSS systems that need to comply with CNSA) will still need to be using a FIPS-approved curve for a few more years.

We could consider changes to the SSH HASH in draft-kampanakis-curdle-ssh-pq-ke. We could consider other more conservative combinations like X25519+Kyber768 and P256+Kyber768 as the TLS WG is doing. These initial methods were choices we made just for the initial version of the draft.

If only there was a WG where we could converge on these choices and ratify draft draft-kampanakis-curdle-ssh-pq-ke…  😉


From: saag <[e-mail]> On Behalf Of Rene Struik
Sent: Tuesday, May 23, 2023 10:20 AM
To: John Mattsson <john.mattsson=[e-mail]>; Eric Rescorla <[e-mail]>; Simon Josefsson <simon=[e-mail]>
Cc: [e-mail]
Subject: RE: [EXTERNAL][saag] sntrup761x25519-sha512


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Hi John:



To my knowledge, there is no NIST standard that approves the key agreement schemes X25519 and X448. As to CSNA2.0, I am not aware of removal of P-384 either.



If you can provide references to the relevant NIST specification(s), including section numbers, that would be great (I could not find this in [2]. Same for CSNA2.0 (including date of document, etc.).



BTW - Table 2 of [1] recommends use of SHA-384 or SHA-512 for all classification levels.



Ref:

[1] NSA - Announcing the Commercial National Security Algorithm Suite 2.0 (September 7, 2022).

Web link: https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF

[2] NIST SP 800-186 - Recommendations for Discrete Logarithm-Based Cryptography, Elliptic Curve Domain Parameters (NIST, February 3, 2023).

Web link: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186.pdf



Rene



==

[excerpt of email John Mattson, Tue May 23, 2023, 9.57am EDT]

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?
On 2023-05-23 9:57 a.m., John Mattsson wrote:

+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]><mailto:[e-mail]> on behalf of Eric Rescorla <[e-mail]><mailto:[e-mail]>
Date: Tuesday, 23 May 2023 at 15:18
To: Simon Josefsson <simon=[e-mail]><mailto:simon=[e-mail]>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[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





_______________________________________________

saag mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/saag

--

email: [e-mail]<mailto:[e-mail]> | Skype: rstruik

cell: [phone]