OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: HSS in version 3.1 of the specifciation


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.
 

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?

 

Thanks



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]