Consider adding Ed25519ph and Ed448ph
Closed this issue · 12 comments
I think including the HashEdDSA variants (namely, Ed25519ph and Ed448ph) in addition to the PureEdDSA variants (namely, Ed25519 and Ed448) should be considered. The motivation is to allow using these algorithms with any streaming interfaces that will hopefully be added soon (see w3c/webcrypto#73).
Thanks for the suggestion! I agree that could make sense. Most likely, these should be entirely separate algorithms from the perspective of the Web Crypto API, given that the parameters and possible input types (especially once we support streaming) will most likely be different. This would also mean that an implementation is free to not implement them, as with any algorithm, but that also seems reasonable, I think?
@twiss Yes, I agree with everything you said! Depending on the timeline of this proposal versus streaming, it might make sense to consider it as part of this proposal.
I prefer landing Ed25519, Ed448, X25519, and X448 irrespective of streaming and separate of the ph variants.
I have yet to see any use of the ph variants in security token formats or protocols developers deal with, let alone applications.
Yeah, that's also fair enough. There are some protocols (such as OpenPGP, which isn't necessarily an ideal example since its use of Ed25519 predates RFC8032, but nevertheless) which already had a mechanism for pre-hashing, and thus ended up using that rather than Ed25519ph. Maybe that will end up being the norm for applications that need prehashing; not sure.
In any case, if it's needed / wanted we can always add them later, as they should be separate algorithms, anyways.
which already had a mechanism for pre-hashing, and thus ended up using that rather than Ed25519ph. Maybe that will end up being the norm for applications that need prehashing; not sure.
It might be worth mentioning that, while doing that is possible, it is generally better to use HashEdDSA directly. One reason is, for example, that prehashing and then using PureEdDSA effectively signs two documents: the hash and the hashed document. In other words, an attacker obtains a signature that is valid for M in the context of the application that uses prehashing, and a signature for H(M) in any other context. HashEdDSA explicitly prevents such issues.
Yeah, that's true. Probably, in that case, the applications shouldn't be sharing keys - but still it's true that HashEdDSA solves this in a cleaner way.
I consider that it's better to work from now (and not later) on a generic interface that allows to include the ph variants.
At the risk of being glib, Web Crypto itself is a generic interface that allows adding more algorithms later. More importantly, there are concrete differences between, for example, Ed25519 and Ed25519ph - e.g. the latter allows streaming, the former doesn't. So if we ever add streaming, I think it's clearer if they're separate algorithms, so that you can more easily determine whether a given algorithm supports streaming, for example. However, even if we change our mind, and want to add them to the same algorithm later, it's still possible - because Ed25519 is equivalent to { name: 'Ed25519' }, and we could always add { name: 'Ed25519', prehash: true } or something like that, if for some reason we think that's better than just calling it Ed25519ph.
OpenSSL just added support for ph variants: openssl/openssl#6277 openssl/openssl#19705
If we chose to include this in the existing draft, which I don't think we should, we'd also have to request IANA registrations for new JWK crv subtype identifiers and possibly new JWS alg identifiers for the ph variants. The existing registrations from RFC 8037 are only for the PureEdDSA variants.
Alternatively, the jwk format key import/export step would just be an error.
I am not saying that we should include them at this point either. The main point of this issue is to ensure that any design decisions made as part of this proposal won't get into the way of adding the ph variants later, I think :)
After looking at this more I came across this text in RFC 8032, Section 8.5:
The Ed25519ph and Ed448ph variants are prehashed. This is mainly
useful for interoperation with legacy APIs, since in most of the
cases, either the amount of data signed is not large or the protocol
is in the position to do digesting in ways better than just
prehashing (e.g., tree hashing or splitting the data). The
prehashing also makes the functions greatly more vulnerable to
weaknesses in hash functions used. These variants SHOULD NOT be
used.
To be perfectly honest, I think it's a bit strange that the RFC defines these variants but then immediately says they shouldn't be used. But, I would still tend to follow its advice and not include variants that are not recommended to be used.
Applications that need single-pass signing could still prehash the data themselves (though of course they would need to make sure that the same key is never used for signing data directly), or do as the RFC suggests and add tree-hashing or split the data and sign each chunk.
Unless there are strong objections and signals of interest to implement, I'll close this issue. (Though even if those arise later Ed25519ph and Ed448ph can always still be added to Web Crypto as separate algorithms, no special consideration for that is necessary now.)