[lamps] Re: [pqc-forum] Pre-hash options for SLH-DSA

["Markku-Juhani O. Saarinen" <[e-mail]>]

Thanks David,


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.

Cheers,
- markku

Dr. Markku-Juhani O. Saarinen <[e-mail]>


On Tue, Jul 30, 2024 at 3:38 PM 'David A. Cooper' via pqc-forum <
[e-mail]> wrote:

> As was previously announced on the pqc-forum
> <https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/JKMh0D0pa30/m/vbflXolxAQAJ>,
> 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.
>
> 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
>
>
>
> --
> 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 [e-mail].
> 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
> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/60e9e8ca-3318-4017-b11a-7be327b90d75%40nist.gov?utm_medium=email&utm_source=footer>
> .
>