Re: [pkcs11] 'Hash then Sign' Discussions

[Robert Relyea <rrelyea@redhat.com>]

On 2/9/23 8:07 PM, Greg Scott wrote:

There has been discussion in the KMIP TC regarding various PQC topics including some material from KMIP members who are participating in some of the discussions regarding the NCCoE PQC Migration project and whether the analysis document would be available to the TC at some point soon or as some suspect to be issued as a NIST publication.

After the meeting in January Judith Furlong (KMIP TC Co-Chair) circulated a list of threads that had relevant information on the "hash then sign" discussions which have been happening on the NIST PQC Forum and within the IETF.

I confirmed with Judy at this week's KMIP TC meeting that these were public discussions and that these could also be circulated to the members of the PKCS#11 TC.

Thanks Greg, this is really helpful.

I conclude from this that:

1. we need to define multi-part versions of the signing functions and not HASH+Single part.
2. for at least Falcon and Sphinx we need the signature or some portion of the signature available at C_VerifyInit() time.

We'll probably need that for XMSS as well, and we probably need a multi-part change for HSS (same issue).

I see a couple of ways of solving this:

1. Create a new C_VerifyWithSignatureInit() function which takes the signature as a parameter (we could have a new C_VerifyNoSiganatureFinal() to match it, or just leave the existing C_VerifyFinal and either accept a signature (verifying it matches the original), or ignore the signature. We can adjust the spellings (maybe C_VerifyMultiPartInit()?)
   
2. For those mechanism that need it, include the signature in the Mechanism Parameters. Would probably only include those mechanism parameters in the C_VerifyInit call.
   
3. For those mechanisms that need it, include the nonce as part of the mechanism Parameters. If we do this, should we also include the nonce parameter for C_SignInit, which returns the nonce? In all our examples the nonce packaging in the signature will almost certainly be defined in the base specs, so applications will almost certainly pass just the signature and not the nonce separately.

Pre 3.0, we would be restricted to 2 or 3. Adding the function does generate some questions, though:

1. If you support C_VerifyWithSignatureInit(), should you also support it for existing muti-part operations (CKM_RSA_PSS_SHA256 for instance)?
2. C_VerifyInit() would seem to continue to work for single part operations, which means we wouldn't generate an error until the first C_VerifyUpdate(). Maybe that's fine because for single part only, that works this way today.
   

The link for the message sent to the KMIP reflector is https://www.oasis-open.org/apps/org/workgroup/kmip/email/archives/202301/msg00005.html

If for some reason you are not able to access this link, I have duplicated the message at the end of this email.

Greg

==

Greg Scott

E: greg.scott@cryptsoft.com

M: +61 406 255 166

Subject: 'Hash then Sign' Discussions

• From: "Furlong, Judith" <Judith.Furlong@dell.com>
• To: kmip <kmip@lists.oasis-open.org>
• Date: Sat, 14 Jan 2023 01:23:08 +0000

---

At yesterdayâs KMIP TC meeting I mentioned Iâd send out links to some of the âHash then Signâ discussions associated with the PQC algorithms that have been happening on the NIST PQC Forum and within the IETF.

Â

NIST PQC Forum

• Integration of Post-Quantum Signatures
• Design rationale for keyed message digests in SPHNICS+, Dilithium, FALCON? [cross with IETF CFRG]
• Whether to hash-then-sign with Dilithium and Falcon? [cross with IETF CFRG]
• Parameter selection for the selected algorithms

Â

IETF Crypto Forum Research Group (CFRG) has had several long email discussions on the topic

• Whether to hash-then-sign with Dilithium and Falcon? [cross with NIST PQC Forum and IETF LAMPS]
• Design rationale for keyed message digests in SPHNICS+, Dilithium, FALCON? [cross with NIST PQC Forum]

Â

IETF (Limited Additional Mechanisms for PKIX and SMIME (LAMPS)

• Whether to hash-then-sign with Dilithium and Falcon? [cross with IETF CFRG]
• How do we plan to solve the hash-then-sign paradigm in Dilithium, Falcon and Sphincs+)

Â

Judy

Â

Judith Furlong

Senior Distinguished Engineer, Security

Dell Technologies | ISG Chief Technology and Innovation Office

Office:Â +1-774-350-6287

Judith.Furlong@dell.com

Â