Kyber-to-ML diff listing?

[Paul Hoffman]

Greetings again. The list traffic makes me think that there are likely to be significant differences between the spec for public comment and the final outcome. Is there a NIST page that is tracking those differences? The most important ones will be bits-on-the-wire, but differences in what what the sender and receiver are expected to do are also important.

If the answer is that there is no NIST page (and none expected), is anyone else keep such a list in a speculative fashion?

--Paul Hoffman

[Mike Ounsworth]

Same question for:

Dilithium_round4 -> ML-DSA-ipd (initial public draft)

 

And I understand that SPHINCS+_round4 and SLH_DSA are identical, but worth mentioning also.

 

---

Mike Ounsworth

-- 

You received this message because you are subscribed to the Google Groups "pqc-forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion on the web visit https://urldefense.com/v3/__https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/74ED1B04-6A72-4D6B-B566-D0C965BAC5AC*40icann.org__;JQ!!FJ-Y8qCqXTj2!dN-Wq6jLkt9UKnnKtX_3duy-Lcie3tIKARoV4yN0fao1GFtaIeZFyzrGImJW8b64IIGwfJH9p_0Xu9EfpYdXo1xynEw$.

Any email and files/attachments transmitted with it 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.

[Markku-Juhani O. Saarinen]

Hi Both,

I'm unsure if you've noticed that each draft standard has a section that documents the differences to the submission documents ("Round 3"). This happens to be Section 1.3 in each specification. If something is missing, it is certainly in the public interest (besides NIST), so please notify this list.

FIPS 203 IPD: Section "1.3  Differences From the CRYSTALS-KYBER Submission"
FIPS 204 IPD: Section "1.3  Differences Between the ML-DSA Standard and CRYSTALS-DILITHIUM"
FIPS 203 IPD: Section "1.3  Differences From the SPHINCS+ Submission"

None of these algorithms are/have been on Round 4. That is for additional key establishment algorithms.

Cheers,

- markku

[Markku-Juhani O. Saarinen]

That last FIPS IPD is 205, of course. https://csrc.nist.gov/pubs/fips/205/ipd

Cheers.

[Falko Strenzke]

It would be great if we could agree on naming scheme for the algorithms according to the draft versions. Then experimental implementations could use these strings to identify algorithm versions. That would facilitate interoperability testing greatly. I would be fine with 

ML-DSA-ipd etc.

for the initial draft versions.

-Falko

Am 30.09.23 um 19:35 schrieb 'Mike Ounsworth' via pqc-forum:

Any email and files/attachments transmitted with it 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. --

You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB5739CF4B061C0716234EACD99FC7A%40CH0PR11MB5739.namprd11.prod.outlook.com.

--

MTG AG
Dr. Falko Strenzke
Executive System Architect

Phone: +49 6151 8000 24
E-Mail: falko.s...@mtg.de
Web: mtg.de


MTG Exhibitions – See you in 2023

---

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email. Unauthorised copying or distribution of this email is not permitted.

Data protection information: Privacy policy

[Bas Westerbaan]

As ML-KEM and the rest aren't final yet, I think it's best to stick with the old names such as Kyber for any preliminary/experimental deployment.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/be11cbab-ce5e-4073-9c94-d0f04f07186d%40mtg.de.

[Falko Strenzke]

I'm not sure about that, as I assume "Kyber" will likely also be understood as referring to the final submission version. This is for instance what seems to have happened with Keccak as opposed to SHA3. I think a naming convention that identifies draft versions unambiguously would be helpful. There are going to be 3 new schemes now, and more to follow, each at least with a final submission version, an initial draft version, and a final version. A further draft version is not impossible, even though probably not planned. That can be enough source for confusion for anyone trying to get two independent implementations to get to work together.

- Falko

Am 02.10.23 um 16:42 schrieb Bas Westerbaan:

[Mike Ounsworth]

My vote / suggestion is:

 

“Dilithium_round1/2/3” -- means “as submitted to roud1/2/3 of the NIST PQC competition”. “Dilithium” is a short-hand for this.

“ML-DSA-ipd” – FIPS 204 Initial Public Draft. Note this matched the PDF file name:

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.ipd.pdf

 

“ML-DSA” – reserved for final FIPS 204.

 

---

Mike Ounsworth

[Falko Strenzke]

Thanks Mike, I'm also fine with these suggestions.

Maybe it makes sense to also agree already now on the labels for further potential NIST draft versions (irrespectively of what is actually the plan by NIST, there will never be a guarantee for the number of drafts). Possibly "pf<YYMM>" for "pre-final <YYMM>", <YYMM> indicating two digit year and two digit month of the publication date.

It would make sense to document this somewhere – given that we have sufficient agreement on the suggested labels. Maybe draft-ar-pquip-pqc-engineers is the right place?

- Falko

Am 02.10.23 um 19:00 schrieb Orie Steele:

+! to these suggestions.

--
Pqc mailing list
P...@ietf.org
https://www.ietf.org/mailman/listinfo/pqc

--

ORIE STEELE
Chief Technology Officer
www.transmute.industries

[Mike Ounsworth]

Hi Falko,

 

To me, the naming issue is transient and will no longer be relevant in a year or two, but the document pqc-for-engineers is meant to be a long-lived document, so I don’t believe this belongs there.

 

I have submitted a pull request to the pquip state-of-protocols-and-pqc readme [1]. Let’s see if Paul and Sofía agree that it belongs there.

 

 

[1]: https://github.com/ietf-wg-pquip/state-of-protocols-and-pqc/pull/25

---

Mike Ounsworth

+! to these suggestions.

 

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/b82ba2bb-5e51-4cc3-91f2-1b1d1d5f08ef%40mtg.de.

[Phillip Hallam-Baker]

The naming issue will not be transient, sorry.

I am planning to ship code this year, it will make use of the interim identifiers. The purpose of my system is to enable people to encrypt data at rest. The long term anchors incorporate a Dilithium signature key and they are intended to be life-long.

Once the code is released, those are going to be facts on the ground that all future implementations will be obliged to deal with.

And I am not the only person in this situation.

A very similar issue happened with BASIC authentication in HTTP. I got food poisoning and was out for two weeks. In that time BASIC was defined and shipped. I wrote the first DIGEST proposal the day I got back. It took five years to get that into the main HTTP spec and by that it was too late because BASIC authentication had moved to HTML password fields which are of course vulnerable to phishing as is any scheme where the password is disclosed in the exchange.

This is of course also how specifications wear out over time. Each extension of functionality demands a new layer of kludge. That is how the Mesh can do more in 30,000 lines of code than PKIX + TLS + CMS + SMTP + lots more. Starting from scratch every 30 years or so allows us to move forward.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB573987F8A602507CFEC11EE79FCBA%40CH0PR11MB5739.namprd11.prod.outlook.com.

[Tim Hollebeek]

The longer we use the wrong name, the less transient this problem will be.  If we don’t switch relatively soon, we might be doomed.

 

As an example, I’ll note that the last time I checked, the term SSL is still more popular than TLS.

 

-Tim

 

+! to these suggestions.

 

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany

--

You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMm%2BLwgNtfMc5-mapnEp9WFOqOirTMXxK%3DM-SSj%3Dsgu5eraDdw%40mail.gmail.com.

[Mike Ounsworth]

Fair points Phillip. Maybe this does warrant a short section on naming in the pqc-for-engineers doc.

 

---

Mike Ounsworth

[Bas Westerbaan]

As an example, I’ll note that the last time I checked, the term SSL is still more popular than TLS.

Is calling TLS, SSL harmful though?

I think it is harmful if the final version of ML-KEM is confused with a draft version of ML-KEM.

Best,

 Bas

[Mitchell]

> is calling TLS, SSL harmful though

Maybe in The 00's?

[Tim Hollebeek]

It still leads to far more confusion than you’d think.

 

Anyway, my point is that terminology is persistent in people’s heads for very, very long periods of time and it is very challenging to change once people start using words a certain way.

 

The faster we can get to the right terminology for transition-related things, then better.  Terminology is already a problem in explaining this problem space to people, and it’s only going to get worse.

 

-Tim

 

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> On Behalf Of Mitchell
Sent: Friday, October 6, 2023 10:01 AM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: Bas Westerbaan <b...@cloudflare.com>
Subject: Re: [Pqc] [EXTERNAL] Re: [pqc-forum] RE: Kyber-to-ML diff listing?

 

> is calling TLS, SSL harmful though

--

You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/f5ef8983-391b-4385-b03e-0af2362f34abn%40list.nist.gov.

[Phillip Hallam-Baker]

I can't see how we can agree on permanent names until NIST are done and they are doing stuff which probably can't be rushed.

I understand where you are coming from, believe me. I have an absolutely pristine design right now with absolutely everything regular and clean. There are large parts unimplemented but those are designed as optional optimizations. And then there is this PQC module that is going to be a carbunkle on the end product for a century.

[Falko Strenzke]

Hi Mike,

in the meantime one change proposed by me was merged:

“Dilithium” is a short-hand for "Dilithium3", the round 3 submission.

Otherwise, with the previous definition 

“Dilithium” is a short-hand for this

it would be ambiguous what "Dilithium" exactly refers to. I hope you are fine with this.

Another finer point is that certain protocols will specify a distinct algorithm identifier for each parameter set. Accordingly, it would still be unclear whether to write "ML-KEM-768-ipd" or "ML-KEM-ipd-768". I would favor the latter (keeping to the version postfix directly after the scheme) and would mention that also on that page. But clearly, this is a minor point and if an implementation chooses the other variant it would still be unambiguous what is meant.

Then it would also be good to have a single test vector for each parameter set for each of the schemes (seed, public key, private key, ciphertext or signature). The purpose of that test vector would merely be to be able to identify resp. verify the algorithm version. I am not sure, however, whether that is still in scope of state-of-protocols-and-pqc or what would be the proper place for it.

- Falko

Am 04.10.23 um 15:44 schrieb Mike Ounsworth:

[Mike Ounsworth]

Hi Falko,

 

Ooo! Yes, I also prefer “ML-KEM-ipd-768” over “ML-KEM-768-ipd”. Good suggestion!

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/55a2deda-4b89-4b13-84a2-7c43f095f6bf%40mtg.de.