Encryptr is one of the first “in production” applications built on top of Crypton. Encryptr can store short pieces of text like passwords, credit card numbers and other random pieces of information privately, in the cloud. Since it uses Crypton, all data that is saved to the server is encrypted first, making even a server compromise an exercise in futility for the attacker.

A key feature is that you can run Encryptr on your phone as well as your desktop and all data is available in each place immediately. Have a look:


The author of Encryptr, my colleague Tommy @therealdevgeeks, has recently blogged about building Encryptr. I hope you give it a try and send him feedback through the Github project page.

Crypton Logo

Since I left Mozilla last year, I have been working on Crypton ( https://crypton.io ), an HTML5 application framework that places privacy above all else. Last month, my team was invited to the ‘Hack In The Box’, Malaysia security conference to lead a Lab Session on Crypton.

We were required to write a whitepaper for HiTB to publish, which was a great exercise, as my team has been meaning to write a paper for some time. It was a long trip, but worth it. We led a group of engineers through most of the Crypton API in about 2 hours.

I lived-coded the ‘skeleton’ of a messaging application in 74 lines of JavaScript. The coolest thing about this session was using Firefox’s Scratchpad for all of the live-coding. It worked so well, we plan on doing more sessions like this.

Crypton is intended for use inside of mobile and desktop applications (FirefoxOS, too). Our initial target for development is via Cordova and node-webkit. The API hides all of the complexity of cryptography from the developer. Developers use APIs that look like any other hosted API, for instance, account creation looks something like this:

var myAccount; 
crypton.generateAccount('alice', 'password', function callback(error, successResult){
  if (error) { console.error(err); return;}
  myAccount = successResult;
});

Beneath this elegant, every-day-looking API call, a set of encryption keys are generated for encryption, signing and HMAC as well as a stretched key via the password that wraps all other keys. This keyring is then stored on the server making multiple-device operations easy.

As we move forward with the Crypton framework, we are building a “private backend service” which will make using Crypton trivially easy to use and require no system administration. More on this in a future post.

In working on the Web Crypto API specification, the valuable feedback and criticism keeps going back to the main pitfall: DOM malleability. The many attack surfaces in each web page makes handing over crypto keys and crypto primitives quite dangerous. As the W3 working group approaches this API we have this issue in mind, but, the API(s) we want to deliver are not going to solve the DOM-is-dangerous problem. Luckily, browser vendors are working on this – and have been – for years, and the work continues.

Firefox OS will introduce signed “privileged” and “certified” web apps that by default have very strict CSP applied to them. No eval(), no remote scripts or styles – the app is pretty well sandboxed against the most common attacks. These apps are signed and verified before installation and update. Let’s hope these kinds of approaches will help make web apps more “trustworthy”:)

So, how can we use crypto in web pages and not expose anything like keys or actual crypto functions or properties to the DOM? What does that look like? After thinking about the use case for this: web-based messaging, digital signatures for code and document verification – among others, I came up with what I am calling a ‘bridge’ API, I have named it “nulltxt”.

It has one method: window.navigator.bridge.getCipherObject()

This function creates a DOMRequest object, which you can attach event handlers to: “success” and “error”.

To generate a keypair, you pass a config object:

{type: "keygen", format: "DER_BASE64"}

into “getCipherObject”:

var request = window.navigator.bridge.getCipherObject({type: "keygen",format: "DER_BASE64"});
request.onsuccess = function (){ */ this.result.publicKey is our key /* };
request.onerror = function (error){};

Once your keypair is generated, the success callback is executed, handing you a public key and an ID you’ll need to decrypt or sign with that particular key. Multiple keys can be generated per origin.

To encrypt data, you call the same function with a different config object:

{ type: "write",
  format: "DER_BASE64",
  recipientName: "drzhivago",
  publicKey: A_PUBLIC_KEY,
  keyID: 7635263572 
}

This operation opens a special writing widget in the browser chrome where you can safely write plain text outside of the DOM:

Write some plain text, then click the encrypt button. The browser encrypts the data and returns it to your success event handler. The encrypted JSON blob is now available to send to the server where it can be received by Alice.

The result object looks like:

{
  "content": "yeGwdhLSs8qKDywerhs7pchNzxIpmtRGuBf59zMHegR/+urU20RbGxmHEvrx5yxmcEk8j9yPYHJLRKH6SJlEcDR4TKFzWNYLsMdoAxFi7AecN74MP2s0udvmg4vU944hYFo/F3fh2E9hnBF6xsdoRtCdkiNBLTRINCdDv3dgxLEe1UgdeXpbsIljgHc8svaD/lYik2rV+UojHk0yk9NFzv2tCu8wb58kzZluuo10qyqrX1X/rLpu2ZVlk/Ik+MbM7HxK1cSBL5kqUdNU/tx9qqVZVLzcAZz2ZDr2l0wRGKwoJ3f41QrwN8SGCRvMtpPEl1PdcYtdpTg4atAbNZ7T3cJhybtrYW64Yu7d9coguFQg2TQFU8hyIiWdFhY7XqOwR71KNgkHQr+ET/dRpV6TmBlN5IiUMgKq7achpOjkyJEBCfEURRpV71ViEo+37dT1SqIzxhlNY8yDn2gPhcC/DHk4eXi5axFkg4OyhxD9Q7hW7oW+1K/pzjYm2M+yCTtguQ9xikYouiiYbC3oFKMO9F6unfmDHJKc/XwWI9nsuYwSVSqPPZ8tj91pI/SB/ng8UyCojPrUO/jJ3cHjsWccY2XDg5ryVYVAmNWQQ9UEsTT8WrwyJ04i9/FEEYvVznyHlYB3z9diKDW35j7EZKPJQi7uYQVcdB3e2NMve2JPrxxwmebBLrHv4hpfaKmS8NcWpvJYp5r5U1iVLnwIpH98wEsHSrhyBKwBq1bf7s+Lvz9Hx8XuME4zbC6SN4j00QIx4eU3yuKnsa2LGj7b8UQ0GrtNwiRWKwF+qaH15f5rUEUN/9bwdljUVkXNbRg0s1Jde8z/OWevnS/B/AX760fPRxVz6QtEcKCSKZd5AqiVnqSTSzJmvY2izmweHb0uUde7PMsY3aYhNU9eNpA7p2Wmvd+YbSQjMNgnaqB9I+XwNwVZymjhQzar91FZtFSvw4YERA/zUIPFVgrEwdnOnp0t0ORyVOo1QZnvyPMwVddfWpN68aJCVK5dYGyI1uL8CzcBjZqgRjuKSQgt9JfhZJakvdXXPyCq3y5N8cbZZeQvpK8VcRCFHk6fRGrt4vAVSU6dgNewEoj51j+RsH0OOgcuCyJJ7BZgP4mHrrQWfLelnMU=",
  "pubKey": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8p4gH/RlmICUyCJop4AfvHvIkQjMWhUI4keK22MDVyNrDWSektxxX+VN5hLQzmNU/4jTCBBx2gICYcw0DGiw5HGBHp3e0KCmhcc48s3tLwf1TUuhdCEj1v+Oq+Z0FhVEEUF+GYpMBLQvy2HGlPUHbOZsYamKUspMnuiLgqNdsEmjQtO3L8tfrfGcksb7K3siPDomcya1NPkIsmInHy3KB4yv8ATcVQS1rIQ/6I8/vb5OBoVKa9dLm42C5lVcBd9SFqCIxy49Z52DU7y48LmDayUvtrHZx5gI61mV2/CWDhwWSnAD9l/f/s8IjHxuuWzYfaRaO+6ROY380TNIigjTswIDAQAB",
  "wrappedKey": "DWscCbnT63FJuU7dQueXverB31cU0A49omSHw98aqlkW/8qiKuyQgWss9QNp/8qB97xjheJxQcozKrkbulF1ExCfSFuGXR++psel8LFiXoreDRwxJPO/Fqbqf9bIBLpOHx6GLjbUze4fWEGHs1Dt22GHHLvkaHgFPc+sBZcHvHnKF1+iKFonFXSDfUODozNV/poyi1UJ6RrXX/HIgbUlkUos02FcTn9qQqATRUj4lAY0tgFJlqJdpiQJDOWcWV3DJtaPIU2qPo9i95xFDzXBZbb6j/zp6518urFh8hSQKJUG4JPI0yeeW3iTEgN6EUTl0gYXgGvYDQIbeCM+oRZj+A==",
  "iv": "dITA6JK5SUBeP/Hgn6xf1w==",
  "type": "encryptedData",
  "format": "DER_BASE64",
  "signature": "wkkhQVZW3MdQtZha/AKf6hdIntKQI74vvYwKG+VtxUN+XXup2GkeNXWzJJY51YQC2/3EPwn6n+lUXm2xCRjV4ICY3+A0nbZrZnNrG0t6QpDWIQz1g9YYLe8pysjym95CsKy7AlXgo43BX811fv+aShQQTRkLwur5/geHF8idIeYORqt0B/9pwOnjfZnshT4Cj5ILwoe2VKZ3eWnIxND1a3Z8rE0s6WTFojFbshGQU6pf8dOj8w0cD6EDuOnEQ7Y40GbdwR9G3PhDY/JhMUjODhP+5X9nXesW2VlMPXE0byNhtzbnzg5Yi0pP9eBr7t5fTjwBTg5XjR4qDZKeyF0pqQ=="
}

Reading plain text is the reverse process, your app will need to change some of the properties of the received object:

var readCipherObject = receivedCipherObj; // an object received via the app 
readCipherObject.type = "read"; 
readCipherObject.authorName = "Alice"; 
readCipherObject.keyID = myKeyID; 

var request = window.navigator.bridge.getCipherObject(readCipherObject); 
request.onsuccess = function (){ */ this.result.verification contains the 'verification' boolean /* }; 
request.onerror = function (error){};

The reading UI looks like:

Upon clicking “Decrypt”, the content changes to plaintext:

The plain text is read inside the reading widget and is keep out of the content DOM. A validation boolean property is returned in the success event handler, none of the text.

This UI in this addon is only a part of the point of it. I have long wondered how crypto can be used more safely in web apps – where we don’t have to worry about keys being stolen and primitives being ‘monkeypatched’. I am fairly certain the UX can be made much better. The main idea I want to get across is the internal API. It is quite simple. Once you have a keypair, you can do “hide()” and “show()” – similar to the simplicity of Dan Bernstein’s NaCL (box/unbox).

Sign() and Verify() are also in the works. I would also like for this API to support IETF’s JOSE formats.

If you would like to give “nulltxt” a try, (remember, nulltxt is EXPERIMENTAL ONLY), the addon is hosted here: https://addons.mozilla.org/en-US/firefox/addon/nulltxt/

A demo page is hosted here: https://nulltxt.se/nulltxt/demo-code/demo.html

And, of course, the source code is here: https://github.com/daviddahl/nulltxt-extension/

Let me know what you think of this approach. I can imagine a web application where the web site only ever handles ciphered data and provides no crypto in the DOM – offloading all of it to the browser chrome. Of course, there are still attack surfaces here, mainly around spoofing the browser chrome UI. With a severe CSP in place, I think this approach might work well.

Good news! With a lot of hard work – I want to tip my hat to Ryan Sleevi at Google  – the W3C Web Crypto API First Public Working Draft has been published: http://www.w3.org/TR/WebCryptoAPI/
If you have an interest in cryptography or DOM APIs and especially an interest in crypto-in-the-DOM, please read the draft and forward any commentary to the comments mailing list: public-webcrypto-comments@w3.org

On Monday, May 7th, 2012, there will be a public call to discuss the Web Cryptography API. Via the W3C public-webcrypto mailing list:

Join us next Monday 7th of May, from 19:00-20:30 UTC (3:00pm-4:30pm Boston local)

*         Zakim Bridge +1.617.761.6200, conference 27978 (“CRYPT”)

*         IRC irc.w3.org:6665  #crypto

Please dial in if you would like to discuss or find out the plans for this important specification.

In a previous episode of “Privacy Claw-back”, I deleted the contents of and removed my Facebook account. That was kind of hard to do at the time as I wasted a whole lot of time on Facebook – it was really fun reconnecting with old friends.

However, I began to think critically about Facebook. This is where all of the problems come in. Facebook’s creation is a tale of amazing scale, ingenuity and engineering prowess. The dark side of the equation is the unprecedented knowledge that can be gleaned from our data about us. The impulse to use this data improperly is probably impossible to resist.

Google is another can of worms. They did not become the biggest search engine for nothing. The amount of information Google has about you, your spouse, your friends, kids, your preferences, likes, dislikes, where you go, who you talk to, what might ail you, political views – it goes on and on and on.

It is time for me to disconnect from Google. Can I do this and still have a positive internet experience? I hope so. I began this process over a year ago when I switched to a PAID email service, pobox.com. It works pretty good. I am fairly confident my email is not datamined, and the web UI is OK – not the best. (That is what Thunderbird is for). However, I kept my GMail accounts and Google-hosted mail service intact (but idle), just in case.

For search, I switched to DuckDuckGo.com well over a year ago. It has gotten really, really good. I have found myself using Google less and less. I even changed my “urlbar keyword” search in Firefox to use DuckDuckGo. (I occasionally use Bing and Yahoo as well).

Twitter is the only hold-out as I feel like Twitter is “not evil yet”. Perhaps someday Twitter will become a protocol. That, I hope, will be inevitable.

Today, as I read about Google’s new non-opt-out privacy policies, it occurred to me that I really don’t rely on Google anymore, I have slowly freed myself from that dependency. I may yet have issues using certain apps on my Android device and I need to figure that out next. (Yay, Boot2Gecko!).

In the meantime, I have taken this experiment up one notch by adding google.com and http://www.google.com to resolve to my local webserver in /etc/hosts – my machine can no longer reach Google or Facebook. (or Google analytics servers for that matter).

The point is, there are many great internet services out there that you can rely on to handle search, email and social that don’t infringe on your privacy, try them out!

When I found out I could choose my own title at Mozilla I was ecstatic.

Of course coming up with a good one is another matter, I thought about it for days and days…

I thought about my “newbie” place at Mozilla and dredged my unconscious memory of all of the movies I had ever seen and chose the title: “Civilian Observer“.

Folks who have seen my business card are aghast – “What the hell does that mean?”

Surely you remember the 1980 movie “The Final Countdown” starring none other than Martin Sheen? (For my millennial readers, that is Charlie Sheen’s old man). His role was that of “Civilian Observer” on board the USS Nimitz.

From Wikipedia:

In 1980, the supercarrier USS Nimitz (CVN 68) takes on a civilian observer, Warren Lasky (Martin Sheen), at the orders of his reclusive and mysterious employer, Mr. Tideman (who helped design much of the ship), just before it departs Pearl Harbor for a training mission in the Pacific Ocean. Out in the Pacific, the ship encounters a strange storm-like vortex which disappears after the ship passes through it.

Naturally, I am not going to spoil it for you, but the Civilian Observer helps try and figure out alternative ideas for the strange place the ship finds itself in.

In working on open source or free software, you know there is a lot at stake. I feel like all of us are observing the growth of the internet and with it the growth of attempts at curtailing the power that this computer network gives us. We are seeing more and more of the growth of surveillance technology, some of which is created in Silicon Valley – technology that is used to prevent and record private communication, help identify and  round up and torture or kill dissidents all over the world.

The battle for the Web and the Internet is a full on war. It will always be that way. The issues of privacy vs. surveillance, open or closed software stacks and walled gardens are here to stay. We must be vigilant and we must create tools that fight and overturn the impulse to control or subordinate and use people and networks of people.

I have felt like the “Civilian Observer” since before I started at Mozilla, its just become more pronounced in the past few years. Take for instance, a smattering of my Twitter feed – tweets and links selected in the past day, mere hours:

a tweet

a tweet

a tweet

a tweet

a tweet - no link

a tweet

a tweet

a tweet

a tweet

a tweet

a tweet

a tweet

a tweet

a tweeta tweet

Sometimes these tweets pop up right after one another:

2 tweets

a tweet

Wow!, right?

Recently, WikiLeaks published a database of surveillance companies that produce tools that provide “Mass interception of entire populations…“.

These tools deployed on a mass scale essentially turn the Internet into a surveillance system.

We need more Countermeasures for this.

Firefox is one of these countermeasures, without it we would really be in a world of pain. I cannot even imagine how craptastic the net would be without Firefox.

Mozilla’s Boot2Gecko project is also a countermeasure. If we pull this off, it will truly be a Coup d’état in the mobile device space. The goal: building mobile phone apps from HTML, JavaScript and CSS! That is the way it should be.

Deuxdrop is another project in Mozilla labs trying to create a secure messaging system – I have high hopes for it. Again, these are the kinds of tools that need more focus.

I have been working on DOMCrypt for a few years now. DOMCrypt provides a Cryptography API in web pages, making it trivial and fast to encrypt data that may be part of a message to another web user or data that should stay private while stored in LocalStorage (amoung many other use cases). I am proud to say we have implementation bugs and plans lined up for both Gecko and WebKit. The W3C is using the API as the strawman proposal for the Web Cryptography Working Group. Web developers will be able to use strong and fast crypto via a DOM API. Exciting stuff.

Web developers are way out in front on this issue – there are several crypto libraries for JavaScript out in the wild, and developers are using them to push the envelop in web apps.

This is great stuff, but we need safer, built-in crypto APIs for browsers to provide a foolproof way to use crypto in the browser, not to mention the speed boost you get when calling native code APIs vs. native JavaScript functions. The other thing we need are new ways to communicate. The Web has won as the default communication channel and developers need to be able to write apps that allow people to communicate without sharing the conversation with a 3rd party.

Not sharing data with a 3rd party is the key issue. This concept destroys a lot of business models, well, one business model – the one everyone seems to think will work long term. I doubt that. Here’s a business model you can try: make a cool product and charge people a small fee to use it while simultaneously preserving their privacy. Novel, isn’t it?

What can you do to help? You can demand privacy and security be a feature of the products you use, not an afterthought. You can help test or help develop “countermeasure” applications.

Wikipedia lists several applications that enhance communications with more security:

https://en.wikipedia.org/wiki/Secure_communication#Programs_offering_more_security

(The link above does not mention  Tahoe-LAFS – please comment if you know of any more notable applications or toolkits)

I hope the future will bring a slew applications and startups that trumpet privacy and security enhanced applications. I hope web developers begin to think about more creative uses of their talents than online coupons and advertising-funded social media. The future of online privacy and security is both bright and bleak. Bright in that we have the CPU power, talent and base algorithms sitting right in front of us. It may seem bleak if you think no one cares about privacy or there is no ‘free lunch/free beer’ business model.

Another thing you can do is support organizations that are “watching the watchers”, the EFF, Privacy International and others. A great resource for this is privacy.org.

The Final Countdown Poster

The Final Countdown Poster