For SLH-DSA, we are currently considering assigning an OID for one pre-hash option for each parameter set, as in the table below. For the SHA2 parameter sets, SHA-512 would be used for the pre-hash at all security levels. While SHA-256 would provide sufficient security for the category 1 parameter sets, SHA-512 is faster than SHA-256 on many platforms when hashing large messages. SHA-512 is also a more conservative option, which many people have requested. For the SHAKE parameter sets, SHAKE256 would be used with the category 3 and 5 parameter sets. For the category 1 parameter sets, SHAKE128 would be used, since it is faster than SHAKE256 and it provides sufficient security for category 1.
A slightly different approach that could be followed is the one
recommended in Section 4 of
https://www.ietf.org/archive/id/draft-ietf-lamps-cms-sphincs-plus-07.html
for selecting a digest algorithm to use in CMS. The
recommendations in that draft are the same as in the table
below, with the exception that SHA-256 is recommended when using
the SLH-DSA-SHA2-128s and SLH-DSA-SHA2-128f parameter sets.
We would appreciate any feedback people may have about what OIDs to assign for pre-hash versions of SLH-DSA.
Thank you,
David
parameter set |
pre-hash function |
SLH-DSA-SHA2-128s |
SHA-512 |
SLH-DSA-SHA2-128f | SHA-512 |
SLH-DSA-SHA2-192s | SHA-512 |
SLH-DSA-SHA2-192f | SHA-512 |
SLH-DSA-SHA2-256s | SHA-512 |
SLH-DSA-SHA2-256f | SHA-512 |
SLH-DSA-SHAKE-128s | SHAKE128 with 256 bits of output |
SLH-DSA-SHAKE-128f | SHAKE128 with 256 bits of output |
SLH-DSA-SHAKE-192s | SHAKE256 with 512 bits of output |
SLH-DSA-SHAKE-192f | SHAKE256 with 512 bits of output |
SLH-DSA-SHAKE-256s | SHAKE256 with 512 bits of output |
SLH-DSA-SHAKE-256f | SHAKE256 with 512 bits of output |
Collision resistance assumptions aside, let's look at these technical choices:
SLH-DSA-SHA2-128s and SLH-DSA-SHA2-128f versions would currently *not* require an implementation of SHA-512 -- the proposed prehashing option would make SHA-512 necessary for the 128s and 128f variants too. Other SHA2 versions of SLH_DSA require both algorithms. I'd think that it would be better if the SHA2-128s and SHA2-128f variants used SHA-256 as a prehash, as was suggested in the cited internet draft.
Rationale: As everyone knows, SHA-256 and SHA-512 are two different algorithms from an implementation viewpoint; they have different block sizes and state sizes. SHA-256 works on 32-bit words, SHA-512 works on 64-bit words; the SHA-512 round constants require more than twice ROM bits, etc. SHA-512 has faster throughput on regular 64-bit PCs but not on smaller units like security controllers, which are an important use case for these two variants (OpenTitan already supports 128s). Requiring SHA-512 complicates hardware implementations of these smaller variants significantly and more than doubles its size ( https://ia.cr/2024/367 ). With the current generation, acceleration on microcontrollers is often available for SHA-256 but not SHA-512. The vast majority of the internal hash ops is SHA-256 for all security levels anyway, and SHA-256 is usually faster for those tasks.
On internal hashing of SLH-DSA-SHAKE-128s and 128f: Your posting didn't clarify this, but I assume you're planning to keep the *internal* hashes of SLH-DSA-SHAKE-128s and 128f as SHAKE256, as per Section 10.1 of the FIPS 205 ipd. For SLH-DSA's internal hashing (actually generating and verifying hash-based signatures), SHAKE128 and SHAKE256 are essentially the same algorithm. For these hashes the difference ends up being the contents and location of a few padding bits within a block -- there is no security or performance difference between SHAKE128 and SHAKE256 for single-block messages.
Hence there should be no complication in using the faster-throughput SHAKE128 for SLH-DSA-SHAKE-128 *external* prehashing (as proposed) while all of the internal hashing is kept as SHAKE256 as it currently is.
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/60e9e8ca-3318-4017-b11a-7be327b90d75%40nist.gov.
+1 on Markku’s points. I was initially advocating for simplicity and SHA512 and SHAK256 for the SHA2 and SHAKE SLH-DSA parameters respectively. But I was convinced while discussing draft-ietf-lamps-cms-sphincs-plus that SH256 and SHAKE128 make sense for the Level 1 as Markku is also pointing out.
From: Markku-Juhani O. Saarinen <mjos....@gmail.com>
Sent: Tuesday, July 30, 2024 2:51 PM
To: David A. Cooper <david....@nist.gov>
Cc: pqc-forum <pqc-...@list.nist.gov>; sp...@ietf.org
Subject: [EXTERNAL] [lamps] Re: [pqc-forum] Pre-hash options for SLH-DSA
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. |
On 30 Jul 2024, at 17:38, 'David A. Cooper' via pqc-forum <pqc-...@list.nist.gov> wrote:
As was previously announced on the pqc-forum, SLH-DSA will specify separate "pure" and "pre-hash" versions. For the pre-hash versions, each of the OIDs that NIST will assign will specify both the SLH-DSA parameter set and the function to use for pre-hashing. Given the number of SLH-DSA parameter sets and the number of NIST approved hash functions and XOFs, there is a very large number of potential combinations. While assigning OIDs for more combinations would allow for more flexibility, we believe there is a benefit in minimizing the number of options in order to facilitate interoperability.
I would disagree with the idea that a specific parameter set necessarily needs to be paired with a specific hash function.
After all, the most common case where you use prehashing is because have two different computational devices A and B; A with access to the data being signed, and B with access to the private key (and with a narrow data pipe connecting the two). In this case, A and B might have different trade-offs in terms of hash functions, and it would make sense to allow the implementor to select things appropriately (as long as security concerns are addressed).
If you’re worried about “interoperability”, that is, the verifier knowing what the prehash function is, this needs to be addressed already (because, for example, SLH-DSA-SHA2-128s and SLH-DSA-SHAKE-128s signatures and public keys look exactly the same, and so any such communication requirement needs to be addressed anyways…
--
Actually, I doubt that SLH-DSA will often be used within protocols (except possibly as something such as root certs, where prehashing would not be likely) – I’d expect implementers would find that the signing performance is not sufficient for most interactive protocol uses.
Instead, the use of SLH-DSA with prehashing would be more likely be image signing (where interoperability is less of a concern).
From: Dang, Quynh H. (Fed) <quynh...@nist.gov>
Sent: Wednesday, July 31, 2024 1:27 PM
To: Scott Fluhrer (sfluhrer) <sflu...@cisco.com>; Cooper, David (Fed) <david....@nist.gov>; pqc-forum <pqc-...@list.nist.gov>
Subject: RE: [pqc-forum] Pre-hash options for SLH-DSA
Hi Scott,
Let me try to understand your suggestion.
An OID for a specific SLH-DSA-prehash signature and an OID for a pre-hash hash function when interoperability is a concern in a protocol for signature verification.
Is my understanding correct here ?
Regards,
Quynh.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB544442CC5ED7AE1B73A14E10C1B12%40CH0PR11MB5444.namprd11.prod.outlook.com.
Dear all,
As with SLH-DSA, and as previously announced, ML-DSA will have domain separated pure and pre-hash variants. We are currently considering specifying OIDs for the pure variant of ML-DSA and a pre-hash variant using SHA512 for the pre-hash. We plan to do this
for each of the 3 parameter sets of ML-DSA (ML-DSA-44, ML-DSA-65 and ML-DSA-87).
We would appreciate any feedback people may have about which OIDs to specify for ML-DSA
Thank you,
Ray
Hi Ray,
Can you comment on the choice to use SHA2 for the prehash despite the fact that ML-DSA internally uses SHA3 (SHAKE)? I don’t necessarily disagree with the decision, but I would like to hear the rationale from NIST.
---
Mike Ounsworth
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DM6PR09MB485527D4EAB537B60FDCB8A59CB12%40DM6PR09MB4855.namprd09.prod.outlook.com.
Hi Mike,
The main thinking for focusing on SHA512 for pre-hash was that even pure ML-DSA essentially pre-hashes the message with SHAKE256 when computing the message representative µ, and the FIPS already includes allowances for the message representative to be computed in a different cryptographic module from the one that uses the private key. While we are aware that the inclusion of a public key hash in the computation of the message representative could break some applications that don’t have access to the public key when doing pre-hash, we were thinking the more likely scenario where an additional pre-hash step would be desirable is when dealing with large messages on platforms with SHA2 hardware support, but not SHA3 hardware support.
We are open to the possibility that additional OIDs may need to be defined now or in the future, but all else being equal, our preference would be for fewer options.
Best,
Ray
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DM6PR09MB4855424DA9DB254DCDB136589CB12%40DM6PR09MB4855.namprd09.prod.outlook.com.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CA%2BiU_qkxFEY2jhYYoMy79g-GOp9kuzygatM%2BCw39nQQxJ5NpwA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB5444AB79F4C156238C2D78CDC1B12%40CH0PR11MB5444.namprd11.prod.outlook.com.
Ok, so we’re talking about assigning OIDs, rather than what combinations are allowed (other than what is required for security – I have no issues with those constraints).
I then have no objection…
Instead, the use of SLH-DSA with prehashing would be more likely be image signing (where interoperability is less of a concern).
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEEbLAaDPdYSGx_AE_rkVygKeGg2fy70bhbt-Chh9UaZSNsTFA%40mail.gmail.com.