[Bug 25839] Curve25519 Named Curve

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

--- Comment #33 from Harry Halpin <hhalpin@w3.org> ---
(In reply to Henri Sivonen from comment #32)
> (In reply to Ryan Sleevi from comment #20)
> > (In reply to Henri Sivonen from comment #15)
> > > When different CPU architectures have distinct implementations, you could
> > > count x86_64 impl. by person A and armv7 impl. by person B as distinct
> > > implementations.
> > 
> > There are zero *implementations*, let alone interoperable, in the
> > cryptographic libraries used of *any* user agent implementing WebCrypto at
> > present. All of the implementations have, at present, deferred crypto to the
> > appropriate library.
> 
> The Process point I wanted to make is that in the case of per-ISA-optimized
> algorithms *one* library can *potentially* contain *two* independent
> interoperable implementations of a crypto algorithm.
> 
> Thus, moving from zero to two for Process purposes *might* be easier than it
> first seems.
> 
> > There is no specification of Curve25519.
> 
> Interesting. I thought the definitions in
> http://cr.yp.to/ecdh/curve25519-20060209.pdf and
> http://cr.yp.to/highspeed/naclcrypto-20090310.pdf were specific enough to
> serve as the specification basis for indepentent interoperable
> implementations, but I'm not really competent to assess if they are indeed
> specific enough.
> 
> > While there are many implementations of Curve25519, for different platforms,
> > they are all based on the same djb initial code and still re-use aspects of
> > it.
> 
> The situation with djb crypto that the best implementations for a given CPU
> tend to be in the Public Domain seems to mean that it doesn't make sense for
> anyone to ship something other than the best known implementation for a
> given CPU. If these all are derivatives of djb's code, they aren't
> independent.
> 
> I think in that case, if you can show that the specification is specific
> enough that independent implementations *can* be made, even if no one wants
> to ship those in real products at present, I think that should be enough to
> satisfy the purpose of the Process requirement, which is to demonstrate that
> the spec is specific enough.
> 
> http://nacl.cr.yp.to/valid.html claims that the latter of the two papers
> mentioned above contains independent implementations of the algorithms in
> NaCl (therefore, including Curve25519). The paper indeed contains Python
> code designated as an implementation by Matthew Dempsky. Is there a reason
> to believe that this implementation isn't independent enough to demonstrate
> independent implementability?
> 
> For an analogy, consider if all the major browsers implemented PNG using
> libpng. (I'm not sure if that's actually the case, but it easily could be.)
> Should PNG then not have been able to exit CR if independent
> implementability were demonstrated using a non-browser implementation? In
> many cases, using non-browser implementations to satisfy CR exit criteria is
> harmful, because non-browser implementations don't demonstrate whether the
> spec requires Web-incompatible behaviors. However, with crypto algorithms
> and bitmap image formats, the boundary of the units being tested is
> well-defined enough that it seems that using a non-browser implementation to
> demonstrate independent implementability is not a problem when the algorithm
> is new to the Web Platform.
> 
> > The second is that we've already seen past APIs that use a common
> > code/library (eg: WebSQL -> SQLite), lacking definition or truly ground-up
> > implementations, be rejected.
> 
> Indeed. However, "all the exact behaviors of a particular version of SQLite
> that Apple used" is *way* vaguer a set of behaviors than the behavior of a
> cryptographic primitive. Therefore, it seems that there is significantly
> less risk in determining that a cryptographic primitives is independently
> interoperable implementable even if all the implementations anyone would
> ship are dependent than determining that SQLite is. Also, even if it's the
> case the the above-mentioned papers don't describe Curve25519 well enough to
> constitute a "spec" (as noted, I'm not competent to evaluate whether this is
> the case), Curve25519 still seems way better defined than "all the exact
> behaviors of a particular version of SQLite that Apple used".

Henri - this is a very interesting point as regards interoperability. I've
emailed W3T. We'll have an answer back shortly. 

That being said, we need to figure out the before we go to CR how to address
the problem of curve25519. Does Mozilla plan to support it?

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

Received on Thursday, 19 June 2014 15:03:49 UTC