Oct 11

Cryptographic Invitation Protocols

For a while now, I’ve been noodling around with a cryptographically-secure "invitation protocol" of sorts. I want something that can start with Alice sending an Invitation Message to Bob, and end with fully secure bidirectional communication.

The use cases I have so far are:

  • secure file-transfer tools, as a browser plugin or standalone application. The program would have an address-book, each entry would have an "Inbox" for that person, you would send them a file by drag-and-dropping it onto the Inbox. This invitation protocol would be used to populate the address book.
  • secure communication tools, like Petmail or an encrypted email/IM client, in which you want to add address-book entries so you can later exchange messages with the right correspondent.
  • Tahoe grid membership tools: you would use an Invitation to securely add another person’s client/server node to your grid, maintaining enough information to perform Accounting and server-selection properly.

but there are lots of others. Most applications with any sort of social component need a way to add "buddies" or correspondents. There are plenty of centralized systems (like IM networks, where the namespace is controlled by a single company), and a handful of insecure decentralized systems (like email addresses). I want this protocol for secure decentralized systems, in which the primary identifier for each participant is a public key of some sort.

Read on if you’re interested in cryptographic protocols..

Continue reading →

Aug 11


Hi! My name is Brian Warner. Welcome to my blog!

I’ve been working at Mozilla for about a year and a half. Before Mozilla I was at a startup (now gone) named AllMyData.com, which ran an online backup service aimed at home users and small businesses. For the backend, we developed an open-source encrypted distributed filesystem named Tahoe-LAFS (still thriving), with the relatively-unique feature of “provider-independent security”: the servers hold ciphertext, and only your client (and anyone you choose to share them with) holds the decryption key. By relying upon the servers for availability but not security, you can use servers that you wouldn’t trust otherwise. The system is designed with “POLA” in mind, the Principle Of Least Authority, which improves safety by giving each component as little power as possible; just enough to do its one job.

Mozilla’s Sync system, which helps keep your bookmarks and other browser data synchronized between multiple browsers, uses the same principle. The data is encrypted before it leaves your computer, and our servers don’t get to see the key. The similarity in philosophy between Sync and Tahoe was a big part of the reason I joined Mozilla: I had found a bunch of like-minded people with whom I could promote these ideas, with a wider audience (400 million users and counting!) than anything our tiny startup could reach. Shortly after joining, I helped build the credential-exchange protocol that Sync uses to add a new computer to your account (the “copy this code” J-PAKE-based dialog panel).

But most of what I’ve been doing for the last 18 months is Jetpack, now better known as the Add-On SDK. It’s a new way to tackle the admittedly painful process of writing add-ons for Firefox (and eventually other XUL-based programs, like Thunderbird).

Add-ons in Firefox have always been a bit.. organic. There’s an awful lot of internal interfaces, and add-ons authors have had to dig through a lot of that to find a useful point to attach or override some code. It’s messy, and fragile: it’s difficult for the Firefox developers to keep those internals stable while making large-scale improvements to the browser, so add-on authors are fighting an uphill battle to maintain compatibility with newer releases. With our new faster release cadence (every couple months!), the problem becomes even more challenging.

Jetpack was intended to make the simple things simple. It has a library of interface modules for doing common add-on tasks, like creating a UI, and modifying web pages. We, the SDK authors, will keep updating these modules to match the Firefox internals, so add-on authors won’t have to. One of the promises of Jetpack is that the high-level add-on code doesn’t need to change much at all to keep up with newer browsers.

The SDK has two parts: this library of modules, and a program that assembles your code with the right set of modules and produces the XPI file, ready for installation or upload to AMO. If you think about it in terms of gcc and other compilers, this program is a linker: it figures out which modules are required and combines them into an executable bundle.

The linker is written in Python, and since that’s been my dominant language for the last ten years, most of my Jetpack work has been on the linker side. I’ve also been heavily involved in developing the security model, to make Jetpack-based addons safer in the face of bugs and compromises. I’ll be explaining a lot more about the security model in this blog over the coming months.

And no description of Jetpack is complete without also mentioning Flightdeck, better known as the Add-On Builder. This is an online IDE for writing add-ons. On the backend, it runs a copy of the SDK to generate the XPIs. It allows folks to get into the add-on writing business without downloading or installing an SDK: just start writing the code! A big goal of Jetpack is to make add-on writing accessible to a wider developer community, leveraging Javascript skills that web-devs already have, and an online tool like Builder removes a lot of the unnecessary hurdles for that audience.