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: RE: [pkcs11] HSS in version 3.1 of the specification


The reference in 6.65 should be [NIST SP800-208] not [NIST 802-208].

 

Section 4.3 of RFC 8554 indicates that I and q are part of the public key. It should be possible to generate the first step without the private key and outside the module. Adding some language to 6.65.5 would be helpful.

 

I’d wager that NIST would be happier if H(I || u32str(q) || u16str(D_MESG) || C || message) was computed inside the module’s boundary so that C is properly generated, but I don’t see where they’ve mandated it in SP800-208.

 

Sincerely,

Jonathan

 

 

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of JOHNSON Darren
Sent: Thursday, February 16, 2023 9:10 AM
To: pkcs11@lists.oasis-open.org
Subject: [EXT][pkcs11] HSS in version 3.1 of the specifciation

 

THIS MESSAGE COMES FROM AN EXTERNAL SOURCE. PLEASE VERIFY THE CONTENTS OF THIS MESSAGE BEFORE PROCEEDING.

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature



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