Re: [lamps] [EXTERNAL] Re: LAMPS Virtual Interim in Sept. 2022

[Ilari Liusvaara <[e-mail]>]

On Fri, Sep 16, 2022 at 04:44:55PM +0000, Mike Ounsworth wrote:
> + CFRG as this is request for crypto security review
> 
> 
> Issue summary:
> 
> - Needing to stream your entire message to your crypto module is
>   dumb (think streaming an entire firmware image to your network HSM
>   for code-signing, or to your TPM for secure boot validation; yuck).
> - You want to send just a hash.
> - Both Dilithium and Falcon have, as their first internal step' a
>   hash of the message prepended with a nonce (the pubkey for
>   Dilithium, and a random r for Falcon), I assume in order to block
>   pre-computed collision attacks.
> - If you, for example, do SHA256(m) before calling Dilithium.sign(),
>   then you have re-introduced that collision attack.
> - You can externalize that first hashing step of the Dilithium /
>   Falcon sign / verify algs outside of the crypto module without
>   breaking interop, but doing so will need to be mentioned in the
>   standards, and will need security review.

An alternative to just sending a hash is defining a structure that
represents a salted hash of piece of data and then signing that
structure.

As far as I understand, the X.509 signature algorithm model is
sufficiently flexible that this could be done by defining a special
X.509 signature algorithm.

However, at least in some contexts, there are very nontrivial
related considerations. E.g., COSE "hash-once-sign-twice" stuff.

With SPHINCS+, these constructions are even more useful, as
externalization is not possible, and (unsalted) prehashing leads to
a security issue. Furthermore, SPHINCS+ is currently the only
trustworthy PQ signature algorithm: Currently Dilithium and Falcon
are definitely not trustworthy (NSA effectively endorsing level 5
Dilithium nonwithstanding).


And as for purpose of that prepending, for Dilithium, it indeed looks
to be to block precomputed collision attacks. However, for Falcon,
the primary purpose seems to be to block a possible attack (which might
be catastrophic) if the same message is signed twice; blocking collision
attacks seems to be a side effect.


Dilthium looks straightforward to externalize: Have interface that
passes in mu instead of m. Getting it wrong breaks interop, so it does
not look to be too bad interface.

However, Falcon is completely another matter. The lesser problem is
that one needs to pass in (block-aligned) SHAKE-256 state, and not a
hash. The serious problem is that since getting generation of r wrong
might have catastrophic consequences, it is not possilble to pass that
in to any sort of security module. One would have to have some sort of
two-pass interface, which is quite radical deperture from usual sort of
one-pass signature interface.



-Ilari