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

[Robert Relyea <rrelyea@redhat.com>]

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