-
Notifications
You must be signed in to change notification settings - Fork 157
Open
Description
Was there an intentional choice to omit SHA2 midstate caching from the SLH-DSA crate or is this still a "to-do" for later?
The SLH-DSA spec is written intentionally to encourage this, by padding
Also the HMAC here can be cached.
In case you are thinking "the perf improvement isn't worth it", you would be wrong. In my SLH-DSA implementation (closed source for now), I benchmarked signing with and without midstate/HMAC caching.
Without midstate caching
Params | keygen | signing | verifying |
---|---|---|---|
SLH-DSA-SHA2-128f |
3.2 ms | 108 ms | 6.8 ms |
SLH-DSA-SHA2-128s |
314 ms | 2345 ms | 2.4 ms |
With midstate caching
Params | keygen | signing | verifying |
---|---|---|---|
SLH-DSA-SHA2-128f |
1.5 ms | 45.1 ms | 3.2 ms |
SLH-DSA-SHA2-128s |
143 ms | 1102 ms | 1.1 ms |
On average, this midstate caching improves speed by a factor of about 2.2x on my machine, at least for 128-bit parameter sets. I haven't implemented higher security parameter sets yet.
Metadata
Metadata
Assignees
Labels
No labels