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

[Mike Hamburg <[e-mail]>]

Hi Daniel,

Sorry you’re right, I misread the RFC.  More precisely, the prehash function is a parameter in the overall construction, but ed25519ph and ed448ph fix that parameter.

Regards,
— Mike

> On Sep 11, 2024, at 2:26 PM, Daniel Huigens <[e-mail]> wrote:
> 
> Hi Mike,
> 
> On Wednesday, September 11th, 2024 at 22:35, Mike Hamburg wrote:
>> Phillip points out that this vulnerability applies to EdDSA with prehash mode, because it doesn’t have a firewall at all, except between “yes prehash” and “no prehash". EdDSA uses a fixed hash function internally: SHA-512 for Ed25519, or SHAKE256 for Ed448. But the prehash mode signs the hash of a message, without indicating what hash function was used.
> 
> Ed25519ph and Ed448ph do indicate which pre-hash functions are used,
> by simply hardcoding them - to the same functions that are used inside
> PureEdDSA: SHA-512 for Ed25519 and SHAKE256 for Ed448.
> 
> And as specified, the message is pre-hashed inside the function,
> so there should be no risk of using the wrong one - although some
> implementations do allow passing a hash that was computed externally
> by the application, but obviously to remain compliant it needs to use
> the specified hash function (and this is usually properly documented
> as far as I've seen).
> 
>> So if an attacker can convince a victim to use a weak hash for verification
> 
> .. then they wouldn't be using Ed25519ph or Ed448ph, but some broken
> variant of it. I don't think there's much we can do to protect
> against that.
> 
> Phillip's message, as I understood it, was more about the case where the
> signer decides to use e.g. Ed448(SHA512(M)) rather than Ed448ph(M)
> because they don't like SHAKE, or so. That's when the hash function
> firewall is missing, and the context parameter could be used to add it
> back.
> 
> Best,
> Daniel