On Tue, May 21, 2024 at 08:04:44PM +0100, Neil Madden wrote: > On 7 May 2024, at 10:29, Ilari Liusvaara <[email protected]> wrote: > > > > On Mon, May 06, 2024 at 02:40:32PM +0100, Neil Madden wrote: > > > > > > For EdDSA, there is huge difference between Ed25519 and Ed448, so those > > are definitely different crpytographic operations. > > Is there a huge difference? RFC 8032 (which I’m sure you’re familiar > with!) says that it is a single algorithm (EdDSA), instantiated with > two different curves.
The internal hash function is different (SHAKE versus SHA-2), and the input to hash function is different (beyond just field lengths changing). And I think that original EdDSA had some technical stuff that made p=4k+3-type curves like Edwards448 not work with it. Then there was EdDSA2, which generalized the construction allowing p=4k+3-type curves. The "EdDSA" from RFC8032 is neither of those, it is something far more loose. > What about applications that only accept canonical signatures for > EdDSA (eg for consensus)? Is that a change in the cryptographic > operation or not? (It is if you consider multiplying out the cofactor > or not). So that choice should be reflected in any fully-specified > algorithm. The signatures produced by standard Ed25519/Ed448 signing should pass any reasonable verification variant. This goes up to verification that enforces that R and A are canonically encoded, high-order and in main subgroup. The main subgroup check is fairly expensive, the canonical encoding (which RFC8032 specifies) and high-order checks are very cheap (there is a trick to do the high-order check very fast[1]). This is not like canonical ECDSA, where standard signatures may need sign-flipping to be acceptable. > > For ECDSA, one could argue if curve factors into cryptographic operation > > performed or not. However, for each curve, there is single preferred > > hash function, and anything else gives interoperability problems. > > E.g., P-256 should always go with SHA256. So those should still be > > treated together. > > Indeed, curve doesn’t really factor into the cryptographic operation > performed, so this undermines the idea that it is about fully-specifying > the cryptographic algorithm. I’m not really sure the situation is very > different between ECDSA and EdDSA on this respect. Since this whole thing is about interop, I gave weight to arguments from interop. > And if we’re going to fully-specify the hash function, then that > suggests that for encryption algorithms that “enc” should be smushed > into the algorithm identifier. Otherwise, why are we saying one use > of symmetric cryptography is somehow essential to the algorithm and > the other isn’t? Both can be varied independently. The "enc" is different layer from "alg" values (also holds for COSE, where "enc" maps to layer 0 "alg"). And the draft explicitly says that "enc" and "alg" are independent. Given that JOSE is designed for interop, this is actually critical. > I look forward to us correcting the same mistake currently being made > in JOSE in a few years time. Or we could just update the draft to > match what seems to be the reality: nobody actually wants encryption > algorithms to be fully specified, because it would lead to an > explosion of new identifiers. All people really want to do is to add > a couple of new signature identifier values to hack around a mis- > design of various protocols. As note, COSE-HPKE/JOSE-HPKE has explicit KEM instead of implicit KEM because even if it is currently always possible to guess the correct KEM, this might not hold in the future. E.g., Imagine adding SHA-3 variant of X25519, no way to guess that. [1] For Edwards25519, check that X^2, Y^2 and X^2+Y^2 are all nonzero. For Edwards448, check that X^2 and Y^2 are both nonzero. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
