Hi,
my responses are inline below tagged with [DJ]
From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org>
On Behalf Of Robert Relyea
Sent: Friday, January 5, 2024 6:13 PM
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Groups - Post Quantum Signatures V4 Comments
On 10/22/23 4:10 PM, JOHNSON Darren wrote:
Hi,
I just wanted to confirm some details with this proposal. As well as add some minor editorial comments.
FIPS 204 defines pre-hashing for ML-DSA. We didn’t want to include that in the spec?
I missed that. It looks like a different mechanism, though. It would be single shot only. I'm not clear, however, does the pre-hash version need 'tr' (hash obj the public key)?
[DJ] I think you are referring to a mechanism where the value ‘μ’ from line 6 of the FIPS-204 is passed in by the application. Is that right?
6:
μ
←H(tr||M,512)
But I think FIPS-204 is referring the case where M is pre-hashed first, then then H(M) is passed in to ML-DSA.Sign(). Similar to CKM_ECDSA_SHA256. This topic is rather vague in FIPS-205. NIST has raised a question about this on the pqc-forum
seeking input from industry. The are considering a more formal approach as is done for EdDSA. For example:
"pure" signing: sign_sk(octet(0) || octet(OLEN(C)) || C || M)
"pre-hash signing: sign_sk(octet(1) || octet(OLEN(C)) || C || OID of hash function H || H(M))
I suspect this topic will be updated in the next version of FIPS 204 and FIPS 205.
So maybe it is better for us to wait for the updated versions before addressing pre-hashing.
FIPS 204 defines both random and deterministic variants. Don’t we want to have those defined separately in the spec? There are use cases where one may want a deterministic signature, as well as use case where one may want a randomized
signature.
Hmm I was considering that a compatible implementation detail, not necessarily visible to the application. I wouldn't use two different mechanisms. Probably an optional parameter that lets the application select
this on Signature creation (wouldn't be needed at verify because p' is already included in the signature.
[DJ] That seems reasonable to me.
CKA_VALUE for CKK_ML_DSA public key is defined as a “Big Integer”. But FIPS 204 defines it as an encoded value. So shouldn’t it be a “Byte Array”? The question/comment applies to CKA_VALUE for the ML-DSA private key as well.
Yes, the values for these shhould be the encoded values from the FIPS spec.
For Falcon, both public and private keys are encoded values as well. The proposal states that the CK_VALUE attribute for the public and private keys are a “Big Integer”. Shouldn’t they be “Byte Array”?
Yes.
I spent a lot of time on SLH-DSA, but I have the same question about the CKA_VALUE for the public and private keys. Shouldn’t they be “Byte Array”? They both contain multiple values.
Yes.
Also, FIPS 205 defines both random and deterministic variations of SLH-DSA. We didn’t want those called out separately in the spec either?
I think that's the same answer as ML_DSA.
[DJ] Agreed
Thanks
Darren