Hi Bob,
I replied inline below.
Thanks
From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org>
On Behalf Of Robert Relyea
Sent: Friday, March 3, 2023 1:17 PM
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Post Quantum Signatures - comments
On 3/3/23 2:18 AM, JOHNSON Darren wrote:
Sorry, I had to miss the call this week. So I apologize if these topics were already discussed.
Dilithium
Public key CKA_VALUE is defined as Y and the private key CKA_VALUE is defined as X. This are probably just copy+paste from existing algorithms?
The dilithium public and private keys are made up of multiple values. The dilithium spec defines bit packed encoding of these values. Should we be calling out
those sections for formatting? Similar to EC Point confusing in the past, encoding/formatting should be clear. Or are we waiting for some ASN.1 definitions for how to encode these values?
Yes, I should update them.
CKM_DILITHIUM.
The text for this mechanism doesnât specify if it supports single vs multi part, and/or both. For most other mechanisms, the text description of the mechanisms
states what type of signatures it is for. For consistency, shouldnât this one follow that convention? The table that defines the input/output lengths does specify that this mechanism is only for single part. Why is this only single part? The algorithm
supports both single and multipart usage without any API complications.
If I assume we arenât trying perform the hash define in step 10 outside of the token, then shouldnât the input length be âanyâ instead of âhLenâ.
If we wanted to allow a true pre-hashed variant, it should be yet another mechanism to indicate it is a pre-hashed variant with the hash step performed outsideâ
although I donât think we will be defining that before industry or standards bodies define it first.
The spec defines the single binary representation of the public key. It seems best to use that rather than have everyone try to split up the components. The exception is if we expect that ASN.1 would represent the public key as it's components.
Then it would make since to keep them separate in the PKCS #11 module.
[DJ] I agree that the single binary representation makes it simpler.
CKM_<hash>_DILITHIUM
These all use the wording âas described initially in [NIST SP-800-5x]â.
If we are going to document these pre-hash variants (which Iâm fine with or without them at this time), they should probably say that these mechanisms hash the
message first, then perform the signature âas described initially in [NIST SP-800-5x]â. At least they should be described
that way until NIST defines a variant with pre-hashing
I'm actually going to remove CKM_<hash>_DILITHIUM since I don't expect NSIT to define a variant with pre-hashing (after looking at the discussion).
[DJ] Agreed
Most of the the same comments all apply to Flacon and Sphincs+, so I wonât echo them here.
For Sphincs+ you donât include the Robust variant from the spec. Was this intentional?
Which variant? No it's wasn't intentional (I don't think).
[DJ] You defined the 6 parameter sets. But for each one of those, there is a âsimpleâ and ârobustâ variant. Section 7.2 and 7.2.1 of the spec describes them.
Thanks for the early comments!
bob
Thanks
Darren