Announcement of the 3rd Round Onramp Candidates

[dustin...@nist.gov]

Nine Candidates Advance to the Third Round of the Additional Digital Signatures for the PQC Standardization Process

 After 18 months of evaluation, NIST has selected nine candidates for the third round of the Additional Digital Signatures for the Post-Quantum Cryptography (PQC) Standardization Process. The advancing digital signature algorithms are:

• FAEST
• HAWK
• MAYO
• MQOM
• QR-UOV
• SDitH
• SNOVA
• SQIsign
• UOV

NIST Internal Report (IR) 8610 describes the evaluation criteria and selection process. These third-round candidates will have the opportunity to submit updated specifications and implementations (i.e., “tweaks”). NIST will provide more details to the submission teams in a separate message. This third phase of evaluation and review is expected to last approximately two years.

 NIST is also planning to hold the 7^th NIST PQC Standardization Conference in the late spring/early summer of 2027. The conference will most likely be held in (or near) Gaithersburg, Maryland.

 Questions may be directed to pqc-co...@nist.gov. NIST thanks all of the candidate submission teams for their efforts in this standardization process as well as the cryptographic community at large, which helped analyze the signature schemes.

The NIST PQC team

[Thom Wiggers]

Hi all,

Thanks NIST PQC team! I’d honestly thought that this would take a little bit longer still. 

Coincidentally, I have been at work updating our signatures zoo comparison tool. I’ve now added a round-3 page.

https://pqshield.github.io/nist-sigs-zoo/?r=3

I am very pleased to announce that you can now zoom on the graph—Claude is clearly much better at javascript than me.

Cheers,

Thom

(PS. I’d like to invite scheme submitters to open PRs (https://github.com/pqshield/nist-sigs-zoo/) or issues with a link to any and all updated versions as they have them — that’d be a great help to keep track of things and show the latest state of the game.)

--
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 visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/5e07130a-10b4-429e-bd6d-44b5b8a48996n%40list.nist.gov.

[John Mattsson]

Thanks for your hard work!

I think this is a very good selection. It is appropriate to narrow the set of algorithms and focus on a smaller number of candidates, 2035 is only nine years away. I appreciate the clear statement that NIST targets the robust SUF-CMA notion for all general-purpose signatures.

The report states that “NIST anticipates a longer timeline for the potential standardization of any of these multivariate schemes and is unlikely to standardize them without a further round of evaluation.”

Does this imply that NIST may consider standardizing MPC-in-the-Head, lattice-based, or isogeny-based schemes without an additional evaluation round? Given the statement that “a primary challenge for HAWK and SQIsign will be a more complete understanding of their relatively novel security assumptions,” I assume that NIST is primarily considering the potential standardization of MPC-in-the-Head schemes without a further round of evaluation, contingent on receiving sufficient additional analysis of their complex designs and security proofs.

Cheers,

John Preuß Mattsson

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/BE77A4D3-AC00-41B8-9406-BAEC561F1F54%40thomwiggers.nl.

[Daniel Apon]

Cheers, team

John-- What I read from the statement "A primary challenge for HAWK and SQIsign will be a more complete understanding of their relatively novel security assumptions" is that a more complete understanding of HAWK's and SQIsign's relatively novel security assumptions will be a primary challenge.

That sounds like it's work up to the international research community, not NIST, to perform. And NIST would adjudicate.

Best
--Daniel

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/AS4PR07MB8825582786AADC06398BEA8589042%40AS4PR07MB8825.eurprd07.prod.outlook.com.

[Bo Lin]

NIST team,

Thanks for the great effort!

I'd like to contribute the following tables to the community with the hope to facilitate future discussion.

1. Key size, signature size and common application payload size

Total sizes for Level 1 security are ranked as follows and ML-DSA-44 is added and highlighted for comparison.

Rank	Algorithm	pk (B)	sig (B)	Total (B)
1	SQIsign‑I	64	148	212
2	HAWK‑512	1,024	555	1,579
3	ML‑DSA‑44	1,312	2,420	3,732
4	MQOM	3,584	1,024	4,608
4	SDitH	3,584	1,024	4,608
4	SNOVA	3,584	1,024	4,608
7	QR‑UOV	4,096	1,024	5,120
7	UOV	4,096	1,024	5,120
9	FAEST‑128f	32	5,956	5,988
10	MAYO‑five	5,554	964	6,518

Signature schemes are commonly used in authentication and identification. The following table provides commonly used application payload sizes:

Protocol	Max App Payload (bytes)	Notes
IPv4 + TCP	1460	Most common MSS
IPv4 + UDP	1472	Max UDP payload
Pv6 + TCP	1440	IPv6 header is larger
IPv6 + UDP	1452	Max UDP payload
ISO/IEC 7816 (Short APDU)	256	payment cards and SIM cards
ISO/IEC 7816 (Extended APDU)	65536 (optional)	ISO/IEC 7816 is used beyond smart cards

Just an extra note on ISO 7816 - it is used by smart cards, IoT, e-passports, e-ID, health care, wallets, almost everything without an Ethernet interface.

2. Performance (from submission documents and NIST PQC Signature Zoo)

It is important to note that performance figures are only for reference, because these figures are mostly from high-performance x86 CPUs. In practice, if a scheme is very attractive, hardware implementation will be realized as we have seen those happened to RSA and ECC. An efficient hardware implementation with tiny or small silicon footprint is very much desirable. 

As a rule of thumb, if a scheme's performance is comparable with RSA 2048, its performance should be fit for most existing applications. Surely, its size should fit as well.

High‑level ranking by signing speed (fast → slow, Level‑1‑ish sets)
Rank (sign)	Scheme / parameter (≈Level 1)	Family	Sign speed (relative)	Verify speed (relative)
1	HAWK‑512	Lattice	Very fast	Fast–moderate
2	MAYO‑two	Multivariate	Fast	Very fast
3	ML‑DSA‑44	Lattice	Fast–moderate	Fast
4	MQOM	MPC‑in‑the‑Head	Moderate	Moderate
4	SDitH	MPC‑in‑the‑Head	Moderate	Moderate
4	SNOVA	Multivariate	Moderate	Moderate
4	QR‑UOV	Multivariate	Moderate	Moderate
4	UOV	Multivariate	Moderate	Moderate
9	SQIsign‑I	Isogeny	Slow	Slow–moderate
10	FAEST‑128f / EM‑128f	MPC‑in‑the‑Head	Slow–very slow	Slow–very slow

Signing Performance
Rank	Scheme (≈Level 1)	Family	Sign cycles (approx.)	Notes
1	HAWK‑512	Lattice	~8×10⁴	One of the fastest PQ signatures ever published
2	MAYO‑two	Multivariate	~3–4×10⁵	Very fast, especially for a multivariate scheme
3	ML‑DSA‑44	Lattice	~2.8×10⁵	Matches Dilithium‑2 performance
4	MQOM	MPC‑in‑the‑Head	~1–5×10⁶	Middle‑tier MPCitH performance
4	SDitH	MPC‑in‑the‑Head	~1–5×10⁶	Similar to MQOM
4	SNOVA	Multivariate	~1–5×10⁶	Moderate signing cost
4	QR‑UOV	Multivariate	~1–5×10⁶	Classic UOV‑style cost
4	UOV	Multivariate	~1–5×10⁶	Similar to QR‑UOV
9	SQIsign‑I	Isogeny	~5–10×10⁶	Very small signatures but slower signing
10	FAEST‑128f	MPC‑in‑the‑Head	~1.7×10⁶	Fastest FAEST variant
10	FAEST‑128s	MPC‑in‑the‑Head	~1.3×10⁷	Slowest FAEST variant

Verification Performance
Rank	Scheme (≈Level 1)	Family	Verify cycles (approx.)	Notes
1	MAYO‑two	Multivariate	~1×10⁵	Extremely fast verification
2	HAWK‑512	Lattice	~1.5×10⁵	Very efficient
3	ML‑DSA‑44	Lattice	~1.1×10⁵	Dilithium‑class verify speed
4	MQOM	MPC‑in‑the‑Head	~1–5×10⁶	Middle tier
4	SDitH	MPC‑in‑the‑Head	~1–5×10⁶	Similar to MQOM
4	SNOVA	Multivariate	~1–5×10⁶	Moderate
4	QR‑UOV	Multivariate	~1–5×10⁶	Moderate
4	UOV	Multivariate	~1–5×10⁶	Moderate
9	SQIsign‑I	Isogeny	~3–6×10⁶	Verification faster than signing but still slow
10	FAEST‑128f	MPC‑in‑the‑Head	~1.4×10⁶	Fastest FAEST verify
10	FAEST‑128s	MPC‑in‑the‑Head	~1.0×10⁷	Slowest FAEST verify

I hope the above tables help for the future discussion.

Best regards,

Bo LIN

--

[wa...@beullens.com]

@Bo Lin: Did you use a LLM to hallucinate these tables?

@Everyone else: please disregard this.

 

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> On Behalf Of Bo Lin
Sent: Monday, 25 May 2026 12:59
To: dustin...@nist.gov <dustin...@nist.gov>
Cc: pqc-forum <pqc-...@list.nist.gov>
Subject: Re: [pqc-forum] Announcement of the 3rd Round Onramp Candidates

 

NIST team,

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAL3OXVwMHbp%2BpVMJPbB%3DNtYqgyXqA5LqzpV_ky%2BbsUH9ZiKnHw%40mail.gmail.com.

[Sebastien Riou]

Dear NIST,

I noticed that performance measurements focus mainly on 'average' execution time (in discussions, in academic papers, and in commercial datasheets). For operations like ML-DSA sign, this is far from telling the full story and people who rely on 'average' to select the algorithm, the parameter set and the implementation are going to have problems when they finally realize that from time to time the operation is many times slower. 

Average is probably fine in many applications but definitely not for the few that have real time constraints. For that reason, I suggest that algorithm / implementation submitters document the execution time for a worst case scenario. Ideally, we would know for each implementation the average execution time (long term average, i.e., what you get over millions of signatures) and the worst execution time that can occur with a probability of 2^-48. That said, 2^-48 maybe too hard to get in practice, so we may settle for something more accessible such as 2^-32.

A paper discussing the difficulty of benchmarking ML-DSA will be published soon, meanwhile you can refer to those slides  if you want more information on the problem. For ML-DSA, I published test vectors with probability of 2^-37 here (the slides present results on few bare metal SW libraries).

Best regards,

Sebastien Riou

Fellow, Product Security Architecture

PQShield Ltd

 

M:             +33 782 320 285

E:              sebasti...@pqshield.com

W:             www.pqshield.com

[Bo Lin]

@ward: LLM was used to collect figures for the candidates. Protocol payload sizes are known to me. ML-DSA size figures are in the standard and I coded it myself.

Is there anything wrong with some figures? It would be good to be specific, so I can double check them and correct them.

Thanks

[John Mattsson]

Hi Sebastian,

 

I fully agree with this point, and I have made a similar comment on the forum before. The essential security property of availability (the “A” in the CIA triad) is unfortunately often overlooked.

 

High availability is commonly expressed in terms of “nines”. For example, five nines (99.999%) is often used in telecom systems, while more extreme discussions sometimes go up to nine nines (99.9999999%), which is approximately 2^-30.In practice, I do not think availability requirements beyond this level are meaningful for most systems.

 

Under strict high-availability constraints, the worst-case signing time of ML-DSA exceeds that of SLH-DSA, due to its variable-time rejection sampling behavior. That said, a high-availability system can maybe mitigate this in practice by running multiple implementations in parallel or otherwise parallelizing signing operations, thereby reducing effective tail latency.

 

If only a single performance metric is reported, I do not think P50 is the best choice. It would be more informative to report P99, P99.9, or similar tail latencies.

 

Cheers,
John Preuß Mattsson

--
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 visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMoO_M1_6rs-t75LzvKhO0vz5n1LO6idN3a-AqHb1F2PK-zmRQ%40mail.gmail.com.

[Blumenthal, Uri - 0553 - MITLL]

@ward: Did you find any errors in the tables Bo Lin posted? If so - why didn’t you point them out here? If not - guess whose post qualifies as “hallucination” and noise. 

Besides, what do you care how those tables were collected? Next, you’ll object to results provided by a web search, and insist that they are taken only from the actual printed-on-paper material?

@Everyone else: you don’t need me to decide what to do. 

—

Regards,

Uri

Secure Resilient Systems and Technologies

MIT Lincoln Laboratory

On May 25, 2026, at 09:27, ward via pqc-forum <pqc-...@list.nist.gov> wrote:



@ Bo Lin: Did you use a LLM to hallucinate these tables? @Everyone else: please disregard this. From: pqc-forum@ list. nist. gov <pqc-forum@ list. nist. gov> On Behalf Of Bo Lin Sent: Monday, 25 May 2026 12: 59 To: dustin. . . @ nist. gov <dustin. moody@ nist. gov>

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside the Laboratory.

 

ZjQcmQRYFpfptBannerEnd

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/009c01dcec4a%24175bf5f0%244613e1d0%24%40beullens.com.

[Krijn Reijnders]

It is clear that the numbers in table 1 are hallucinated: they dont make any sense for the multivariate ones, which have larger public keys and smaller signatures. Simply check https://pqshield.github.io/nist-sigs-zoo/ if you want the proper numbers for this. It also mixes up a level 5 for Mayo in there.

(I haven't checked the other tables).

[wa...@beullens.com]

Ok, I should probably have mentioned more explicitly that, yes, the tables in Bo Lin’s email are hallucinated AI slop and the majority of the values in them are wrong.  
  

.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/34009E4E-571D-4FF5-855E-BA3C40FDCB1B%40ll.mit.edu.

[Demi Marie Obenour]

On 5/25/26 11:05, 'John Mattsson' via pqc-forum wrote:
> Hi Sebastian,
>
> I fully agree with this point, and I have made a similar comment on the forum before. The essential security property of availability (the “A” in the CIA triad) is unfortunately often overlooked.
>
> High availability is commonly expressed in terms of “nines”. For example, five nines (99.999%) is often used in telecom systems, while more extreme discussions sometimes go up to nine nines (99.9999999%), which is approximately 2^-30.In practice, I do not think availability requirements beyond this level are meaningful for most systems.
>
> Under strict high-availability constraints, the worst-case signing time of ML-DSA exceeds that of SLH-DSA, due to its variable-time rejection sampling behavior. That said, a high-availability system can maybe mitigate this in practice by running multiple implementations in parallel or otherwise parallelizing signing operations, thereby reducing effective tail latency.
>
> If only a single performance metric is reported, I do not think P50 is the best choice. It would be more informative to report P99, P99.9, or similar tail latencies.

Could FN-DSA be tweaked to not need rejection sampling at all?
--
Sincerely,
Demi Marie Obenour (she/her/hers)

[Sebastien Riou]

Hi John,

I fully agree with this point, and I have made a similar comment on the forum before.

Thanks.

High availability is commonly expressed in terms of “nines”. For example, five nines (99.999%) is often used in telecom systems, while more extreme discussions sometimes go up to nine nines (99.9999999%), which is approximately 2^-30.In practice, I do not think availability requirements beyond this level are meaningful for most systems.

In real time systems (which are deployed probably in billions), when a task does not complete within its time budget it is considered as a failure. In automotive, this is expressed in terms of "FIT" (failure per billion hours of operation). I have run the calculations in the table below:

In conclusion, a task which has a probability of failure of 2^-37 ends up being severely rate limited by its FIT budget rather than its actual execution time.

I validated this approach with an automotive expert.

So I concluded that 2^-37 is actually not enough for some use cases. The table below show that the sweet spot is around 2^-48:

(still assuming 1% of total FIT budget is allocated to the task performing the signature)

I believe that beyond automotive, many systems that move have a need for bounded execution times or at least bounded probabilities of time out.    

Under strict high-availability constraints, the worst-case signing time of ML-DSA exceeds that of SLH-DSA, due to its variable-time rejection sampling behavior.

This is debatable depending on the parameter set, hardware platform, but, above all, depending on the number of repetitions that you consider 'worst case' (FIPS-204's 814 repetitions achieve a 2^-256 probability, I think this is over the top for WCET computations). Having the data for 2^-32 for in all benchmarks is a low hanging fruit and would already provide a good indication. Adding another data point somewhere between 2^-40 and 2^-48 would solve the problem for most use cases I guess. 

That said, a high-availability system can maybe mitigate this in practice by running multiple implementations in parallel or otherwise parallelizing signing operations, thereby reducing effective tail latency.

Indeed, I expect this type of solution to be implemented in some systems. Unfortunately many real time systems happens to be constrained in terms of implementation footprint and/or power consumption. Anyway, this is a solution, my point is that NIST and implementers should make the problem visible and take it into account for selecting a winner. Beyond the competition, having a standard metric for 'the worst case' would benefit everyone.

Best regards,

Sebastien Riou

Fellow, Product Security Architecture

PQShield Ltd

 

M:             +33 782 320 285

E:              sebasti...@pqshield.com

W:             www.pqshield.com

[Demi Marie Obenour]

I wonder if Raccoon's parameters could be tweaked to get fully deterministic
execution time. Raccoon is designed to be masking-friendly as well.

[John Mattsson]

Ericsson recently suggested that  NIST should develop a similar publication to SP 800-227 Recommendations for Key-Encapsulation Mechanisms, but for signature schemes.

https://emanjon.github.io/NIST-comments/2026%20SP%20800-230%20IPD.pdf

Variable time signatures is another new and important characteristics that users should be aware of, and that warrant additional guidance from NIST. 

Cheers,

John Preuß Mattsson

-- 

[si...@hoerder.net]

On 26 May 2026, at 10:10, 'John Mattsson' via pqc-forum <pqc-...@list.nist.gov> wrote:



Ericsson recently suggested that  NIST should develop a similar publication to SP 800-227 Recommendations for Key-Encapsulation Mechanisms, but for signature schemes.

https://emanjon.github.io/NIST-comments/2026%20SP%20800-230%20IPD.pdf

Variable time signatures is another new and important characteristics that users should be aware of, and that warrant additional guidance from NIST. 

Cheers,

John Preuß Mattsson

Hi,

I completely agree.

In a safety context, I expect that the system will have a timer enforcing a time-out on probabilistic run-time signatures with the time-out parameter being determined by implementation specific safety considerations, not by cryptographic considerations. If the crypto implementation fails to produce a signature within the given time frame, safety measures will kick in. 

I haven’t seen any evidence that the loop bounds from Appendix C in FIPS 204 can lead to a satisfactory worst-case run time: First of all, test vectors that enable show-casing worst-case run-time under those bounds are missing (to the best of my knowledge) and secondly, the safety time-out is expected to come before the bounds are reached with the consequence that signature generation has failed.

Depending on NIST’s guidance (and above mentioned implementation specific safety considerations) the safety engineer may either decide to choose the timeout such that they have time to restart the computation from scratch at least once and hope for a better outcome or, if that is not possible, directly engage the mechanisms for a communication failure. However, clear guidance will be needed and safety engineers don’t necessarily know about CMVP guidance and this mailing list. A SP800 dedicated to PQC signatures is easier to find.

Best,

Simon

[Demi Marie Obenour]

Another option is to use KEM-based protocols that do not need signatures.

That said, I think this is an area where tweaking parameters could have
a very significant positive outcome.

[Blumenthal, Uri - 0553 - MITLL]

> Another option is to use KEM-based protocols that do not need signatures.

>

> T hat said, I think this is an area where tweaking parameters could have

> a very significant positive outcome.

Regarding use of KEM-based protocols, I strongly agree with Demi: the tradition of implicit authentication based on Key Exchange goes back to MQV/HMQV family of protocols. At IETF there are a few proposals under consideration, that do exactly that.

Thanks

--

V/R,

Uri

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                C. A. R. Hoare

[Bo Lin]

Hi, all,

I'm terribly sorry to use the LLM generated tables in my previous post that caused unnecessary confusion. I manually checked the size-table figures and re-post here. Those performance tables can be discarded (I explained it in #2).

My original post wanted to make the following two points:

1. key size and signature size of a scheme should considered against IP packet size and ISO 7816 APDU payload size which is like that 

Protocol	Max App Payload (bytes)	Notes
IPv4 + TCP	1460	Most common MSS
IPv4 + UDP	1472	Max UDP payload
Pv6 + TCP	1440	IPv6 header is larger
IPv6 + UDP	1452	Max UDP payload
ISO/IEC 7816 (Short APDU)	256	payment cards and SIM cards
ISO/IEC 7816 (Extended APDU)	65536 (optional)	ISO/IEC 7816 is used beyond smart cards

They cover most of our real life applications.

The key sizes and signature sizes of the nine candidates and FIPS 204 can be listed as 

Rank

Algorithm

pk (B)

sig (B)

Total (B)

1	SQIsign‑I	65	148	213
2	SNOVA	1,016	248	1,264
3

HAWK‑512

1,024

555

1,579

4	MQOM	52	2,868	2,920
5

ML‑DSA‑44

1,312

2,420

3,732

6	SDitH	70	3,750	3,820
7

FAEST‑128f

32

5,956

5,988

8

MAYO‑five

5,554

964

6,518

9	QR‑UOV	24,225	200	24,425
10	UOV	278,432	128	278,560

They are ranked in total size and for those which have multiple parameter sets to improve performance, the minimum set is chosen. I'll provide my point of view on performance in #2. In real applications, key size and signature size should be considered separately because message on their direction may be very different, also the channel conditions.

2. I thought about it and the performance figure tables in my previous post could not make my point and performance figures are everywhere. What I would like to say is that we not only need to consider software implementation performance but also need to take silicon area into account, especially for those schemes with small key size and small signature size. 

In general, RSA 2048 can be a good yardstick for further discussion because everyone has one or two RSA engines in their pocket.

Finally, thanks to @wa...@beullens.com to point out the mistake and to all the others who made constructive comments.

Best regards,

Bo LIN

[Sofi Celi]

Dear, all,

@Bo Lin, several of the values still look very off to me (for MQOM, SDitH, SNOVA, UOV, FAEST‑128f, FAEST‑128s, and MAYO (from memory, so worth double-checking against the specs)). More importantly, the table mixes security levels across schemes: the set listed as "MAYO-five" is a Level 5 parameter set, not Level 1 (https://pqmayo.org/params-times/), so ranking it alongside ML‑DSA‑44 at Level 1 isn't a like-for-like comparison.

The broader point: an LLM-generated table, even one that gets some values right, isn't a sound basis for a comparison like this. Each entry needs to be sourced from the submission specs, and ideally fixed at a single security level before ranking.

The assumptions in regards to TCP/UPD and IPv4, etc. seem to also be too handwavy, as well. 

The wider issue is that posting unverified, LLM-generated numbers and/or tables to this list creates work for everyone who then has to check them, and risks those figures being cited downstream as if they were authoritative. I'd ask that values be sourced from the submission specs before being shared here.

Thank you,

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAL3OXVz_dXa7eoqvOxKaNX9C7TmyFPz9a_8uCBjHqERuZ17L2A%40mail.gmail.com.

--

Sofía Celi
@claucece
Cryptographic research and implementation at many places, but specially at Brave

Reach me out at: cher...@riseup.net
74BE 6517 031D 11CC D233  3FCA 44DF 95B9 E3BC 4369

[Nadim Kobeissi]

According to GPTZero, this reply to an “LLM-generated table” was itself LLM-generated. I wonder where our field is going...

Nadim Kobeissi
Symbolic Software • https://symbolic.software

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAHy9yiysOii4PcGgnTQwRmmuTO_YXWb5A6SHW%2B3B9zyVABLPBg%40mail.gmail.com.

[Nadim Kobeissi]

Source: https://app.gptzero.me/documents/12555c20-5a6f-4649-860a-eb5d53fa3a6c

Nadim Kobeissi
Symbolic Software • https://symbolic.software

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/F55F43F6-2C58-4DBA-A176-AD12A30759CD%40symbolic.software.

[Sofi Celi]

Dear, Nadim,

Thank you for scanning and uploading emails/documents to cloud-based tools. To clarify, I did not use an LLM in preparing this — but even if I had, the point would stand on its own merits. I remain unpersuaded by your reasoning here.

Given prior experience, I'll keep this discussion on the list rather than continue it privately. If anyone wishes to contest the substance — specifically the MAYO security-level comparison or the individual parameter values — I'd be glad to work through it against the submission specifications.

BTW, in this email, I made an LLM to make the email sound LLM. Hope this helps your pursuit and work of uploading emails/documents to AI-checkers cloud-based tools ;)

Thank you,

[Nadim Kobeissi]

I was more making a comment about the state of the field at large, which is definitely being impacted by LLM use. No need to get upset.

Nadim Kobeissi
Symbolic Software • https://symbolic.software

[Gustavo Banegas]

Honestly, it is not only our field. Every other field (not only
technology) is suffering from the same problem.

Anyway, I guess that maybe we should fix the table in a proper way, so,
I believe we should ignore the table from Bo Lin since we can see that
is not well made.

All the best,

Gustavo

ps: No, I didn't use LLM preparing this too.

>>>> <mailto:wa...@beullens.com> to point out the mistake and to

>>>> Signature Zoo <https://pqshield.github.io/nist-sigs-zoo/>)

>>>> *Nine Candidates Advance to the Third Round of the

>>>> Additional Digital Signatures for the PQC

>>>> Standardization Process*
>>>>
>>>> **After 18 months of evaluation, NIST has selected

>>>> nine candidates for the third round of the
>>>> Additional Digital Signatures for the Post-Quantum
>>>> Cryptography (PQC) Standardization Process.

>>>> <https://csrc.nist.gov/projects/pqc-dig-sig>The

>>>> advancing digital signature algorithms are:
>>>>
>>>>

>>>> * FAEST
>>>> * HAWK
>>>> * MAYO
>>>> * MQOM
>>>> * QR-UOV
>>>> * SDitH
>>>> * SNOVA
>>>> * SQIsign
>>>> * UOV

>>>>
>>>>
>>>> NIST Internal Report (IR) 8610

>>>> <https://csrc.nist.gov/pubs/ir/8610/final> describes

>>>> the evaluation criteria and selection process.
>>>> These third-round candidates will have the
>>>> opportunity to submit updated specifications and
>>>> implementations (i.e., “tweaks”). NIST will provide
>>>> more details to the submission teams in a separate
>>>> message. This third phase of evaluation and review
>>>> is expected to last approximately two years.
>>>>

>>>> NIST is also planning to hold the 7^th  NIST PQC

>>>> Standardization Conference in the late spring/early
>>>> summer of 2027. The conference will most likely be
>>>> held in (or near) Gaithersburg, Maryland.
>>>>
>>>> Questions may be directed to pqc-co...@nist.gov.
>>>> NIST thanks all of the candidate submission teams
>>>> for their efforts in this standardization process
>>>> as well as the cryptographic community at large,
>>>> which helped analyze the signature schemes.
>>>>
>>>>
>>>> The NIST PQC team
>>>>
>>>>
>>>> --
>>>> 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 visit
>>>> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/5e07130a-10b4-429e-bd6d-44b5b8a48996n%40list.nist.gov

>>>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/5e07130a-10b4-429e-bd6d-44b5b8a48996n%40list.nist.gov?utm_medium=email&utm_source=footer>.

>>>>
>>>>
>>>> --
>>>> 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 visit

>>>> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAL3OXVz_dXa7eoqvOxKaNX9C7TmyFPz9a_8uCBjHqERuZ17L2A%40mail.gmail.com
>>>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAL3OXVz_dXa7eoqvOxKaNX9C7TmyFPz9a_8uCBjHqERuZ17L2A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>>>
>>>>
>>>>
>>>> --
>>>> Sofía Celi
>>>> @claucece
>>>> Cryptographic research and implementation at many places, but
>>>> specially at Brave
>>>> Reach me out at: cher...@riseup.net
>>>> 74BE 6517 031D 11CC D233 3FCA 44DF 95B9 E3BC 4369
>>>>
>>>> --
>>>> 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 visit
>>>> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAHy9yiysOii4PcGgnTQwRmmuTO_YXWb5A6SHW%2B3B9zyVABLPBg%40mail.gmail.com

>>>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAHy9yiysOii4PcGgnTQwRmmuTO_YXWb5A6SHW%2B3B9zyVABLPBg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>>
>>>
>>> --
>>> 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 visit

>>> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/F55F43F6-2C58-4DBA-A176-AD12A30759CD%40symbolic.software
>>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/F55F43F6-2C58-4DBA-A176-AD12A30759CD%40symbolic.software?utm_medium=email&utm_source=footer>.

>>
>>
>>
>> --
>> Sofía Celi
>> @claucece
>> Cryptographic research and implementation at many places, but
>> specially at Brave
>> Reach me out at: cher...@riseup.net
>> 74BE 6517 031D 11CC D233  3FCA 44DF 95B9 E3BC 4369
>
> --
> 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 visit

> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/547A1CC1-A2A6-4DA3-B930-0D6FA371672D%40symbolic.software
> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/547A1CC1-A2A6-4DA3-B930-0D6FA371672D%40symbolic.software?utm_medium=email&utm_source=footer>.

[Nadim Kobeissi]

Thankfully, tools like GPTZero are getting pretty accurate, so it becomes possible to check if someone did indeed use an LLM, even when they claim they’re not!

Sentences highlighted in yellow are obviously LLM-generated to anyone with experience, I leave the judgement to the reader:

https://app.gptzero.me/documents/12555c20-5a6f-4649-860a-eb5d53fa3a6c

Nadim Kobeissi
Symbolic Software • https://symbolic.software

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/a0e2f9ec-50ab-454b-a858-f76be07f0141%40cryptme.in.

[Sofi Celi]

Dear all,

First off, Nadim — thanks for keeping me honest! You're absolutely right, and I really appreciate the accountability. Upon reflection, I did use an LLM to help me structure and articulate some of my earlier points. I should have been more transparent about that from the start, and I take full responsibility.

Moving forward, I commit to being more mindful about attribution and transparency. Thank you all for this valuable learning experience — this is exactly the kind of constructive dialogue that makes this community so special. This is truly an exceptional community.

Warmest regards,

Sofía or an LLM or Ward?  ;) x)

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/C4E5296C-44C4-48BB-A6C6-80D459893FD7%40symbolic.software.

[Nadim Kobeissi]

Hi Sofia,

Look, the point that I was trying to make was sincerely just pushing back against the (minor!) hypocrisy of using an LLM to call someone out for using an LLM.

I have no problems with using LLMs and use them myself at work (hopefully responsibly.)

I think Bo Lin’s use was obviously irresponsible since it produced incorrect data, and that your use wasn’t irresponsible. It was simply a bit off-putting to see clearly LLM-generated prose used to critique LLM use.

I know that I can be abrasive when pointing out inconsistent behavior, and so I am sorry for that, and I appreciate your patience with me. In the context of my mild abrasiveness, your mildly irreverent reply is totally justified.

Nadim Kobeissi
Symbolic Software • https://symbolic.software

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAHy9yiyaopUxXft1srfdN-Q-jx16MJKp0gj6eQ8j297jbvxDLA%40mail.gmail.com.

[Gustavo Banegas]

Hi all,

ok, after searching the websites and etc. Now, the table has all the
"NIST Security level I" or most related to this one:

| Rank | Algorithm  |  pk (B) | sig (B) | Total (B) | source |
| ---- | ---------- | ------: | ------: | --------: |--------: |
| 1    | SQIsign-I  |      65 |     148 |       213 | https://sqisign.org/ |

| 2    | SNOVA      |   1,016 |     248 |     1,264 |

https://snova.pqclab.org/ |
| 3    | HAWK-512   |   1,024 |     555 |     1,579 |
https://hawk-sign.info/ |
| 4    | *MAYO-one*  | *1,420*   |     *454* |     *1,874* |
https://pqmayo.org/params-times/ |
| 5    | MQOM       |      52 |   2,868 |     2,920 | https://mqom.org/ |
| 6    | ML-DSA-44  |   1,312 |   2,420 |     3,732 |
https://openquantumsafe.org/liboqs/algorithms/sig/ml-dsa.html |
| 7    | SDitH      |      70 |   *3,705* |     *3,775* |
https://sdith.org/ |
| 8    | FAEST-128f |      32 |   *5,924* |     *5,956* |
https://faest.info/ |
| 9    | QR-UOV     |  24,225 |     200 |    24,425 |
https://info.isl.ntt.co.jp/crypt/qruov/files/qruov_Spec-v2.0.pdf Table 5 |

| 10   | UOV        | 278,432 |     128 |   278,560 |

https://www.uovsig.org/ |

>>>>>>        Pv6 + TCP1440IPv6 header is larger
>>>>>>        IPv6 + UDP1452Max UDP payload
>>>>>>        ISO/IEC 7816
>>>>>>        (Short APDU)256payment cards and SIM cards
>>>>>>        ISO/IEC 7816
>>>>>>        (Extended APDU)65536 (optional)ISO/IEC 7816 is used

>>>>>>            Pv6 + TCP1440IPv6 header is larger
>>>>>>            IPv6 + UDP1452Max UDP payload
>>>>>>            ISO/IEC 7816
>>>>>>            (Short APDU)256payment cards and SIM cards
>>>>>>            ISO/IEC 7816
>>>>>>            (Extended APDU)65536 (optional)ISO/IEC 7816 is used

>>>>>>            1HAWK‑512Lattice~8×10⁴One of the fastest PQ
>>>>>>            signatures ever published
>>>>>>            2MAYO‑twoMultivariate~3–4×10⁵Very fast,

>>>>>>            especially for a multivariate scheme

>>>>>>            3ML‑DSA‑44Lattice~2.8×10⁵Matches Dilithium‑2
>>>>>>            performance
>>>>>>            4MQOMMPC‑in‑the‑Head~1–5×10⁶Middle‑tier MPCitH
>>>>>>            performance
>>>>>>            4SDitHMPC‑in‑the‑Head~1–5×10⁶Similar to MQOM
>>>>>>            4SNOVAMultivariate~1–5×10⁶Moderate signing cost
>>>>>>            4QR‑UOVMultivariate~1–5×10⁶Classic UOV‑style cost
>>>>>>            4UOVMultivariate~1–5×10⁶Similar to QR‑UOV
>>>>>>            9SQIsign‑IIsogeny~5–10×10⁶Very small signatures

>>>>>>            but slower signing
>>>>>>            10FAEST‑128fMPC‑in‑the‑Head~1.7×10⁶Fastest
>>>>>>            FAEST variant

>>>>>>            10FAEST‑128sMPC‑in‑the‑Head~1.3×10⁷Slowest

>>>>>>            FAEST variant
>>>>>>
>>>>>>
>>>>>>            Verification Performance
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            RankScheme (≈Level 1)FamilyVerify cycles
>>>>>>            (approx.)Notes
>>>>>>            1MAYO‑twoMultivariate~1×10⁵Extremely fast
>>>>>>            verification
>>>>>>            2HAWK‑512Lattice~1.5×10⁵Very efficient

>>>>>>            3ML‑DSA‑44Lattice~1.1×10⁵Dilithium‑class verify

>>>>>>            speed
>>>>>>            4MQOMMPC‑in‑the‑Head~1–5×10⁶Middle tier

>>>>>>            4SDitHMPC‑in‑the‑Head~1–5×10⁶Similar to MQOM
>>>>>>            4SNOVAMultivariate~1–5×10⁶Moderate
>>>>>>            4QR‑UOVMultivariate~1–5×10⁶Moderate
>>>>>>            4UOVMultivariate~1–5×10⁶Moderate
>>>>>>            9SQIsign‑IIsogeny~3–6×10⁶Verification faster

>>>>>>            than signing but still slow
>>>>>>            10FAEST‑128fMPC‑in‑the‑Head~1.4×10⁶Fastest
>>>>>>            FAEST verify

>>>>>>            10FAEST‑128sMPC‑in‑the‑Head~1.0×10⁷Slowest

>>>>>>            FAEST verify
>>>>>>
>>>>>>
>>>>>>            I hope the above tables help for the future
>>>>>> discussion.
>>>>>>
>>>>>>            Best regards,
>>>>>>
>>>>>>            Bo LIN
>>>>>>
>>>>>>            On Thu, 14 May 2026 at 20:21, 'dustin...@nist.gov

>>>>>> <http://nist.gov/>' via

>>>>>>                Questions may be directed topqc-c...@nist.gov.

>>>>>>                NIST thanks all of the candidate submission teams
>>>>>>                for their efforts in this standardization process
>>>>>>                as well as the cryptographic community at large,
>>>>>>                which helped analyze the signature schemes.
>>>>>>
>>>>>>
>>>>>>                The NIST PQC team
>>>>>>
>>>>>>
>>>>>>                --
>>>>>>                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 visit
>>>>>> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/5e07130a-10b4-429e-bd6d-44b5b8a48996n%40list.nist.gov
>>>>>>                <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/5e07130a-10b4-429e-bd6d-44b5b8a48996n%40list.nist.gov?utm_medium=email&utm_source=footer
>>>>>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/5e07130a-10b4-429e-bd6d-44b5b8a48996n%40list.nist.gov?utm_medium=email&utm_source=footer>>.
>>>>>>
>>>>>>
>>>>>>        --
>>>>>>        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

>>>>>> topqc-forum...@list.nist.gov.

>>>>>>        To view this discussion visit
>>>>>> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAL3OXVz_dXa7eoqvOxKaNX9C7TmyFPz9a_8uCBjHqERuZ17L2A%40mail.gmail.com
>>>>>>        <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAL3OXVz_dXa7eoqvOxKaNX9C7TmyFPz9a_8uCBjHqERuZ17L2A%40mail.gmail.com?utm_medium=email&utm_source=footer
>>>>>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAL3OXVz_dXa7eoqvOxKaNX9C7TmyFPz9a_8uCBjHqERuZ17L2A%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>>>>>>
>>>>>>
>>>>>>
>>>>>>    --
>>>>>>    Sofía Celi
>>>>>>    @claucece
>>>>>>    Cryptographic research and implementation at many places, but
>>>>>>    specially at Brave
>>>>>>    Reach me out at:cher...@riseup.net
>>>>>>    74BE 6517 031D 11CC D233 3FCA 44DF 95B9 E3BC 4369
>>>>>>
>>>>>>    --
>>>>>>    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 topqc-forum...@list.nist.gov.

>>>>>>    To view this discussion visit
>>>>>> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAHy9yiysOii4PcGgnTQwRmmuTO_YXWb5A6SHW%2B3B9zyVABLPBg%40mail.gmail.com
>>>>>>    <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAHy9yiysOii4PcGgnTQwRmmuTO_YXWb5A6SHW%2B3B9zyVABLPBg%40mail.gmail.com?utm_medium=email&utm_source=footer
>>>>>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAHy9yiysOii4PcGgnTQwRmmuTO_YXWb5A6SHW%2B3B9zyVABLPBg%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>>>>>
>>>>>
>>>>>    --
>>>>>    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 topqc-forum...@list.nist.gov.

>>>>>    To view this discussion visit
>>>>> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/F55F43F6-2C58-4DBA-A176-AD12A30759CD%40symbolic.software
>>>>>    <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/F55F43F6-2C58-4DBA-A176-AD12A30759CD%40symbolic.software?utm_medium=email&utm_source=footer
>>>>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/F55F43F6-2C58-4DBA-A176-AD12A30759CD%40symbolic.software?utm_medium=email&utm_source=footer>>.
>>>>
>>>>
>>>>
>>>> --
>>>> Sofía Celi
>>>> @claucece
>>>> Cryptographic research and implementation at many places, but
>>>> specially at Brave
>>>> Reach me out at:cher...@riseup.net
>>>> 74BE 6517 031D 11CC D233  3FCA 44DF 95B9 E3BC 4369
>>>
>>> --
>>> 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 topqc-forum...@list.nist.gov.

>>> To view this discussion visit
>>> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/547A1CC1-A2A6-4DA3-B930-0D6FA371672D%40symbolic.software
>>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/547A1CC1-A2A6-4DA3-B930-0D6FA371672D%40symbolic.software?utm_medium=email&utm_source=footer
>>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/547A1CC1-A2A6-4DA3-B930-0D6FA371672D%40symbolic.software?utm_medium=email&utm_source=footer>>.
>>
>> --
>> 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 topqc-forum...@list.nist.gov.
>> To view this discussion
>> visithttps://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/a0e2f9ec-50ab-454b-a858-f76be07f0141%40cryptme.in.

>
> --
> 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 visit
> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/C4E5296C-44C4-48BB-A6C6-80D459893FD7%40symbolic.software

> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/C4E5296C-44C4-48BB-A6C6-80D459893FD7%40symbolic.software?utm_medium=email&utm_source=footer>.

[Nadim Kobeissi]

SQIsign’s key and signature sizes are truly impressive and really set it apart from the pack. I hope it gets selected, because this would offer something which very few PQ primitives currently do. In pivoting away from ECC, we’ve ended up (largely) with much larger public keys and signatures, and it would be great to have a primitive that can harken back to that, which might especially be useful in memory-constrained environments (think firmware signing, etc. — something which I’ve been dealing with a lot at work recently, by coincidence).

Nadim Kobeissi
Symbolic Software • https://symbolic.software

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/3d31bd17-6d8e-42c9-a088-719f96ec468b%40cryptme.in.

[Sebastien Riou]

Hi Nadim,

Agree for your main point about SQIsign.

I'm curious about the "memory-constrained environment" associated with "firmware-signing". Could you elaborate in which use case you end up signing firmware on a memory constrained device ?

Best regards,

Sebastien Riou

Fellow, Product Security Architecture

PQShield Ltd

 

M:             +33 782 320 285

E:              sebasti...@pqshield.com

W:             www.pqshield.com

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/E6EB44DC-30E9-4D74-A847-FD3315E538E0%40symbolic.software.

[Nadim Kobeissi]

Hi Sebastien,

The memory-constrained environment I’m dealing with here is actually not firmware signing (hence why I wrote “etc.!”) but a situation where we still need to encode a public key and a signature within a small physical space. It’s definitely a situation in which SQIsign would be useful, because we had to re-engineer the spec to accommodate relatively massive public key + signature sizes when switching to ML-DSA from ECC.

Unfortunately, I can’t say more because this is work that’s being done under NDA. I hope it will be public one day soon.

Nadim Kobeissi
Symbolic Software • https://symbolic.software

[Pedro Massolino]

Sorry if I am crossing any bounds with this question, but would not FN-DSA be a better choice than ML-DSA regarding signature+public key size?

Or Falcon, since FN-DSA has no draft as far as I am aware.

Dr. Pedro Maat Costa Massolino
Senior Cryptography Hardware Engineer
PQShield Ltd

E:              pedro.m...@pqshield.com
W:             www.pqshield.com

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/FAA0DFC2-BA5C-45FC-857C-458BBA75857D%40symbolic.software.

[Nadim Kobeissi]

Two reasons:

1. There seems to be a big gap in terms of maturity between ML-DSA and FN/Falcon implementations,

2. Both ML-DSA and FN/Falcon PK+sig size increases are large enough such that it doesn’t matter anymore for our use case and we need to go do some weird engineering tricks such that the spec survives PQ migration. However, SQIsign is still close enough to ED25519 (and at least 5x smaller even than FN/Falcon) to allow us to still wiggle through with the space we have.

Nadim Kobeissi
Symbolic Software • https://symbolic.software

[Nadim Kobeissi]

Giving a hint that I hope doesn’t violate NDA but still explains my position:

Imagine situations where you need to print a public key, a signature, or both, as something similar to a barcode or QR Code, on something similar to a receipt or cardboard packaging...

Nadim Kobeissi
Symbolic Software • https://symbolic.software

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/255B37C6-900C-4877-96ED-01DA2257CED4%40symbolic.software.

[Blumenthal, Uri - 0553 - MITLL]

Falcon loses to ML-DSA where the implementation needs to be validated. Is been pointed out in the NIST documents. (Plus, some performance differences.)

Thnx

—

Regards,

Uri

Secure Resilient Systems and Technologies

MIT Lincoln Laboratory

On May 27, 2026, at 06:59, 'Pedro Massolino' via pqc-forum <pqc-...@list.nist.gov> wrote:



Sorry if I am crossing any bounds with this question, but would not FN-DSA be a better choice than ML-DSA regarding signature+public key size? Or Falcon, since FN-DSA has no draft as far as I am aware. Dr. Pedro Maat Costa Massolino Senior Cryptography

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside the Laboratory.

 

ZjQcmQRYFpfptBannerEnd

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CADc2vht7Wc94Pwkmfvg7S3w8YTAn6RtkxZN5zyYX42%3DJOV-F9w%40mail.gmail.com.

[Nadim Kobeissi]

Yes, this is exactly correct, Uri.

And on top of this, there’s also the effect that standardization usually leads to a chasm opening between standardized and non-standardized implementations, wherein implementers focus their attention in on the standardized primitive when working on producing higher quality, more performant and verified implementations for more platforms and programming languages, leaving non-standardized primitives less able to compete in those domains and allowing the standardized primitives to further monopolize adoption by being more appealing to engineers and product managers.

Nadim Kobeissi

Symbolic Software • https://symbolic.software

On 27 May 2026, at 2:19 PM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote:

Falcon loses to ML-DSA where the implementation needs to be validated. Is been pointed out in the NIST documents. (Plus, some performance differences.)

[Thomas Prest]

Hi Demi Marie,

To answer your questions on making the running time of Falcon and Raccoon deterministic:

1. Falcon => there are two checks at the end of the Falcon signing procedure, one on the norm of the signature and one on the bitsize of its encoding. We can remove these two checks by slightly increasing the bounds (ballpark estimate of the impact: 2-3 bits in security and maybe 10 bytes in signature size). Once you do that, the running time is still not deterministic since each of the 2n calls to SamplerZ take a variable amount of time, but it can be upper bounded with high probability, which is probably what you want in the end. Happy to look more into it if it's something the community considers very important (at the moment, the restart rate is already very low, but not negligible).
2. Raccoon => there are two checks at the end of the Raccoon signing procedure, one on the L2 norm and another on the L_oo norm. Again, they can be increased to make the rejection rate negligible with minimal impact on security.

Best,
Thomas

[Bo Lin]

Hi, Sofi,

Your observation is right that the updated table is still erroneous. I would stop updating it but recommend to use https://pqshield.github.io/nist-sigs-zoo/ for sizes and performance figures. (Thanks to Krijn Reijnder and other who pointed this link to me).

Just a small note for those who want to use the table in the site that when "Total size" is calculated, signature size could come from CA which usually has a higher security level than the application's public key. So the size of a certificate may be bigger than the "Total size" of simply summing up the PK size and the signature size in a row.

In terms of those LLM generated tables, I didn't expect so many responses but if anyone to this thread, they'll know what to do. Your concern was justified if it were not addressed.

For IP packet size and ISO 7816 size, let me list two reasons why I think they should be considered. 

1. There are quite a few certified PQC libraries have been certified, so for new candidates to be standardised, they should differentiate the existing standards. Otherwise, it would be difficult to justify the effort to certify a new but similar scheme.

2. In addition to differentiate on security, applicability is a good justification area and IP packet size (esp. UDP) and ISO 7816 exist in many applications. 

If you have any other criteria for the standard selection, you can post them here. ML-DSA is standardised and employed by many applications. If the next one is similar to it, though it may provide more security assurance, it will be just a backup scheme. 

For the next selected schemes to have position in the real world, they must have desirable features in applications.

Best regards,

Bo Lin

[Sophie Schmieg]

On the topic of FN-DSA, I wrote up a couple of thoughts on the practicalities deploying the algorithm while we are waiting for the initial private draft to turn into an initial public draft:

https://keymaterial.net/2026/05/13/so-you-want-to-deploy-fn-dsa/

I kept it fairly general though, given the lack of the aforementioned ipd.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAL3OXVyB%3DcSjRTw1NfbWnQ4YWOc046g%2BOpu2m9QbAo116MvUQA%40mail.gmail.com.

--

Sophie Schmieg | Information Security Engineer | ISE Crypto | ssch...@google.com

[Sofi Celi]

Thank you @Bo Lin ! Recommending https://pqshield.github.io/nist-sigs-zoo/ is the right move, and I'm happy said conclusion is reached. 

@Sophie always happy to make people chuckle!! ;) xD

Thank you,

[Brent Kimberley]

Is there a companion p99 / p99.9  / p99.99 chart?

 

From: 'Sophie Schmieg' via pqc-forum <pqc-...@list.nist.gov>
Sent: May 27, 2026 1:36 PM
To: Bo Lin <boli...@gmail.com>
Cc: Sofi Celi <sofi...@gmail.com>; dustin...@nist.gov <dustin...@nist.gov>; wa...@beullens.com; pqc-forum <pqc-...@list.nist.gov>
Subject: Re: [pqc-forum] Announcement of the 3rd Round Onramp Candidates

 

⚠️CAUTION: This email is from an external source. Verify sender before opening links and attachments.⚠️

 

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEEbLAbnghs7mzQQty432SMk7rPYUGdO6eT50LVoGOD5MYCjXQ%40mail.gmail.com.

THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

[Brent Kimberley]

Scratch that.  Thanks.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/YT2PR01MB57746669CFE8EF29EA7627EAFA082%40YT2PR01MB5774.CANPRD01.PROD.OUTLOOK.COM.

[Sofi Celi]

Thank you, Gustavo. That seems very helpful. I think also the website from PQShield will help on that as well. 

Sofía Celi
@claucece
Cryptographic research and implementation at many places, but specially at Brave

Reach me out at: cher...@riseup.net
74BE 6517 031D 11CC D233  3FCA 44DF 95B9 E3BC 4369

[Francisco Rodriguez- Henriquez]

Hi Krijn,

Don't forget to also check PQ-SORT:
https://pqsort.tii.ae/

PQ-SORT will be continuously updated as new information from the teams
becomes available.

Cheers,
Francisco

On Mon, 25 May 2026, Krijn Reijnders wrote:

> It is clear that the numbers in table 1 are hallucinated: they dont make any sense for the multivariate ones, which have larger public keys and smaller
> signatures. Simply check https://pqshield.github.io/nist-sigs-zoo/ if you want the proper numbers for this. It also mixes up a level 5 for Mayo in there.
>
> (I haven't checked the other tables).

>
> --
> 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 visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/6F962152-411D-452B-A31E-33A16662D270%40getmailspring.com.
>
>

[Sebastien Riou]

Hi Fransisco,

On https://pqsort.tii.ae/:

If I select only ML-DSA, security level 3 and 5 and metric 'Max',  I get the following numbers for signature:

ML-DSA-65: 2.109 million cycles

ML-DSA-87: 1.971 million cycles

This is obviously wrong. You are not alone getting those weird results, pretty much every benchmark I have seen so far about ML-DSA sign either omit a 'Max' metric or get it wrong (upside down like here or with significant variation from one run to another).

First and foremost, 'Max' cannot be practically measured, it would involve finding a test vector which has a probability of occurrence of 2^-256...

More details on how to get it right: https://github.com/sebastien-riou/BTVG-MLDSA/blob/main/2026-05-10%20-%20MAgiCS%20-%20MLDSA%20Sign%20Benchmarking.pdf (corresponding paper will be available on open access soon)

Best regards,

Sebastien Riou

Fellow, Product Security Architecture

PQShield Ltd

 

M:             +33 782 320 285

E:              sebasti...@pqshield.com

W:             www.pqshield.com

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/alpine.LFD.2.23.451.2606021907180.3727337%40delta.cs.cinvestav.mx.

[D. J. Bernstein]

eBACS has always reported 25%, 50%, 75% in tables. Big differences
between 25% and 75% are marked in red with question marks. See, e.g.,
"328278? 504094? 700491?" cycles for dilithium2 signing on Gracemont:

https://bench.cr.yp.to/results-sign/amd64-freshwrap,little.html

For many years these were first quartile, median, third quartile, but
I've switched over to stabilized quartiles, as explained in my paper
"Robust statistics for rejection-sampling timings" last year:

https://cr.yp.to/papers.html#rsrst

The underlying data files generated by SUPERCOP include many more
measurements (e.g., 48 measurements for each signing size, split across
3 keys); it's easy to graph those to get an idea of variations.

Carefully modeling the variations for a specific platform and adding a
safety margin should be acceptable for a hard real-time system, but I
still wouldn't recommend using such a model to pick inputs to use for
cross-platform benchmarks: the inputs can easily miss big variations for
another platform.

---D. J. Bernstein

[fran...@cs.cinvestav.mx]

Hi Sebastien,

Thanks for pointing out this issue. We acknowledge this problem, and we
are working on how to solve it.

Cheers,
Francisco

[John Mattsson]

eBACS has always been my favorite benchmark resource, and to a large extent it still is. Newer websites such as Signature Zoo and PQ-Sort provide more user-friendly interfaces, but I worry that they may disappear after a few years, when the topic is not hot anymore. In contrast, eBACS has existed for more than 20 years. It would be beneficial to have a unified long-term approach that preserves the comprehensive measurements provided by eBACS while presenting them through a more modern web interface.

I am also missing performance data that is useful for real-time systems. Sébastien Riou has stated that the sweet spot for his systems is around a probability of 2^-48. You cannot choose a signature algorithm for real-time systems based solely on average or 75th-percentile performance figures. Performance estimates at a 2^-48 probability would need to combine empirical measurements with analytical calculations.

Cheers,

John Preuß Mattsson

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> on behalf of fran...@cs.cinvestav.mx <fran...@cs.cinvestav.mx>
Date: Thursday, 4 June 2026 at 06:38
To: Sebastien Riou <sebasti...@pqshield.com>
Cc: Francisco Rodriguez- Henriquez <fran...@cs.cinvestav.mx>; Krijn Reijnders <reijnde...@gmail.com>; Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>; wa...@beullens.com <wa...@beullens.com>; pqc-forum <pqc-...@list.nist.gov>
Subject: Re: [EXT] RE: [pqc-forum] Announcement of the 3rd Round Onramp Candidates

[You don't often get email from fran...@cs.cinvestav.mx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hi Sebastien,

Thanks for pointing out this issue. We acknowledge this problem, and we
are working on how to solve it.

Cheers,
Francisco

> Hi Fransisco,
>

> On https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpqsort.tii.ae%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cd6f62e6f871748b7c74108dec1f2e87f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639161447273771427%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=jMNYPDK7dgD92in6vkjt5E3VvADZiGY5DeahCaA6TFQ%3D&reserved=0:

>
> If I select only ML-DSA, security level 3 and 5 and metric 'Max',  I get
> the following numbers for signature:
>
> ML-DSA-65: 2.109 million cycles
> ML-DSA-87: 1.971 million cycles
>
> This is obviously wrong. You are not alone getting those weird results,
> pretty much every benchmark I have seen so far about ML-DSA sign either
> omit a 'Max' metric or get it wrong (upside down like here or with
> significant variation from one run to another).
> First and foremost, 'Max' cannot be practically measured, it would involve
> finding a test vector which has a probability of occurrence of 2^-256...
> More details on how to get it right:

> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsebastien-riou%2FBTVG-MLDSA%2Fblob%2Fmain%2F2026-05-10%2520-%2520MAgiCS%2520-%2520MLDSA%2520Sign%2520Benchmarking.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cd6f62e6f871748b7c74108dec1f2e87f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639161447273799401%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=OeEMVMlrbQJqoeVpI59Aw4ce61tNTOqERh%2BnDOy5ZnE%3D&reserved=0

> (corresponding
> paper will be available on open access soon)
>
> Best regards,
>
> Sebastien Riou
>
> Fellow, Product Security Architecture
>
> PQShield Ltd
>
>
>
> M:             +33 782 320 285
>
> E:              sebasti...@pqshield.com
>

> W:             https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pqshield.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cd6f62e6f871748b7c74108dec1f2e87f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639161447274160158%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=kw6dXrwaNnCz%2BODG4B4OamRoSezhWLhgumb3upcLpD0%3D&reserved=0

>
>
> On Wed, 3 Jun 2026 at 03:15, Francisco Rodriguez- Henriquez <
> fran...@cs.cinvestav.mx> wrote:
>
>> Hi Krijn,
>>
>> Don't forget to also check PQ-SORT:

>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpqsort.tii.ae%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cd6f62e6f871748b7c74108dec1f2e87f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639161447274181681%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=a6WrW0roIN1h83%2F5cZxQ4BfmnXsx%2BApGqXFqIts5c9k%3D&reserved=0

>>
>> PQ-SORT will be continuously updated as new information from the teams
>> becomes available.
>>
>> Cheers,
>> Francisco
>>
>> On Mon, 25 May 2026, Krijn Reijnders wrote:
>>
>> > It is clear that the numbers in table 1 are hallucinated: they dont
>> make
>> any sense for the multivariate ones, which have larger public keys and
>> smaller

>> > signatures. Simply check https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpqshield.github.io%2Fnist-sigs-zoo%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cd6f62e6f871748b7c74108dec1f2e87f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639161447274198881%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=sPprJuRFgw6tIkrn8mk1s2TMS2IAAAsMHmV3X6eqQJI%3D&reserved=0 if

>> you want the proper numbers for this. It also mixes up a level 5 for
>> Mayo
>> in there.
>> >
>> > (I haven't checked the other tables).
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "pqc-forum" group.
>> > To unsubscribe from this group and stop

--
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 visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Flist.nist.gov%2Fd%2Fmsgid%2Fpqc-forum%2Ffbf827f03d0cc93701be46a92448852d.squirrel%2540delta.cs.cinvestav.mx&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cd6f62e6f871748b7c74108dec1f2e87f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639161447274214607%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=MCOnSG9KuBuMUUf5xOI9%2BT6%2FwzKK5ZAEo9ve81z6gkg%3D&reserved=0.