RE: [pkcs11] HSS in version 3.1 of the specifciation

Hi Bob,

that wasnât the point of my question. I fully understand the whole single part way it is defined and the limitation with verify.

My question was that for HSS, the spec uses the same wording we use for CKM_RSA_PKCS, or CKM_ECDSA, where the application computes the hash and provides the hash as input to the C_Sign() call.

For ECDSA without hashing, we state âThis mechanism corresponds only to the part of ECDSA that processes the hash value, which should not be longer than 1024 bits; it does not compute the hash value.â.

For DSA without hashing, we state âThis mechanism corresponds only to the part of DSA that processes the 20-byte hash value; it does not compute the hash valueâ.

For RSA without hashing, we state âThis mechanism corresponds only to the part of PKCS #1 that involves block formatting and RSA, given a hash value; it does not compute a hash value on the message to be signedâ.

These all make sense as many standards define these algorithms as Sign(hash(message)). So the part that only processes hash is well defined.

For HSS, we also state âThis mechanism corresponds only to the part of LMS that processes the hash value, which may be of any length; it does not compute the hash valueâ.

There is no part of LMS that processes a hash value. LMS process the whole message that is to be signed. LMS is defined as Sign(message).

So it is not clear to me how CKM_HSS can âcorresponds to only to part of LMSâ.

I assume CKM_HSS is computing the full LMS signature over the provided data as that is the only way it can work. The description we have in the spec suggests it is only doing a part of LMS.

Maybe Iâm just nit picking over the wording?

Maybe I am.

Thanks

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Robert Relyea
Sent: Friday, February 17, 2023 5:16 PM
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] HSS in version 3.1 of the specifciation

On 2/16/23 7:10 AM, JOHNSON Darren wrote:

Hi,

we are trying to adopt the HSS definition from version 3.1 of the specification, and it doesnât seem to make sense.

This overlaps with the discussions you started for PQC signatures for v3.2. So we may just decide to part this discussion and update HSS once we resolve the other questions you raised.

Let me know if that is what you want to do.

Orâ if Iâm missing some detail and Iâm wrong, please let me know.

It only has one type of signatureâ âHSS without hashingâ which defines the single part signature. The single part aspect is fine as defining multi-part APIs for hash based signatures is being worked on for v3.2.

But the general description of this signature doesnât make sense.

This section states âThis mechanism corresponds only to the part of LMS that processes the hash value, which may be of any length; it does not compute the hash valueâ.
What âhash valueâ is this referring to.  The first step of LMS is âQ = H(I || u32str(q) || u16str(D_MESG) || C || message)â, for simplicity, lets just call it âQ=hash(private key | random | message)â.  An application canât pass Q.

Yes, that's why it's defined as a single shot operation. Sign isn't a problem, but verify needs the signature at the beginning (because 'C' is in the signature).

For now you can only do C_Verify_Init(), C_Verify() for HSS. Unlike RSA, there isn't a HSS_SHA1 type signature, the Hash is the same hash as the WOTS_Hash of the bottom tree always.

 
Similar to your new definitions for SPHINCS, Dilitium, etc, should this section just be âHSS Signatureâ?

And the multi part APIs and the topic of hash-than-sign will be sorted out with v3.2?

yes, I thing we should plan for that.

Thanks

pkcs11 message