Missing Prehashed algorithms for Ed25519

[sausix]

Using Ed25519 is strongly recommended according to the nice documentation. I've learned a lot. Thank you.

But the Ed25519 module seems to be incomplete, because there's no interface to provide prehashed data into the sign/verify functions.

This results is signing or verifying big files is limited to the available RAM or how big a bytes object can get.

Or is there a reason? Thank you.

[alex]

You are correct that we do not currently support ed25519ph variants.

There are two reasons for this:

1. No one has asked so far,
2. They have different security properties than ed25519 (notably they require the hash function to be strong), so we need to document this precisely.

[sausix]

Seems to affect ed448 too.

I actually did not ask for variants of curves or hash algorithms. These curves also don't allow others per definition as I read Wikipedia correctly. My concern is just the missing stream based hashing using the hash method of ed25519

[reaperhulk]

Prehashed isn’t really practical due to the design of ed25519 (pure eddsa). Take a look at the RFC (https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.6) and you’ll see that it hashes the private key, uses part of that resulting hash in the prefix of hashing the message itself, then uses the result of that to compute a point, which is then serialized and used in another hash that also contains the message.

[sausix]

Ok. It's more complicated but then it seems to have no elegant solution until it's possible to handover at least a file handle or a pipe to the backend which reads the stream and computes the hash.

[reaperhulk]

We're going to close this since the most appropriate solution here is ed25519ph (which OpenSSL does not yet support). We'll revisit when OpenSSL adds this.