Re: [CFRG] [EXTERNAL] pq firmware signing question

[Ilari Liusvaara <[e-mail]>]

On Mon, Mar 18, 2024 at 03:45:00PM +0000, John Mattsson wrote:
> 
>   *   The conservative SLH-DSA is security wise quite attractive for
>       this use case but the keys are a bit big. My hardware people
>       tells me that they want to keep the amount of burned bytes
>       small. As ML-DSA is in CNSA 2.0 my feeling is that ML-DSA is
>       more commercially available. ML-DSA also have better
>       performance and smaller keys.

It appears that SLH-DSA keys are actually much smaller:

- CNSA 2.0 ML-DSA has 2592 byte public key.
- AFAICT, SLH-DSA has 64 byte public key.

It is the SLH-DSA signatures that are much larger than ML-KEM
signatures. However, the retuned sizes below are less than 2.5x the
4595 byte ML-DSA signature size.


>   *   The private key in trust anchors is typically used a small
>       amount of times. SLH-DSA tuned for much less than 2^64
>       signatures is a good fit. The signing speed is almost
>       irrelevant. The verification speed is important.

Looking at recent paper (eprint 2024/018) on retuning
SPHINCS+/SLH-DSA:

Category I, 1M signatures

h=18, d=2, a=14, k=12, w=16: Size 4304, cost 968690/762


Category III, 1M signatures:

h=24, d=3, a=13, k=16, w=16: Size 9648, cost 890349/1477


And 1M signatures seems plenty: To burn through this in a millenia
takes multiple releases per day (which is extremely fast pace, even for
single-layer setup).

Advantage of using SPHINCS+ retuned to small number of signatures over
stuff like XMSS is that there are no state-tracking problems.

However, there is certificational problem here: This will hold, but
can we get this certified enough?




-Ilari