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

[Jonathan Schulze-Hewett <schulze-hewett@infoseccorp.com>]

In the only PKCS#11 implementation of LMS I've dealt with, C_Sign took just
the message as input, not the output of a hash of I||q||D_MESG||C||message.
Since we're the authors of the original proposal I assume that's what we
meant. I also suspect that we copied the language from the other algorithms
in an attempt to indicate that we're not doing hash then sign, just the LMS
signature step. The fact that HSS/LMS is a hash based scheme makes things
convoluted. If it wasn't a hash based scheme I think the existing language
would be clearer. Suggestions for updating the language?

Sincerely,
Jonathan

-----Original Message-----
From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of
JOHNSON Darren
Sent: Friday, February 17, 2023 10:24 PM
To: Jonathan Schulze-Hewett <schulze-hewett@infoseccorp.com>;
pkcs11@lists.oasis-open.org
Subject: RE: [pkcs11] HSS in version 3.1 of the specification

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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.oasis-
open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php&data=05%7C01%
7Cschulze-hewett%40infoseccorp.com%7Ce9af4b943d8e4132badf08db1167f40e%7Cf8af
a6aefcf941af84e8cca28837a74a%7C1%7C0%7C638122910395787140%7CUnknown%7CTWFpbG
Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
000%7C%7C%7C&sdata=7gWW%2BTs0LuEnKPeFav0oWoWNiXxYbHJ9Vf8zWOucMHE%3D&reserved
=0

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