Post Quantum Signatures - comments

[JOHNSON Darren <darren.johnson@thalesgroup.com>]

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?

 

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.

 

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

 

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?

 

Thanks

Darren