Be careful not to confuse Ed25519 with Curve25519. The former uses Edwards coordinates in which case (x,y) coordinates are appropriate. The latter uses Montgomery coordinates, which only require an x coordinate for the special case of an implementation of the Diffie-Hellman key exchange.
In fact all coordinate systems can use a "compressed" form of just x and at most 1 bit to indicate the sign of y (recall that x and y are related via the curve equation). However compression (or some forms of it) was patented, and hence avoided. However I believe that patent has now lapsed (?) As I recall IEEE1363 supports a compressed representation of points. Also "decompression" has a cost associated with it, although this doesn't arise for Curve25519 where it is never required to recover the y coordinate Mike Scott ________________________________________ From: jose <[email protected]> on behalf of Daniel Holth <[email protected]> Sent: 14 August 2014 03:20 To: Mike Jones Cc: Trevor Perrin; [email protected] Subject: Re: [jose] JWK Elliptic Curve key representations and new curves On Wed, Aug 13, 2014 at 9:39 PM, Mike Jones <[email protected]> wrote: > It has come up in recent discussions in the CRFG, the W3C WebCrypto working > group, and the TLS working group that not all elliptic curves or curve > protocols use two coordinates (x and y) in their public key representations. > For instance, a Curve25519 public key is a single 32-byte value. Especially > in light of the request by TLS to the CRFG to recommend new curves, and that > some of the curves in consideration use only a single value in their public > key representation, I believe that JOSE should consider how to represent > such keys as JWKs. > > > > I see there being two logical ways to address this: > > > > CHOICE 1 – MAKE THE “EC” KEY TYPE MORE FLEXIBLE: One obvious possibility is > to make it a property of the “crv” parameter for JWKs with “kty”: “EC” what > fields are required. So for instance, when “crv” is “P-256”, “P-384”, or > “P-521”, both “x” and “y” members would be used, but other curves might use > a different set of members, such as just “x” for public keys. > > > > CHOICE 2 – USE A DIFFERENT KEY TYPE: Another possibility is to leave the > “kty”: “EC” definition as it is but to define a related “kty”: “EC1” value > to be used by elliptic curves for which only one value “x” is used in the > public key representation and an additional value “d” is used in the private > key representation. > > > > Within choice 2, there are actually two sub-choices available to us: > > > > CHOICE 2A – DEFINE A NEW KEY TYPE VALUE IN JWA NOW: If we think that there > are only two kinds of elliptic curve key representations that we will ever > care about, we could define the second one in JWA now. However, this would > almost certainly start a debate within JOSE about whether we should add any > additional curve definitions using this new key type. If we do, it should > almost certainly be because we have followed the CFRG’s and TLS’s lead in > the new curve choices, although doing so would almost certainly further > delay our completion. > > CHOICE 2B – DEFINE THE NEW KEY TYPE IN A NEW SPEC: This could be done by > writing an individual draft that registers “kty”: “EC1” and later possibly > adopting it as a working group item. This would allow our current specs to > proceed as-is, while giving us time to sync with CFRG and TLS as their curve > choices move forwards. > > > > One additional pesky detail worth noting is that the normal Curve25519 key > representation uses little-endian 32-bit numbers whereas SEC1 (which we use > for “x”, “y”, and “d”) uses big-endian numbers. So for any of these choices > above, we’d also have to decide whether to allow different curves to specify > different endianness, require all to use big-endian representations, or to > say that for some curves, the value is an octet array of a given size and be > silent on endianness. > > > > While I’m reluctant to even bring this up at this point in the development > of our specs, I also don’t want those designing potential applications of > JWKs to believe that their choices of curves are limited by decisions that > JOSE has made. It’s clear that JWK can be extended to accommodate curves > using only a single value in their public key representations. > > > > How do you think we should do that? > > > > -- Mike > > > > P.S. Thanks to Trevor Perrin for private discussions that informed some of > the contents of this note. I didn't find the existing spec a burden. My JWK-derived system uses { "kty" : "Ed25519", vk : "the base64url-encoded verifying key" } and uses "Ed25519" as alg as well. (In the less necessary JWK private key representation "sk" : "..." is used for the secret part). Is there some economy that makes it desirable to have a Ed25519 JWK look similar to any other elliptic curve key that only uses one (opaque?) parameter? The constant-time implementation (no secret branching) is monolithic, specialized to that curve and is not built out of reconfigurable pieces. Curve1174 "Elligator" is another elliptic curve system by DJB etc. that looks like it shares some of the attributes of Ed25519. Daniel Holth _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
