W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > October 2012

One devo's perspective on JS-based crypto

From: Jim Burrows <brons@eldacur.com>
Date: Wed, 10 Oct 2012 12:34:44 -0400
Message-ID: <CAOPLg6o0cpO46_A0Q1tkDY_Q7eQYbgedbt+3fG9Fc_T2r-vFzw@mail.gmail.com>
To: public-webcrypto-comments@w3.org
Since the question of what developers are looking for, and how developers
use Javascript-based crypto has been discussed of late, I thought I might
give a quick precis of my experience and interests in the area. In the
process, I've been learning a lot about how the public-webcrypto list and
archive work. I hope I have not looked to much the fool for those who may
have been CC'd on my earlier attempts while learning the ins and outs.

I have done contracting work in the last several months with two client
companies who were building multi-platform suites of secure communications
apps covering voice, text, data, email, alerting and video. My work has
included JavaScript based development using SJCL. My clients have used
Javascript-based code that I have developed for a few of purposes and have
indicated an interest in using it for a number of others. The uses have

   *  Jacketing captive JavaScript code in native-code apps to allow quick
      deployment of a client on a platform that does not yet have an app
      of its own.
   *  Having an independently developed implementation of a communications
      client that is used for in-house testing of commercial products,
      allowing for the exercise of bugs and corner-cases not thought of
      by the creator of the original implementation.
   *  Building of quick prototypes.
   *  Development of a marginally-secure "beachhead" presence on a device
      whereby a secure native-code app can be delivered to a newly
      acquired device, and relying on out-of-band confirmation of
      probable identity.
   *  File transfer using convergent encryption techniques.
   *  Other more blue-sky applications.

It is quite true that a secure pipe to an endpoint in an
unverifiably-secure environment such as a web browser used for other
purposes is of limited use due to the level of risk implicit in exposed
nature of the endpoint, but there are often real world cases were there is
significant operational value in having a secure pipe with one known secure
end point, especially when you are in control of the risky end of the
pipe.This can happen in both the "beachhead" and controled-test
environments, and is arguably a valid choice in terms of fast deployment to
new or additional platforms if a sufficiently secure jacketing app can be
quickly developed.

Received on Wednesday, 10 October 2012 17:32:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:48 UTC