Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Peer-review required: SwaTwt and TweedleDH

David Dahl david at ddahl.com
Wed Sep 29 14:41:21 PDT 2010


On Wed, Sep 29, 2010 at 12:04 PM, Daniel Colascione
<dan.colascione at gmail.com> wrote:

>> One of the future areas of work was to build crypto support into a
>> browser plug-in or extension. There is work being done on client-side
>> crypto for HTML5, similar to client-side storage, that is promising.
>> Support would be built into compatible browsers and accessible via
>> calls in Javascript.
>
> As you mentioned a few days ago, Javascript-callable cryptography
> primitives can only be performance optimizations: they cannot change the
> fundamental trust model between a client and server. As such, they just
> encourage what we know to be a bad idea. If a client can trust a server,
> a client can trust a server to do the cryptographic work server-side.
> Conversely, if the work can't be safely done server-side (as in the
> PseudoID blinding case[1]), then the client needs dedicated support. I
> hope these Javascript primitives never become widely supported.

All of the crypto you would need for a project like this (in native
C++, wrapped by JS) is available in Firefox 4.0 pre-releases. The
Firefox Sync tools do full PKI via NSS, wrapped in JS via jsctypes.

see: http://mxr.mozilla.org/mozilla-central/source/services/crypto/IWeaveCrypto.idl

In an extension I have wrapped these methods and exposed them to
content scripts giving me fast PKI. There is still some level of trust
involved with the server, but the cryptographic methods do not
originate in the server-delivered JS, rather inside Firefox itself.
This gives you the best of both worlds, a web app for ease of
development and fast, standard crypto. Of course, all of this work is
open source and available under a tri-license from the get-go.

One of the eventual goals here is to begin some DOM API
experimentation that makes these methods part of the DOM itself in all
browsers. I would say that this kind of experimentation is probably
the most important work that developers work on.

Regards,

David



More information about the liberationtech mailing list