[Bug 25839] Curve25519 Named Curve

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

--- Comment #32 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(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".

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

Received on Friday, 13 June 2014 12:52:22 UTC