[Bug 25839] Curve25519 Named Curve

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839

--- Comment #50 from Trevor Perrin <webcrypto@trevp.net> ---
(In reply to Ryan Sleevi from comment #49)
> (In reply to Trevor Perrin from comment #48)
> > Don't care!
> > 
> > The several Javascript crypto projects I'm advising don't use PKIX, S/MIME,
> > JOSE, or PKCS#8.  If Curve25519 needs number registration for those, then
> > that seems like an issue for those protocols, not a concern for a low-level
> > crypto library.
> 
> No, it's a concern for our library too, with regards to importKey,
> exportKey, and wrap/unwrap.
> 
> Even if you decide to hand-wave these formats to the ground (which doesn't
> seem entirely appropriate, since there is active work going on precisely to
> standardize these), you still have to define what "raw" means, in the
> specific context of WebCrypto, and ideally in a way that will interoperate
> with other, non-WebCrypto things.

The "raw" definitions would be straightforward, as the Curve25519 and Ed25519
papers specify exact encodings for keys and signatures.


> Of the multiple Curve25519 implementations, very few that I'm aware of try
> to actually interoperate with eachother, or with any other protocol.

I've talked to some developers of these libraries who indeed have performed
interop tests.  The DJB specs are very clear, and the formats are very simple. 
I'd be surprised if any serious implementations of Curve25519 ECDH and Ed25519
signatures failed to interoperate.


> Even
> the native language bindings for things like NaCl attempt to just use the
> djb-reference implementation, and just wrap that. So it is a bit
> questionable on the 'interoperability', but it at a minimum requires a
> formal definition for what format(s) are supported for these operations.

It's true that most people use one of the high-quality open-source
implementations that Dan Bernstein or Adam Langley have produced, or
implementations derived from these (by Frank Denis, Robert Ransom, floodyberry,
CodesInChaos, etc).

That speaks to the quality of these implementations, it doesn't imply interop
problems.


> For what it's worth, people do care about JWK, and they do care about SPKI.

Some people do, some people don't.

Personally I'm more interested in TextSecure, Tor, PGP, SSH, OTR and variants,
CryptoCat/miniLock, and others.  I don't think WebCrypto should refuse
algorithms of interest to large communities just because they aren't used
within PKIX or JOSE.


> > Are you saying WebCrypto can't support new algorithms unless they're
> > registered with a half-dozen IETF protocols most people don't care about?
> 
> I didn't say anything close to that.
> 
> I just mentioned that these are exposed API surfaces of WebCrypto, and, as
> of yet, no one has proposed on how to deal with them. Your proposal is
> "Don't deal with them", which is a proposal, and one which should be
> discussed on it's merits, preferably when reviewing such text.

My proposal would be to define the "raw" formats for import/export now, and add
other formats ("jwk", "pkcs8", "spki") if/when they become available.


> > I guess I expected a low-level API to just provide Curve25519 keys with
> > ECDH, and Ed25519 keys with sign/verify (since by convention and for
> > performance/security reasons, Curve25519 is mostly used with different
> > encodings for public/private keys in signatures vs ECDH, and Schnorr
> > signatures are used rather than ECDSA).
> 
> Yes, I can reasonably imagine that, but imagination and specification are
> two different things.
> 
> The fact that Curve25519 does not work with ECDSA, or that the Schnorr
> signatures are used, are exactly the kind of things that need specification
> in order for interoperability (and without just aping the djb@ code, even if
> it is extremely high quality and correct and reasonably licensed for most
> needs)

Curve25519 public keys can be encoded in Edwards form (Ed25519), and in that
form could be used with ECDSA.  However people using 25519 would expect Schnorr
signatures.

"Aping" code for these isn't needed.  Like Curve25519 ECDH, the Ed25519
signature format is well-specified in a published paper:

http://ed25519.cr.yp.to/ed25519-20110926.pdf


> > I could imagine these creating some issues for your API, and those seem like
> > good things to discuss further.  But having to specify PKIX or JWK bindings
> > seems unnecessary and a layering violation.
> 
> I imagine that you missed importKey, exportKey, wrap and unwrap during
> review.

I see them, I just think it's strange for this API to be concerned with
outputting keys in various application formats.

Adding or parsing JSON/XML/ASN.1/etc boilerplate can be done in Javascript
without special performance or security considerations.  It doesn't seem that
important to perform this in the browser.

It's also weird to favor such specific protocols, to the point that not being
used in them is an argument against adopting crypto that's widely used
elsewhere.


> > So what's the way forward?  Should this discussion switch to Bug 25618?  Is
> > anyone working on a more streamlined way to add new algorithms?
> > 
> > Trevor
> 
> Concrete steps:
> - Make an effort to write an independent specification for Curve25519

OK.  

So if I specified "Curve25519" and "Ed25519" algorithms that only define
import/export using the "raw" formats and the DJB-defined standard encodings,
this would be considered?

Is there an example template for producing add-on algorithm documents?  Are any
spec editors or other people willing to help, as I'm new here?


Trevor

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 25 July 2014 07:49:56 UTC