Re: [Pqc] Listing pointers to not-yet-standardized PQC algorithms

[Kris Kwiatkowski <[e-mail]>]

Hi,

1. yes. As much as all information can be found in pqc-forum and it is fun to 
follow (for some definition of "fun"), I wouldn't expect protocol developers 
to be up to date. I.e. things like recent modification in Kyber enacps/decaps 
(FO transform), fact that KAT vectors for most recent Dilithium (3.1) are not 
available at NIST pages, that -90s version of Kyber/Dilihtium were never ment 
to be standardized or fact that Falcon has 3 different signature encodings - 
may be not obvious to protocol designers.

2. I vote no.
I can think of one exception - Kyber with 12-round keccak is not going to be a 
NIST standardized, but still may sound interesting for TLS and (maybe), so to 
mention it somewhere makes sense. But in general, I agree with Mike, it sounds 
like never-ending task.

Kind regards,
Kris

On 05/05/2023 09:10, Florence D wrote:
> Hi,
>
> I vote yes to 1. (pointing towards NIST standards and standards in development) and no to 2. (pointing towards other algorithms).
>
> 1. While I agree with Panos that cryptographers are tracking NIST, part of the justification for doing the "PQ for engineers" work in this group is that we don't expect all engineers designing security protocols to be following NIST closely.  I think including a brief description of the current state of play for NIST algorithms (e.g. in the process of being standardised, still being assessed etc.) would be useful, as well as pointers to the latest versions.  The pointers could be to other IETF/IRTF drafts where they exist.  I think this should be short, but something would be better than nothing.
>
> 2. I think we should focus on the NIST algorithms. These have been selected due to their security and usability and these are the features that IETF should be looking for when incorporating algorithms into our protocols.  If we start pointing to other algorithms then this group would need to start weighing up their security and relative merits outside of NIST's process, which is not in our remit.
>
> Also, at Real World PQC Dustin Moody suggested that NIST would be standardising one of BIKE or HQC, but not both.  That might have changed, but we should check before writing anything.
>
> Flo
>
> Florence D
> UK National Cyber Security Centre
>
> -----Original Message-----
> From: Pqc<[e-mail]>  On Behalf Of Mike Ounsworth
> Sent: 04 May 2023 19:12
> To: Kampanakis, Panos<kpanos=[e-mail]>; Paul Hoffman<[e-mail]>;[e-mail]
> Subject: Re: [Pqc] Listing pointers to not-yet-standardized PQC algorithms
>
> I vote no also.
>
> I see this list / github page as an index of *IETF* PQC work. Trying to document the PQC work in general beyond the IETF seems it is both not the IETF's responsibility, as well as a never-ending task.
>
> ---
> Mike Ounsworth
>
> -----Original Message-----
> From: Pqc<[e-mail]>  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, May 3, 2023 8:58 PM
> To: Paul Hoffman<[e-mail]>;[e-mail]
> Subject: [EXTERNAL] Re: [Pqc] Listing pointers to not-yet-standardized PQC algorithms
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
>
> ______________________________________________________________________
> I would vote no to both.
>
> 1. Crypto developers are following NIST's work and there are plenty of resources that explain what these algorithms are. I don't see a benefit in encyclopedically documenting something that have been documented many times before.
>
> 2. Frodo is in the LWE family. It is not RLWE or MLWE, so as a primitive it has less structure and could be assumed to be more conservatively secure, but it is in the lattice family like Kyber. The Frodo public key and ciphertext are pretty big. NIST's schemes offer better size-performance balance and math primitive family diversity. IETF should only go with primitives that make sense for use in its WGs. I am not sure I would pick Frodo over Kyber or BIKE in any use-cases. Personally, I expect and hope that European regulatory bodies will endorse NIST's primitives in the long run as well.
>
>
>
> -----Original Message-----
> From: Pqc<[e-mail]>  On Behalf Of Paul Hoffman
> Sent: Wednesday, May 3, 2023 6:57 PM
> To:[e-mail]
> Subject: [EXTERNAL] [Pqc] Listing pointers to not-yet-standardized PQC algorithms
>
> 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.
>
>
>
> Greetings again. The grand list of pointers at<https://urldefense.com/v3/__https://github.com/ietf-wg-pquip/state-of-protocols-and-pqc__;!!FJ-Y8qCqXTj2!ZIRdEHgW2t4iPCMG1WwqGfi7XfFSSJA-XHtPiDAvekvmrUjKPca5jNo7729Pg7MdVdjIAsnpOsrJV60gByKQ6FAyyqPXQlbvY916$ 
> >  primarily lists Internet Drafts and RFCs.
>
> We know that the protocols themselves are being developed elsewhere, primarily (but not exclusively) at NIST. NIST has said that it will publish standards for CRYSTALS-Kyber, CRYSTALs-Dilithium, Falcon, and SPHINX+ next year, and has more informally said that it will publish standards for other KEM finalists (Classic McEliece, BIKE, and HQC). Should this WG help let IETF developers know about these algorithms and their status at NIST; if so, how?
>
> Those of us following the European PQC world know that there is still a lot of interest in some non-NIST algorithms, particularly FrodoKEM. FrodoKEM is being standardized in ISO. Should this WG let IETF developers know about these algorithms? If so, how do we bound this list to prevent us from promoting MyMostlyUnreviewedKEM without enough context?
>
> --Paul Hoffman
>
> --
> Pqc mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pqc__;!!FJ-Y8qCqXTj2!ZIRdEHgW2t4iPCMG1WwqGfi7XfFSSJA-XHtPiDAvekvmrUjKPca5jNo7729Pg7MdVdjIAsnpOsrJV60gByKQ6FAyyqPXQj4jUzt_$
>
> --
> Pqc mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pqc__;!!FJ-Y8qCqXTj2!ZIRdEHgW2t4iPCMG1WwqGfi7XfFSSJA-XHtPiDAvekvmrUjKPca5jNo7729Pg7MdVdjIAsnpOsrJV60gByKQ6FAyyqPXQj4jUzt_$
> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
>
> --
> Pqc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pqc
>