Planned changes to the Dilithium spec.

[Perlner, Ray A. (Fed)]

Hi all,

 

After discussion among ourselves and with the Dilithium team, we plan to make the following changes from version 3.1 of the Dilithium spec (https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf ) to our MLWE-sig standard based on Dilithium:

1. In order to support hedged signing, we plan to replace line 12 in Figure 4 in version 3.1 of the Dilithium spec. with “rho' ß H(K | rnd | mu)” where rnd is either "" in the deterministic case or a random 512-bit string in the randomized one. (Hedged signing was discussed in earlier PQC-Forum messages. The basic idea is that the use of the private key in deriving the per-signature randomness rho’ provides robustness against a bad RNG, as in deterministic signing, but in hedged signing additional fresh randomness is included in the computation of rho’, so it will be easier to avoid side-channel pitfalls that can arise with completely deterministic signatures.)
2. In order to make sure the argument for the BUFF security of Dilithium given in section 6.1 of https://eprint.iacr.org/2020/1525.pdf holds for all security strength categories, we plan to increase the size of the variable tr (which first appears at line 7 of Figure 4 in version 3.1 of the Dilithium spec.) from 256 bits to 512 bits.

 

Please let us know if you have any comments or objections regarding these proposed changes.

 

Ray Perlner (on behalf of the NIST PQC team)

 

[Markku-Juhani O. Saarinen]

On Thursday, April 20, 2023 at 11:06:43 PM UTC+2 Perlner, Ray A. (Fed) wrote:

After discussion among ourselves and with the Dilithium team, we plan to make the following changes from version 3.1 of the Dilithium spec (https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf ) to our MLWE-sig standard based on Dilithium:

1. In order to support hedged signing, we plan to replace line 12 in Figure 4 in version 3.1 of the Dilithium spec. with “rho' ß H(K | rnd | mu)” where rnd is either "" in the deterministic case or a random 512-bit string in the randomized one. (Hedged signing was discussed in earlier PQC-Forum messages. The basic idea is that the use of the private key in deriving the per-signature randomness rho’ provides robustness against a bad RNG, as in deterministic signing, but in hedged signing additional fresh randomness is included in the computation of rho’, so it will be easier to avoid side-channel pitfalls that can arise with completely deterministic signatures.)

Hi Ray & All,

I like the hedging idea a lot -- but at least in my mind, the purpose of hedging was to bring "best of both worlds" into a single step, and that way, get rid of the cumbersome situation where there are two different variants of the Dilithium signing process. Here a separate deterministic variant is apparently retained -- and it remains just as insecure against side-channel attacks as before.

Suggesting fixed-size "md":

If I'm reading the above correctly, it is proposed to set md as a zero-length string for Deterministic signing and a 512-bit quantity for randomized. This seems to require an additional API switch and two sets of KAT files. Additionally, there are technical domain separation issues (concatenation is not an appropriate way to hash variable-length triplets of data), but those don't seem exploitable in this particular case. Anyway, testing would be simpler if one were just to set md=0^512 (or some "application specific" 512-bit value) for the deterministic use case, and random 512-bit value in general use. From API and testing viewpoint there would be just one Dilithium.

Additional rationale for "One Hedged Dilithium":

As you note, the main reason for deterministic Dilithium is to provide security in use cases where limited entropy is available. It is clear that deterministic Dilithium is significantly less secure (or significantly slower if the same security level is required) in hardware implementations ( see e.g. https://eprint.iacr.org/2022/1406.pdf ). Adding "K" to randomized signing has very little effect on this.

I might be worrying about this too much (but it has emerged in practical engineering work): some engineers/standardization bodies might assign separate algorithm identifiers for these variants, even though this is essentially an internal implementation detail. If these are seen as essentially different algorithms, then this might still force us (hardware implementors) to include support for the less secure deterministic variant in APIs and hardware too.

The Dilithium standard should at least include language stating that the hedged implementation is the preferred one and possibly require hedging at higher FIPS 140-3 security levels (which may require side-channel security anyway).

Everyone should recall that deterministic and randomized signatures and secret keys are interchangeable. This does not affect signature verification at all, and both versions can use the same secret keys -- they just use them slightly differently.

 

1. 
   
2. In order to make sure the argument for the BUFF security of Dilithium given in section 6.1 of https://eprint.iacr.org/2020/1525.pdf holds for all security strength categories, we plan to increase the size of the variable tr (which first appears at line 7 of Figure 4 in version 3.1 of the Dilithium spec.) from 256 bits to 512 bits.
   

This seems reasonable. However, the specification could be clarified to state that "tr" is a 512-bit SHAKE-256 of the public key, which has been serialized into bytes as specified in the Dilithium specification itself. ( Some in IETF etc. have even proposed non-standard encodings for Dilithium public keys without realizing that both signature generation and verification would then require re-serialization of public keys into this format. )

Background: The "tr" quantity is used to explicitly bind the signature to the public key (which gives it several of the "BUFF" properties). This is done in the computation of "mu" on line 10 of the signature function (as "tr"), but the same quantity also appears on line 28 of the verification function as H( rho || t1). Clearly, "mu" must match in signing and verification, so the encoding of the hash input must be the same. In actual implementations, it is computed as tr = H(pk), as I am describing above.

Cheers,

-markku

[Markku-Juhani O. Saarinen]

On Thursday, April 20, 2023 at 11:06:43 PM UTC+2 Perlner, Ray A. (Fed) wrote:

1. 
   
2. In order to make sure the argument for the BUFF security of Dilithium given in section 6.1 of https://eprint.iacr.org/2020/1525.pdf holds for all security strength categories, we plan to increase the size of the variable tr (which first appears at line 7 of Figure 4 in version 3.1 of the Dilithium spec.) from 256 bits to 512 bits.
   

On Friday, April 21, 2023 at 8:49:31 AM UTC+1 Markku-Juhani O. Saarinen wrote:

This seems reasonable. However, the specification could be clarified to state that "tr" is a 512-bit SHAKE-256 of the public key, which has been serialized into bytes as specified in the Dilithium specification itself. ( Some in IETF etc. have even proposed non-standard encodings for Dilithium public keys without realizing that both signature generation and verification would then require re-serialization of public keys into this format. )

Addition:

 

Note that successful forgery with the hashes can be achieved by matching ~c == H( mu || w'1 ) on line 31 of the verification function.

Since ~c is only  256 bits, one can find a collision (two distinct messages with the same signature) with 2^128 classical effort, which seems to break the desired BUFF security properties.

Basically: Compute w1 up to line 17 in Sign(), then perform a collision attack to find M1 != M2 so that corresponding 256-bit hashes ~c1 and ~c2 match. Note that mu does not need to match for M1 and M2 (and the use of mu on line 12 is irrelevant); it is sufficient that:  H( H( tr || M1 ) || w1) == H( H( tr || M2 ) || w1).

Then one uses that shared ~c value to complete the rest of signature steps 17..26 to arrive at sigma = (~c, z, h ). Now this is a signature for both M1 and M2.

So for consistency, perhaps NIST wants to increase the size of ~c too, which is easy to do.

Cheers,

- markku

[Markku-Juhani O. Saarinen]

Addition 2:

To clarify: ~c is the "challenge hash" that represents the polynomial challenge c in actual Dilithium signatures (Fig. 4 in Dilithium 3.1 spec). The abstract algorithm flow in Figure 1 doesn't have this variable.

The actual BUFF transform (Figure 6 of https://eprint.iacr.org/2020/1525.pdf) achieves goals such as MBS (Message Bound Security, violated in the above attack) by adding an additional hash h = H(m, pk) in the signature. It is easy to see  (and also shown in Proposition 6.1 of the BUFF paper) that an additional hash isn't necessary with Dilithium since the challenge hash ~c = H( mu || w1 ) already contains both m and pk via mu = H( H(pk) || m ) and is used in verification in a similar manner as the auxiliary hash h is used in the BUFF transformed verification function Vf*.

The BUFF transform does not modify the core algorithm and the Dilithium security proofs only assume second pre-image resistance. The challenge entropy (of polynomial c itself) is at log2(binomial(256,tau))+tau; for Dilithium 2,3,5 we have tau = { 39,49,60 } (Table 2 of Dilithium 3.1) and corresponding challenge spaces |Btau| of { 2^192.8, 2^225.3, 2^257.0 }. While increasing the challenge hash ~c would just add 32 bytes to the signature size, increasing tau would impact the performance via SampleInBall() and the rejection rate. To achieve the same goals as the BUFF transform, this does not seem exactly necessary. If it is shown to be necessary, it would be a much bigger change.

Cheers,

- markku

 

[Tobias Schneider]

Hi Ray (and Markku, all),

We would like to have your feedback on an alternatives proposal for Dilithium signing, which is a bit orthogonal to what you are currently advocating for with the hedged approach (protection against bad randomness, single API / easy testing).

Sampling y directly from a randomness source has significant performance and memory requirements benefits for very constrained devices, which include a good randomness source, e.g., according to SP 800-90 A/B/C.
It would remove the need for most of the masked Keccak operations and provide more flexibility for masked implementations, e.g., share-wise generation of y.
The output is indistinguishable from the randomized hedged version, and security is no less assuming the provided randomness is cryptographically secure.
In fact, the side-channel leakage is actually reduced with respect to the hedged version since no leakage on masked Keccak for rho’ and y is obtained.
More benchmark details are provided in our eprint [1] and presentation at RWC23 [2].

We understand that it would not be the best fit for default Dilithium, as not all platforms include a good randomness source.
However, the benefits for platforms that have this feature seem significant enough to us to consider it for inclusion in the standard.

NIST mentioned before that some standards will get Special Publications with further implementation details, e.g., small SPHINCS+.
So if it cannot be part of the main draft, is it possible to consider the fully-randomized version as a Special Publication?

Best regards
Tobias

[1] https://eprint.iacr.org/2022/1406
[2] https://iacr.org/submit/files/slides/2023/rwc/rwc2023/68/slides.pdf

[Markku-Juhani O. Saarinen]

Hi,

All of this is correct. Testability is the only technical advantage of the SHAKE seed-expansion approach for "y" over sampling it directly from (D)RBGs. It's just random numbers. And, as noted, masked Keccak is expensive.

One could do the same in keypair generation -- sample s1,s2 directly from general DRBGs rather than implement rather complicated masked rejection sampling gadgets. ( However we found masked Dilithium key generation to have practical applications as some customers want to manage secret keys as masked seeds (d * 256 bits) to save non-volatile key storage space. )

In the end the question of what is a valid/invalid implementation is basically a FIPS 140-3 and CAVP/ACVTS (Cryptographic Algorithm Validation Program) question. Very recently LMS was the first PQC scheme added there ( https://github.com/usnistgov/ACVP#stateful-hash-based-signatures ). I recall NIST informing the last CMUF meeting that XMSS is next in line after HSS. The natural expectation is that Kyber and Dilithium will follow eventually.

The problem Dilithium faces with CAVP is that the inherently "error-tolerant" stochastic nature of lattice operations makes semi-automated validation of internally divergent implementations difficult. So if a future SP discusses alternative implementation details and options, this is probably limited by testability requirements. For example, straightforward application of formal methods would require completely rigid adherence to the specification, but of course side-channel security countermeasures already complicate implementations so that they don't fit into a "formal spec" template anymore. And we want to have side-channel security.

We know that one can have a Dilithium or Falcon implementation with trivially faulty arithmetic components that still produces signatures that verify as correct against the public key -- this is less likely with RSA or ECC. If Known-Answer Tests (KATs) can't be used one could perhaps try statistical methods -- but defining those in CAVP context seems complicated and would require very large amounts of testing data.

Personally, I've come to just accept that KATs and other deterministic end-to-end testing aids are absolutely needed in holding these PQC implementations together. So even when I advocate for randomized implementations as being more secure (they are), I'm not comfortable unless I am able to bypass that randomness in testing and make the module spit out the expected test vectors. My expectation is that this "testing mode" will also help with eventual FIPS 140-3 certification.

Cheers,

- markku

 

[Falko Strenzke]

Hi Markku,

I think cryptographic specifications would generally benefit from enabling such a testing mode as you propose. That could be realized by parametrizing each function which uses randomness with a randomness source. The latter can then be a  deterministic PRNG and used for testing with a specific seed. In normal usage, it might be a TRNG or a TRNG-driven (seeded) PRNG. In that latter case, one can also specify the optimal way of hedging against weaknesses in the underlying TRNG, namely by additionally seeding the PRNG with the input message to be signed or encrypted. This would for example make some "static-IV" constructions for encryption unnecessary.

The only downside of such a standardization approach that I see is the complexity and overhead it creates for defining the interface and behaviour of the generic randomness source. That would probably only be worthwhile if it finds broad agreement across standardization bodies, so that implementers have to understand a single "randomness source framework".

In any case I think that independently from the very general idea, for the PQC schemes a standardized testing mode is necessary.

- Falko

Am 26.04.23 um 21:11 schrieb Markku-Juhani O. Saarinen:

--
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/CA%2BiU_qneV1zj0vHaSXMQTNYZtO9ofRR%2Bw9TS9_zs6e1zEXxx0Q%40mail.gmail.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

[Perlner, Ray A. (Fed)]

Dear Tobias,

 

We agree that on some platforms, it could be useful to bypass the XOF in generating private randomness for Dilithium. However, I don't think it would be feasible to include this option in the FIPS. It seems to me that in order to give a testable specification for a version of Dilithium that makes separate calls to a RBG when the submitted version uses the output of SHAKE with a private seed, there'd need to be fairly extensive rewriting of the specification and code, separate KATs etc. which would need significant vetting and might slow standardization down.

 

A separate SP later may be possible. To be clear, though, I don’t think we would be able to specify a version of Dilithium that would directly access the entropy source, since this would go against the existing guidance of SP 800-90. To quote from the abstract of SP 800-90b which specifies entropy sources:

 

"This Recommendation specifies the design principles and requirements for the entropy sources used by Random Bit Generators, and the tests for the validation of entropy sources. These entropy sources are intended to be combined with Deterministic Random Bit Generator mechanisms that are specified in SP 800-90A to construct Random Bit Generators, as specified in SP 800-90C."

 

I take it the idea would be to allow implementations of Dilithium to replace the XOF with many separate calls to a DRBG, with the understanding that the DRBG is reseeded with fresh entropy often enough that side channel protections aren’t needed on the DRBG.

 

Best,

Ray Perlner

[Joost Renes]

Hi Ray,

 

We acknowledge the additional complexity that this feature (or any change at this point) brings, and would of course not want to risk slowing down standardization.

On the other hand, we cannot overstate the impact this feature will have on the security (much less leakage on the very sensitive y), efficiency (masked SHA3 is much slower than a DRBG) and complexity (less need for *fast* masked SHA3 software/hardware) of secure embedded systems.

 

We believe it involves only a minor change to the specification/implementation.

I have attached a diff file to enable this change in the Dilithium reference implementation [A].

This is just to demonstrate that functionally there is little change needed.

The KAT files can be generated without any changes to the framework, they can be generated by running “make; PQCgenKAT_sign2” for example.

For convenience, I have also attached them.

Of course, we will leave it up to you to decide whether it makes sense for FIPS or SP.

 

As to your second point, the proposal is indeed to replace the SHAKE pseudo-randomness with a SP 800-90C certified DRBG, not with output from a TRNG directly.

This would mean that y is generated from the same source as seedbuf in key generation, and rhoprime in sign (for the current randomized version).

 

Kind regards,

Joost (on behalf of the NXP team)

 

[A] https://github.com/pq-crystals/dilithium/tree/master/ref, commit 3e9b9f1412f6c7435dbeb4e10692ea58f181ee51

 

From: 'Perlner, Ray A. (Fed)' via pqc-forum <pqc-...@list.nist.gov>
Sent: Tuesday, May 2, 2023 7:58 PM
To: Tobias Schneider <to.schn...@gmail.com>; pqc-forum <pqc-...@list.nist.gov>
Cc: Markku-Juhani O. Saarinen <mjos....@gmail.com>

Subject: [EXT] [pqc-forum] RE: Planned changes to the Dilithium spec.

 

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button

 

--

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/DM6PR09MB48551286C1575593C7A5FE2D9C6F9%40DM6PR09MB4855.namprd09.prod.outlook.com.

[Simon Hoerder]

Hi,

Thanks to the NIST team for announcing the planned changes in Kyber and Dilithium in advance. 

However, with that all available specifications and test vectors on the NIST website and on pq-crystals.org are out of date. That is not particularly helpful for anyone prototyping the PQ transition.

Is NIST planning to release the draft standards within the next month? If not, is NIST or are the Crystal Teams planning to release updated specs / test vectors as a stop-gap? 

Thanks,

Simon

[Peter Schwabe]

Simon Hoerder <si...@hoerder.net> wrote:
> Hi,

Hi Simon, hi all,

That's a very good point. I'll try and implement the proposed changes to
Kyber in a separate branch of https://github.com/pq-crystals/kyber over
the weekend. This is probably anyway good to make sure that we all agree
what exactly the changed version looks like.

All the best,

Peter

[Peter Schwabe]

Simon Hoerder <si...@hoerder.net> wrote:
> Hi,

Dear Simon, dear all,

I now implemented the changes that NIST announced they are planning for
Kyber in the https://github.com/pq-crystals/kyber repo in a branch
called "standard". Bas Westerbaan implemented the same changes, also in
a branch called "standard", in the Python implementation contained in
https://github.com/bwesterb/draft-schwabe-cfrg-kyber/

Some notes about the implementations in these branches:

- The code uses SHAKE256 to derive the rejection key; see my earlier
message to pqc-forum.

- In both repos we now implement test_vectors using deterministic
pseudo-randomness obtained from SHAKE128 on empty input. The
test_vectors (unlike the NIST KATs) now also cover invalid
(pseudorandom) ciphertexts; they do not yet cover invalid
(malformatted) secret and public keys.

- I removed all code for the "90s" variants in the "standard" branch.

- The C/asm implementations in the pq-crystals repo now also have a
derandomized API for keypair and enc, which, in some environments may
make it easier to integrate code or generate test vectors.


All the best,

Peter

[Simon Hoerder]

Dear Peter, Bas,

many thanks for the quick reaction and good work.

Best regards,
Simon

> On 7 May 2023, at 19:23, Peter Schwabe <pe...@cryptojedi.org> wrote:

[Peter...@infineon.com]

Hi all,

 

we support the suggestions of Markku to use a fixed size "rnd" that is either random or a fixed value for the mentioned reasons (simplified testing with a unified API and reduced reason to view the variants as two different algorithms). To prevent vendors from needing to support both variants and their vastly different requirements regarding physical security (e.g. the hard fault protection of deterministic Dilithium: https://eprint.iacr.org/2018/355.pdf), we would welcome a wording in the standard making it clear that supporting either variant is sufficient and that the selection can be implementation specific, even not visible to the user.

 

Additionally, we propose to set the length of rnd to 256 bits. This way, all inputs to H fit into a single block, while security properties are not negatively affected.

 

Cheers,

Peter (on behalf of the Infineon PQC Team)

 

---------- Forwarded message ---------
From: Markku-Juhani O. Saarinen <mjos....@gmail.com>
Date: Fri, Apr 21, 2023 at 9:49 AM
Subject: [pqc-forum] Re: Planned changes to the Dilithium spec.
To: pqc-forum <pqc-...@list.nist.gov>
Cc: Perlner, Ray A. (Fed) <ray.p...@nist.gov>

 

On Thursday, April 20, 2023 at 11:06:43 PM UTC+2 Perlner, Ray A. (Fed) wrote:

 

After discussion among ourselves and with the Dilithium team, we plan to make the following changes from version 3.1 of the Dilithium spec (https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf ) to our MLWE-sig standard based on Dilithium:

1.      In order to support hedged signing, we plan to replace line 12 in Figure 4 in version 3.1 of the Dilithium spec. with “rho' ß H(K | rnd | mu)” where rnd is either "" in the deterministic case or a random 512-bit string in the randomized one. (Hedged signing was discussed in earlier PQC-Forum messages. The basic idea is that the use of the private key in deriving the per-signature randomness rho’ provides robustness against a bad RNG, as in deterministic signing, but in hedged signing additional fresh randomness is included in the computation of rho’, so it will be easier to avoid side-channel pitfalls that can arise with completely deterministic signatures.)

[Perlner, Ray A. (Fed)]

Dear all,

In response to the feedback on this thread (and after checking with the Dilithium team), we plan to make the following additional changes to NIST's standard for Dilithium.

1) As suggested by Markku-Juhani O. Saarinen, we plan to increase then length of \tilde{c} to obtain the "message-bound signature" property from https://eprint.iacr.org/2020/1525 at the target security level. Specifically we plan to increase the length to 256, 384, and 512 bits respectively for the Category 2, Category 3, and Category 5 parameter sets. (compare to line 17 of figure 4 in version 3.1 the Dilithium spec: https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf). To avoid changing the procedure SampleInBall (called at line 18 in version 3.1 Figure 4), the NIST standard will only pass the first 256 bits of \tilde{c} to SampleInBall. (Since the maximum challenge entropy -- listed in Table 2 of the version 3.1 Dilithium spec -- is 257 bits, using more bits would have basically no effect on security.) The remaining bits of \tilde{c} will be output as part of the signature and checked at verification, but not used anywhere else.

2) As also suggested by Markku-Juhani O. Saarinen, we plan to fix the length of rnd (as described in my last email to the forum) to be the same in the hedged and deterministic case. The current plan is to use an all zeroes string for rnd in the deterministic case.

3)As suggested by Peter Pessl, we plan to fix the length of rnd to 256 bits instead of the 512 bits we had originally proposed. This saves a call to the Keccak permutation, and we agree with Peter that 256 bits is sufficient at all security strength categories.

Ray Perlner (NIST PQC)

[D. J. Bernstein]

NIST wrote, in email dated 20 Apr 2023 21:06:05 +0000:
> In order to make sure the argument for the BUFF security of Dilithium
> given in section 6.1 of https://eprint.iacr.org/2020/1525.pdf holds
> for all security strength categories, we plan to increase the size of
> the variable tr (which first appears at line 7 of Figure 4 in version
> 3.1 of the Dilithium spec.) from 256 bits to 512 bits.

Am I correct in understanding that NIST's words "BUFF security" here
refer to the conjunction of the M-S-UEO and MBS and NR properties
defined in the January 2023 version of that paper?

(I searched the paper for the phrase "BUFF security" but didn't find it.
The paper proposed a generic transformation called "BUFF" and claimed it
achieves M-S-UEO and MBS and NR, given EUF-CMA. Section 6.1 claimed that
Dilithium achieved these three properties in the same way as BUFF.)

Also, when NIST IR 8413 claimed that Dilithium without modifications
"satisfies several desirable 'beyond unforgeability' security
properties", citing that paper, am I correct in understanding that it
was also referring to M-S-UEO and MBS and NR?

If so, then it seems that there should already have been an erratum in
April 2023 for NIST IR 8413's statement that unmodified Dilithium has
these properties, and there should be an erratum now for NIST's April
2023 statement that modified Dilithium has these properties.

What I'm really curious about is the procedures that led to these claims
from NIST. Was it more sophisticated than "there's a paper saying these
properties achieved by Dilithium, ergo it's true"? Did NIST review the
proof and miss the error? Or not review the proof?

It seems that some paper reviewers missed the error, but this is less
surprising since the available evidence suggests that paper reviewers
for Crypto, S&P, etc. usually don't read proofs. Surely cryptosystem
selection for standardization should meet a higher bar.

---D. J. Bernstein

[John Mattsson]

Hi,

 

In our public comments on draft FIPS 204, we (Ericsson) also requested that NIST clarify exactly which additional security properties beyond unforgeability that ML-KEM satisfy (if any). I would expect NIST to do so in the final version.

 

I don't see any need to make an erratum for IR 8413. It is a status report for an ongoing standardization project. I think it might even be beneficial to leave it alone as a historical document.

 

Cheers,

John

--

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/20240221114536.845256.qmail%40cr.yp.to.