Dear NIST,
The current specification of CRYSTALS-Dilithium provides two versions. One deterministic and one randomized. I strongly think NIST should also standardize a hedged version where the seed is derived from a random string, a key, and the message. The deterministic version is according to the specification not recommended in scenarios where an adversary can mount side-channel attacks. The randomized version is (I assume) not recommended in scenarios where the PRNG cannot be fully trusted. A hedged version could likely be made to protect against both side-channel attacks and weak PRNGs. The Dual_EC_DRBG story has thought us the importance of not blindly trusting the PRNG. Putting minimal trust in the PRNG and trying to minimize the impact of a compromised PRNG is an essential part of following zero trust principles. Having hedged signature was one of the most requested features in the comments on FIPS 186-5 (Draft).
Best Regards,
John Preuß Mattsson
Dear NIST,
The current specification of CRYSTALS-Dilithium provides two versions. One deterministic and one randomized. I strongly think NIST should also standardize a hedged version where the seed is derived from a random string, a key, and the message.
Date: Fri, 08 Jul 2022 11:47:30 +0200From: Vadim Lyubashevsky <vadi...@gmail.com>On Thu, 2022-07-07 at 11:50 +0000, 'John Mattsson' via pqc-forum wrote:The current specification of CRYSTALS-Dilithium provides twoversions. One deterministic and one randomized. I strongly think NISTshould also standardize a hedged version where the seed is derivedfrom a random string, a key, and the message.The "hedged" version can simply replace the current randomized versionwhich does not take the key and the message as inputs. Since the key isshort and the message is already hashed anyway, including these twothings in the seed creation will probably have a negligible performanceeffect.If people think it's a good idea, it should be easy to incorporate andI suspect that it's better having just 2 versions of the algorithminstead of 3.Don't have two or three versions -- have just one!Signature creation should be defined to be a deterministic function of1. secret key,2. message, and3. a randomization string.
- Users can make deterministic signatures by setting the randomizationstring to something fixed in an application like the empty string.
--
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/f637a042d20b89ee65c687364989fdb085581dfd.camel%40gmail.com.
Vadim Lyubashevsky wrote:
> The "hedged" version can simply replace the current randomized version
I think that is a great idea.
Hanno Böck wrote:
>Please make one the default and don't spec several different versions
>of the possibly major crypto algorithm of the future internet. I think
>if we've learned one thing from past cryptography standards it's that
>excess flexibility is almost always bad.
I think there are strong reasons to have a deterministic implementation option. That enables testing which might otherwise be impossible. If the signature algorithm is implemented in a black box like an HSM, any randomized version (also hedged) implies blind trust in the HSM vendor. A deterministic version allows the user to verify that the HSM follows the specification and does not leak the private key by using bad randomness (I don’t know if that is the consequence in Dilithium, but it is in ECDSA). National states have in the past controlled cryptographic hardware manufacturers like the Swiss company Crypto AG and intentionally weakened the products. Putting minimal trust in the HSM manufacturer is an essential part of following zero trust principles.
Note that the ”versions” that are discussed would be the same algorithm from a protocol perspective. The verifier stays the same. The “versions” are just implementation choices for the signer.
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.
On the other hand, requiring only the ‘hedged’ version would mean that an implementation must do two passes over the message to be signed. This can be a practical issue; for example, if an HSM is signing a large message, it can’t hold the entire message internally, which means it must be fed the message twice.
You can, of course, get around this by hashing the message first (possibly external to the HSM), and then Dilithium signing the hash; however, that is obviously not transparent to the verifier; would it be appropriate to mandate that? The answer may be “yes”; I’m just pointing out the question…
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DB6PR0701MB3047E7AE2489938E5048CDD689829%40DB6PR0701MB3047.eurprd07.prod.outlook.com.
> On the other hand, requiring only the ‘hedged’ version would mean that an implementation
> must do two passes over the message to be signed.
I’m not sure it’s true, considering that every sane email or document signer (that I’m aware of) signs the hash, rather than the document itself.
> This can be a practical issue; for example, if an HSM is signing a large message, it
> can’t hold the entire message internally, which means it must be fed the message twice.
>
> You can, of course, get around this by hashing the message first (possibly external to the HSM),
> and then Dilithium signing the hash; however, that is obviously not transparent to the verifier;
> would it be appropriate to mandate that? The answer may be “yes”; I’m just pointing out the question…
In my understanding, this has been de-facto standard for a long time. Thus, IMHO, it is perfectly appropriate to (explicitly) mandate it.
Thanks!
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB54441756530D08538099094AC1829%40CH0PR11MB5444.namprd11.prod.outlook.com.
>Just to be clear, the "hedged" mode would replace line
>12 of Figure 4 in the dilithium spec with rho'=H(K | seed | mu) where
>seed is either "" in the deterministic case or a random 512-bit
>string in the randomized one.
Another benefit with this construction is that it decreases the chance for implementation mistakes like the infamous PS3 bug where the software signing used ECDSA with a fixed number instead of a per-message random number.
John
From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> on behalf of Vadim Lyubashevsky <vadim....@gmail.com>
Date: Friday, 8 July 2022 at 20:38
To: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>
> To view this discussion on the web visit https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-5cfaa1bc14fcaf0c&q=1&e=7d54690e-fff4-4895-a827-251fec8e42c2&u=https%3A%2F%2Fgroups.google.com%2Fa%2Flist.nist.gov%2Fd%2Fmsgid%2Fpqc-forum%2FDB6PR0701MB3047E7AE2489938E5048CDD689829%2540DB6PR0701MB3047.eurprd07.prod.outlook.com.
>
> --
> 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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-6e2b4d92811927c0&q=1&e=7d54690e-fff4-4895-a827-251fec8e42c2&u=https%3A%2F%2Fgroups.google.com%2Fa%2Flist.nist.gov%2Fd%2Fmsgid%2Fpqc-forum%2FCH0PR11MB54441756530D08538099094AC1829%2540CH0PR11MB5444.namprd11.prod.outlook.com.
>
> --
> 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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-7ee4af837dd02ec3&q=1&e=7d54690e-fff4-4895-a827-251fec8e42c2&u=https%3A%2F%2Fgroups.google.com%2Fa%2Flist.nist.gov%2Fd%2Fmsgid%2Fpqc-forum%2F806BC870-E868-4A0B-AEEA-0CF912E530F1%2540ll.mit.edu.
--
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://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-6d736be5ec352407&q=1&e=7d54690e-fff4-4895-a827-251fec8e42c2&u=https%3A%2F%2Fgroups.google.com%2Fa%2Flist.nist.gov%2Fd%2Fmsgid%2Fpqc-forum%2FCAE158z-09Kw06nufY_iOJm%253D2XCAudGyyi-3fkOB6bONd-AHGeg%2540mail.gmail.com.