- From: <bugzilla@jessica.w3.org>
- Date: Wed, 11 Jun 2014 09:16:12 +0000
- To: public-webcrypto@w3.org
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