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

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Sep 11, 2024 at 3:59 AM Daniel Huigens <[e-mail]>
wrote:

> Hi Phillip,
>
> I know you said you'd write a separate email about the context parameter
> but as I wrote before I think it can be used to solve the issue you're
> describing here too.
>
> In particular, if you call Ed448(sk, SHA3-512(content), context =
> "SHA3-512 hash of <content type> for MyAwesomeApplication") then there's
> no risk of reusing the same signature with a different hash algorithm, or a
> different type of content, or an entirely different application (although
> as you said we shouldn't be sharing keys between applications anyway).
>
> The same is possible with ML-DSA and Ed25519ctx. So, I don't think there's
> a need to introduce new variants.
>
> The pre-hash variants of EdDSA are also already more poorly supported than
> the pure variants, and any new variants are even less likely to be
> well-supported (and thus be used to solve this problem).
>
> Of course, this doesn't answer the question of whether there are unsafe
> uses of Ed448 and Ed25519, but if there are, I think it's easier to tell
> applications to add a context parameter than to use an entirely new variant.
>

At the code level, all these various digest modes all come down to the same
thing

SignInner (  Digest ( <preamble> T<thingsigned> <postamble>))

Where 'preamble' and 'postamble' are specified by the signature algorithm
and  T<thingsigned>  is some serialization of some stuff and either the
data itself or the digest of the data.

If we go down to the bytes of Ed448 or ML-DSA, these arguments turn into
arguments over whether to shift bytes a slot to the left or the right and
whether to use <data> or { H<data>, id(H)) to bind to the thing signed.


And I came up with the exact construct you did and it works fine for Ed448.
But it does not provide for a consistent use of the context slot across all
signature algorithms. My theory of the context parameter is really the
rationale for rejecting that approach.

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'.

And the problem that confusion leads to is people who have a SHA-2-256
digest are likely to end up using the 'prehash' mode thinking it gives them
an assurance it does not.

This hasn't been a problem up to now because Ed25519/Ed448 haven't been
getting a lot of use in situations where the distinction matters and
Ed448ph/Ed25519ph were the only things of their kind. Now we are going to
have people writing code that supports ML-DSA/KEM, I think it very likely
we are going to see increased takeup of Ed/X448 at the same time.