[jose] Re: [lamps] Re: [CFRG] Do we have unsafe uses of Ed448 and Ed25519? Fix Ed448?

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

Hi Daniel,

Note the FIPS 204 comment *"message representative that may optionally be
computed in a different cryptographic module"* on line #6 of
ML-DSA.Sign_internal (Alg 7.) and on line #7 of ML-DSA.Verify_internal
(Alg. 8).

If the "mu" hash (message representative) can be computed in a different
module, so can the hashes that are used to build "mu" in both prehash and
pure versions. I've asked NIST for little clarification on this bit, as it
indeed somewhat violates some other language in the spec wrt allowed
interfaces.

But -- If you're signing a hash from an another module within your security
boundary, you should be okay. If I'm using a private key on a smart card to
sign a 10-gig firmware update, I'm not going to pump the entire thing
through the smart card it to hash it, but compute the hash on a PC that has
a secure link with the smart card. (This is a very real-life use case.)

Cheers,
-markku

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


On Thu, Sep 12, 2024 at 6:43 PM Daniel Huigens <daniel.huigens=
[e-mail]> wrote:

> Hi Phillip,
>
> On Thursday, September 12th, 2024 at 19:48, Phillip Hallam-Baker wrote:
>
> The underlying problem here and the one that I think is causing the
> confusion is that Ed448 or ML-DSA both specify a mode that is being refered
> to as 'prehashed' but they are not the same thing. ML-DSA is a mode that
> turns ML-DSA into a drop in replacement for RSA with the exact same
> affordances: bring your existing hash and it gets signed. Ed448 is 'hash
> your data with SHAKE256 and give me that digest'.
>
>
> That is not what the specs say. Both FIPS 204 and RFC 8032 say that the
> pre-hash variant accepts a *message* (not a hash of a message) and hashes
> the message (inside the function) before passing it to the internal signing
> function. The only difference is that HashML-DSA also has a parameter to
> say which hash function should be used, whereas in HashEdDSA it's hardcoded.
>
> Of course, you *could* reinterpret the functions that the specs define as
> ones that accept a hash digest, and implement it that way, but then *that* is
> what introduces the risk of using the wrong hash function, not the way
> they're defined in the specs.
>
> And note that strictly speaking, this risk exists for both algorithms, if
> you implement it like that: it's then equally possible in HashML-DSA to
> pass a hash digest generated using a hash function that doesn't match the
> one you say you used, as it is in HashEdDSA to use a hash function
> different than the one that the documentation says to use.
>
> ---
>
> I actually think a lot of this confusion comes from naming: if they had
> called HashML-DSA and HashEdDSA the "additional hash variants", or
> "one-pass/streaming variants", rather than the "pre-hash variants", it
> would have been clearer; and the term "pre-hash*ed* variants" could then
> be used for the variant where you pass a hash digest rather than a message
> (if we need such a construct at all, that is - as again I'd argue that in
> that case you can just use the pure variant with a context string).
>
> Best,
> Daniel
>
> _______________________________________________
> Spasm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>