search

lamps-wg / dilithium-certificates

I-D that describes the algorithm identifiers for NIST's PQC Dilithium algorithm for use in the Internet X.509 Public Key Infrastructure
Other
6 stars 3 forks source link

Deterministic or randomized Signing? (from Markku) #6

Open csosto-pk opened 2 years ago

csosto-pk commented 2 years ago

Section 5 states "The randomized version can be invoked by leaving K as EMPTY." Private key formats are determined by application requirements and should not be used as "APIs" to affect functionality as suggested. Side-channel secure implementations will only use this type of plaintext ASN.1 encoding for backup/transport (never actively) and are likely to always perform randomized signing. Some other implementations (perhaps without trustworthy RNGs) may always perform deterministic signing; this does not break the interoperability of signatures. The explanation for the "tr" field in that private key format is not accurate (see above).

csosto-pk commented 2 years ago

This version does not allow leaving K empty as it is a fixed-length octet string. Some implementations may need it, though.

Dilithium allows the same private key to be used for randomized and non-randomized signing; the K value does not affect the public key or break the compatibility of signatures. In fact, some implementors may choose to use the random seed K in a different way; additionally binding it in a hash with some RNG output, the public key, a device-intrinsic key, or whatever. This would often be sensible from security viewpoint. The K value is merely used to randomize the signing process. The only way having a different randomization method could be an issue is if ACVP / FIPS testing turns out to be overly rigid with Dilithium modules. But it is entirely up to the implementation.

bwesterb commented 1 month ago

Agreed, I think it's fine to allow for deterministic signing.