Archives For JS

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.

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

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.

>For ages, I have relied on Douglas Crockford’s excellent supplant() for my string formatting needs in JS. It works great with whatever objects you have already hanging around in your code:

var myObj = { name: "Conan", surname: "The Barbarian" };

"{name} {surname}".supplant(myObj);

// result:

"Conan The Barbarian"

This is great, reliable and all that…

But it is a bit verbose in the cases where you do not already have an object hanging around with the correct properties. I tried to find an existing implementation, but most of them were still too verbose relying on hacks like: “{$1} {$2}” or “$1 $2″ or worse.

I want a “printf” or Python-style string interpolation:

#python

"%s %s" % ("Conan", "The Barbarian",)

// result:

"Conan The Barbarian"

That’s what I want! – only for strings, it doesn’t have to be too feature-rich. Eventually it would be nice if it could handle integers and floats etc.

After some questions and answers on irc in #js, I was able to get something rudimentary going. I started with supplant, and added support for arrays and arguments.

Behold! String.printf():


String.prototype.printf = function (obj) {
var useArguments = false;
var _arguments = arguments;
var i = -1;
if (typeof _arguments[0] == "string") {
useArguments = true;
}
if (obj instanceof Array || useArguments) {
return this.replace(/\%s/g,
function (a, b) {
i++;
if (useArguments) {
if (typeof _arguments[i] == 'string') {
return _arguments[i];
}
else {
throw new Error("Arguments element is an invalid type");
}
}
return obj[i];
});
}
else {
return this.replace(/{([^{}]*)}/g,
function (a, b) {
var r = obj[b];
return typeof r === 'string' || typeof r === 'number' ? r : a;
});
}
};

Examples:

"{f} {b}".printf({f: "foo", b: "bar"});

"%s %s".printf(["foo", "bar"]);

"%s %s".printf("foo", "bar");

// all of which give this result:

"foo bar"

Let me know if you think of more tweaks for this – or problems. It pains me every time I see concatenation in JS code. Question, which is more efficient? ‘+’ or String.replace()?

Cheers!