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

[JOHNSON Darren <darren.johnson@thalesgroup.com>]

Right.

sorry, I thought q was private.  It is hashed in to K. But I forgot that it is also concatenated to the final public key making it fully eposed.  So "Q = H(I || u32str(q) || u16str(D_MESG) || C || message)" could be pre-computed.

 

So is that the intent of CKM_HSS?  Is it assuming that the application passed in Q?

 

Or is CKM_HSS assuming that "message" is passed in?  My assumption was that it should expect "message".  Which is why it can accept "any" length.

But if it expects Q, then the input can't be "any".

 

The description in the spec states that is only a part of LMS....  See my other response to Bob.

 

NIST certainly expects/assumes everything is in the module.

Is it mandated in this case?  SP800-208 states that C is generated using an approved DRBG.  And it also states this "Implementations of the key generation and signature algorithms in this document shall only be validated for use within hardware cryptographic modules. The cryptographic modules shall be validated".

I would not want to try and argue that C can be generated outside the module...

 

And now we have two email threads on this topic... sorry.

I'll merge them the on the next reply

 

 

From: Jonathan Schulze-Hewett <schulze-hewett@infoseccorp.com> 
Sent: Friday, February 17, 2023 3:44 PM
To: JOHNSON Darren <darren.johnson@thalesgroup.com>; pkcs11@lists.oasis-open.org
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: Jonathan Schulze-Hewett <schulze-hewett@infoseccorp.com> 
Sent: Friday, February 17, 2023 3:44 PM
To: JOHNSON Darren <darren.johnson@thalesgroup.com>; pkcs11@lists.oasis-open.org
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