[Bug 25839] Curve25519 Named Curve

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

--- Comment #20 from Ryan Sleevi <sleevi@google.com> ---
(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.

As noted, the cryptographic libraries of two major implementors are presently
tied to major OS releases. The two cryptographic libraries in use by the other
implementors (NSS and OpenSSL) equally lack implementations of Curve25519.

There is no specification of Curve25519. The IETF has made talks of it, but has
yet to actually make headway. It is simply "The code speaks for itself". 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.

It's popularity, unquestionable as it is - even within the organizations of at
least two UAs - is not something at any level of maturity that the document can
even place a normative reference on.

I disagree on the assertion that the x86_64 impl can be seen as interoperable
with the armv7 impl on two grounds. The first is that the common implementation
is not hand-rolled assembly but the common dbj C code. 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.

I don't oppose Curve25519 on crypto reasons; it's unquestionably desirable. But
if we're going to talk about interoperability and well-defined algorithms, at
present, this is lacking.

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

Received on Wednesday, 11 June 2014 09:16:14 UTC