jadephilipoom
commented
6 months ago Here's some context that might be helpful:
- SPHINCS+ supports parameter sets with either SHAKE or SHA-2 as the underlying hash function.
- The current implementation uses SHAKE, although the reasons for that are not super strong. They include:
- for signing or keygen in the future we'd want to use SHAKE, since it has SCA protection
- NIST was previously considering dropping the SHA-2 parameter sets, but has since decided to keep them, so this no longer really matters
- the algorithm instantiation is a little more ergonomic for SHAKE than SHA2; while the SHAKE version just uses SHAKE for everything, the SHA2 version needs HMAC and MFG1 as well.
- Now, there are some reasons emerging why we may want to use SHA-2 instead, or at least make it possible:
- signing infrastructure might support SHA-2 faster than it supports SHAKE
- SHA-2 is slightly faster than SHAKE on OpenTitan because the implementation is not masked (10.5ms vs 12.5ms based on some quick ballpark benchmarks)
In addition to the SHAKE vs SHA-2 question, there's a separate but related question: should we allow a "pre-hashed" option (via an OTP setting or similar) in which the message we sign with SPHINCS+ is the hash of the ROM_EXT image, rather than the image directly? If we did this and used SHA-2, it would reduce boot time for large images because ECDSA and SPHINCS+ could use the same digest (although arguably it would also have an effect on the fault attack difficulty -- see the doc for some discussion).
I'm a little ambivalent on these options myself to be honest; I think there aren't a lot of terrible choices here, and the balance to strike is keeping ROM code as simple as possible while also retaining flexibility as much as we can. Either way, though, if we want to make it for ROM freeze we need to decide on this one pretty quickly. It's a not huge but also not trivial amount of implementation effort.
johannheyszl
timothytrippel
Description
This document proposes updates to the SLH-DSA (Sphincs+) implementation used in secure boot to provide configuration options that will simplify integration with offline and cloud based code signing infrastructure, while providing additional performance improvements in secure boot.