MozCamp Asia Report

2011/11/28 — 1 Comment

I recently attended MozCamp Asia in Kuala Lumpur, Malaysia. It was a pretty fun and amazing experience. Meeting Mozilla contributors from all over Asia was of course, the highlight of the trip.

I did a talk at the conference called “From Web Developer to Firefox Hacker“.  There were a number of web developers at the conference and I wanted to convey to them that their skills are relevant to hacking on Firefox itself. Lowering the bar to hacking on Firefox is hard to do – and technical, patch-creating contributors are very important to the project. Someone who comes into the community as a newbie from a talk or workshop like this, this year, may become a rockstar next year, you never know.

The questions I kept asking myself in putting together this presentation were “How to start?”,  “Am I covering X or Y in sufficient detail?”,  “Am I scaring potential contributors with too much detail about the Mozilla process?”, and “Did I forget anything important?” There is just so much detail to cover.

A realization dawned on me while putting together these slides: our documentation is very well done at this point. I was impressed with a lot of new MDN content I linked to that did not exist when I started 3 years ago. Slowly we are chipping away at making technical contribution easier. Perhaps what we need are a few more “starting point” type documents, presentations and workshops to kick off a slew of new patches, no matter how small.

The talk went well.  A few new folks pinged me on irc in the days after, and I was invited to Taipei to give the talk as an in-depth workshop. A Chinese translation was also discussed.

Now is as good a time as ever for technical contributors to learn our process and contribute to Firefox. It may not be easy, but it is easier than ever:)

A Working Group

2011/11/04 — 2 Comments

This week I attended the W3C annual meeting known as “TPAC” in Santa Clara. I went to discuss the possible formation of a “Web Identity Working Group” to begin the process of possibly standardizing Identity APIs and protocols, of which DOMCrypt was acting as a straw man proposal for a DOM/JS Crypto API.

The short story is that “Web Identity” APIs and protocols are still very much in an R&D phase and while incredibly important, there was not much agreement between interested parties on what to begin working on.

A high-level, hard-to-muck-up, asynchronous crypto API, on the other hand, had massive support from almost all of the interested parties involved. In the end, a “Web Cryptography Working Group” is being established, and I have thrown my hat into the ring as an “editor candidate”.

One of the first tasks is to clearly define what is “in scope”, “out of scope” and what features can be considered part of a potential “road map”. The starting point for this API will have to be a bit narrow, with no UI-based features so we can establish core functionality without too much complexity.

The current charter is here: http://www.w3.org/wiki/IdentityCharter#Web_Cryptography_Working_Group_Charter (I have a feeling this url will change soon)

This is pretty exciting stuff. I met with a whole lot of folks from Microsoft, Google, Apple, Netflix and other companies that have many potential use cases. We need to collect as many use cases as possible in order to understand the most common uses so the first iteration will provide the best capabilities. If you have a use case in mind, do not hesitate to send it to me (ddahl + at + mozilla dot com) or the w3 mailing list, public-webcrypto@w3.org (which is yet to be set up).

After reading this thought-provoking post: http://www.matasano.com/articles/javascript-cryptography/ I thought I would enumerate some of the concerns raised and try to explain how DOMCrypt handles at least some of problems that are inherent in JavaScript cryptography.

  • DOMCrypt is not a low-level crypto API. DOMCrypt is very high-level, making it much harder to ‘do it wrong’. The only configuration is telling DOMCrypt what algorithm to use. See: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
  • Private key material is never exposed to content JS. Each keypair is represented by an ID. This keeps the key material in a secure key store outside of content. (In the case of Firefox, the key material will be stored in NSS’ key database)
  • Each domain/origin will have its own keypair. You will have to know the ‘KeyID’ to use the domain’s keypair to encrypt data. Being able to handle secret key material in content is ‘doing it wrong’. The original DOMCrypt prototype code as well as all of the crypto libraries do this. Not good.
  • All algorithms are well designed, well tested and maintained crypto functions created by tried and true cryptographers (In the case of Firefox’s implementation we have NSS under the covers). Millions of users have depended on this underlying crypto for a decade plus. Part of the motivation for DOMCrypt is that each site might roll their own crypto implementation, or use an implementation that is out in the wild, which are likely to be subtly wrong.  By providing DOMCrypt, we can leverage all the careful scrutiny that has already gone into browser crypto implementations. We are not re-building the wheel. (Random numbers are truly random as we are calling into NSS or other system crypto depending on the browser implementation)
  • Fast. This is not a concern in the Matasano article, but I think it is a valid point. DOMCrypt calls crypto functions written in C, so all of the crypto operations are quite fast.

There are, of course, still many concerns even with a built in crypto API, but I think it is a step in the right direction. Moving all of the heavy crypto operations into the browser itself and exposing only a high-level API to consumers is the beginning. Making encryption as trustworthy as possible in a malleable content JavaScript environment will take some additional work.

 

*thanks to Adam Barth for input

Apparently, I have been summoned by the “7 things” internet meme… This is where you divulge 7 things that people may not know about you and tag 7 more people. I am wondering how I get paid for this. It is a ponzi scheme, right?

The details of my life are quite inconsequential.

1. My father was a relentlessly self-improving boulangerie owner from Belgium with low grade narcolepsy and a penchant for buggery. My father would womanize, he would drink, he would make outrageous claims like he invented the question mark. Some times he would accuse chestnuts of being lazy, the sort of general malaise that only the genius possess and the insane lament.

2. My mother was a fifteen year old French prostitute named Chloe with webbed feet.

3. My childhood was typical, summers in Rangoon, luge lessons. In the spring we’d make meat helmets. When I was insolent I was placed in a burlap bag and beaten with reeds, pretty standard really.

4. At the age of 12 I received my first scribe. At the age of fourteen, a Zoroastrian named Vilma ritualistically shaved my testicles. There really is nothing like a shorn scrotum, it’s breathtaking, I suggest you try it.

Uh, just kidding… Of Course, the previous points are a joke.

Here we go:

When I was five, my family moved to Germany so my dad could help with the post World War II occupation, you know. This was in 1977. (Wow, I am  old.) We lived in Augsburg for 3 years. I was quite aware of the Cold War at the age of 5.

I enrolled in my Junior year of college and never paid the tuition and never showed up to class, instead, I played guitar in a band that was nearly signed to a major record label. of course, these things just never turn out the way you want them to. My band played some pretty big shows opening for Blur once, and other indie bands such as Medicine, The Leaving Trains and Catherine. We recorded at the same studio as Smashing Pumpkins and occasionally hung out with some of them. Ahhh, hanging with Rock Stars at 20 years old… those Were the Days.

I saw the Orb in 1993 and renounced rock music for techno, starting a fledgling techno music group in Chicago. I DJ’d at some pretty huge Raves back in the day. Some of my music is on SoundCloud.

Back in 1995, Netscape went public, I finally set up a PPP account at Suba.net in Chicago. My boss at the time told me the “internet is a fad, the future is in the CD-ROM”. I quit my job and went to work at Northwestern University where they have had an internet connection since 1981. I taught myself HTML. I was into the web.

My wife and I eloped to Italy for a wedding in Florence. We spent a month in Italy, Croatia and Germany and probably spent as much money as the average bride spends on a dress. I HIGHLY recommend it.

I worked at Industrial Light and Magic for 18 months and that is all I can tell you about it, except that it felt more like working at IBM than a tech company on Tatooine (it WAS also a lot of fun).

My wife and I have 2 children, Cecilia – 5 and Henry – 1. Last year we moved back to the Chicago area, bought a place in the woods and are adjusting well to country living.

That about sums it up. I am supposed to tag 7 people now: @shorlander, @dao (is he on twitter?), @limi, @faaborg, @pastith, @ratcliffe_mike and @neonux

I have uploaded the latest DOMCrypt addon, which is version 0.4. It is not reviewed by the Addons team yet.
https://addons.mozilla.org/en-US/firefox/addon/domcrypt/versions/?page=1#version-0.4
I have updated it here as well:
http://mozilla.ddahl.com/domcrypt/extension/built/domcrypt.xpi

(note: The DOMCrypt extension, which is the bleeding edge code still uses ‘window.mozCipher’ as the window property name. The Firefox patch uses ‘window.mozCrypto’, the plan is to eventually merge this API into window.crypto )

I tried to make this API as simple as possible:

Encryption:

window.mozCipher.sym.encrypt(plainText, function callback(aCryptoObject){})

The resulting ‘CryptoObject’ has the following properties:

{
  cipherText: "...ENCRYPTED TEXT...",
  wrappedKey: "...A WRAPPED SYMMETRIC KEY...",
  iv:         "...KEY INITIALIZATION VECTOR...",
  pubKey:     "...A PUBLIC KEY..." // By default this pubKey
                                   // is the current user's public key,
                                   // which is used to wrap the symmetric key
                                   // so the actual key is never exposed to content.
}

Decryption:

window.mozCipher.sym.decrypt(aCryptoObject);

You can also pass in a public key to each method to wrap the key with another user’s key

Internally, a symmetric key is generated each time you run encrypt, it is wrapped with a public key to keep it safe and that cryptoObject is returned.

This is a first pass on an implementation – I tried to make it as simple as possible, with key safety the top priority.

A common use case for this API is localStorage encryption:

// web-based password manager app:)

var myWebPasswords = {gmail: "password", facebook: "password", twitter: "password"};

var jsonPasswords = JSON.stringify(myWebPasswords);

window.mozCipher.sym.encrypt(jsonPasswords, function callback(aCryptoObject){
  var jsonCryptPasswords = JSON.stringify(aCryptoObject);
  localStorage.setItem("jsonCryptPasswords", );
  delete myWebPasswords
});

// decrypt

var myWebPasswords;

var cryptoObj = JSON.parse(localStorage.getItem("jsonCryptPasswords"));

window.mozCipher.sym.decrypt(cryptoObj, function callback (aPlainText){
  myWebPasswords = JSON.parse(aPlainText);
});

This API is simple to use, and gives you a more secure way of using localStorage – or IndexDB, etc.

A really handy summary of the recent W3C Identity Conference held in Mountain View has been posted: Identity in the Browser Workshop Final Report (Draft)

The need for  “Identity” crypto APIs never made it into the DOMCrypt use cases page, until today. The point here is that I have maybe 2 uses cases for DOMCrypt that are important to me: easy symmetric and public key encryption of arbitrary data and the more secure, private messaging that will be made possible because of this. Others may have entirely different ideas that are just as valid. All of these ideas should be collected now as we are still in the design phase.

Of course, for me, the “Apps” are where its at. I am so much more excited about writing messaging apps using DOMCrypt than implementing DOMCrypt itself. Naturally, the API has to come first, work well and be accepted by browsers before the Apps can have a real impact.

A few developers have contacted me about how DOMCrypt works and are actively writing either extensions or web apps using DOMCrypt. This is super exciting.

If you also have an idea or are wondering how to get started playing with this API, please do not hesitate to contact me.I plan on blogging about the example code I have provided in the DOMCrypt content tests.

mozilla IRC: ddahl, twitter: @deezthugs, email: ddahl at mozilla dot com

If you think of additional use cases, I would like to hear them as well, or if you have a mozilla wiki account, please feel free to add them.

 

DOMCrypt round up

2011/06/13 — 3 Comments

While I work on the spec for DOMCrypt, I want to make sure to keep the latest information about the status of this API fresh.

For the uninitiated, DOMCrypt is a browser window API I have been working on that makes using public key and symmetric crypto as well as hashing easy and fast for web developers.  The current implementation is a Firefox add-on as well as a patch for Firefox.

First and foremost, a WebKit bug was filed to implement the DOMCrypt API! This is great news. Both Adam Barth and Jarred Nichols have jumped in to write the code.

Secondly, I have created a proper WebIDL document to describe the API: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest#Browser_Window_property_WebIDL

The mailing list archives for the 3 lists I requested feedback and criticism from are here:

The consensus seems to be that this is a good idea – and a good place to start for a *high-level* browser-based crypto API. Some of the changes that should be made are:

  • Fold this API into the existing window.crypto property to avoid confusion
  • Removed the ‘addressbook’ sub-API as it adds too much undefined complexity (for now, anyway – I hope to revisit this concept in a separate spec)
  • Add an algorithm property to each sub-API to allow for forward migration to better, faster crypto
  • Add an HMAC sub-API to round out the API

All of this has been reflected in the spec.

I have attempted to aggregate most of the discussion into this etherpad (may need some updating): http://etherpad.mozilla.com:9000/DOMCrypt-discussion

As far as the Gecko implementation is concerned, Brian Smith has been giving me a lot of pointers on what will be a better implementation, starting with a new set of APIs to more easily handle the interfacing with NSS, see bug 662674

I would love to collect more feedback on this API, please do not hesitate to join in on the discussion.

It seems like the time is right for this to gain steam as we see the effect of not having these  tools  – in what seems like daily personal data breaches on the web. I think an API like DOMCrypt will help spur new communications tools that have security, privacy and user control built in from the ground up.