[woes] Fwd: Javascript Cryptography Considered Harmful

Peter Saint-Andre <stpeter@stpeter.im> Mon, 12 September 2011 16:32 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: woes@ietfa.amsl.com
Delivered-To: woes@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75C521F8B7F for <woes@ietfa.amsl.com>; Mon, 12 Sep 2011 09:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level:
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gIXx8eHtUp3 for <woes@ietfa.amsl.com>; Mon, 12 Sep 2011 09:32:12 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1604521F8B45 for <woes@ietf.org>; Mon, 12 Sep 2011 09:32:12 -0700 (PDT)
Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 98F99419CB for <woes@ietf.org>; Mon, 12 Sep 2011 10:37:26 -0600 (MDT)
Message-ID: <4E6E3487.1010803@stpeter.im>
Date: Mon, 12 Sep 2011 10:34:15 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: "woes@ietf.org" <woes@ietf.org>
References: <C2F8FC46-71A3-4C29-BBC4-74F07AABB217@bblfish.net>
In-Reply-To: <C2F8FC46-71A3-4C29-BBC4-74F07AABB217@bblfish.net>
X-Enigmail-Version: 1.3.1
OpenPGP: url=https://stpeter.im/stpeter.asc
X-Forwarded-Message-Id: <C2F8FC46-71A3-4C29-BBC4-74F07AABB217@bblfish.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [woes] Fwd: Javascript Cryptography Considered Harmful
X-BeenThere: woes@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <woes.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/woes>, <mailto:woes-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/woes>
List-Post: <mailto:woes@ietf.org>
List-Help: <mailto:woes-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/woes>, <mailto:woes-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Sep 2011 16:32:13 -0000

Perhaps of interest here...

-------- Original Message --------
Subject: Javascript Cryptography Considered Harmful
Resent-Date: Mon, 12 Sep 2011 14:36:47 +0000
Resent-From: public-xg-webid@w3.org
Date: Mon, 12 Sep 2011 16:36:15 +0200
From: Henry Story <henry.story@bblfish.net>
To: WebID XG <public-xg-webid@w3.org>

An interesting article
http://www.matasano.com/articles/javascript-cryptography/

WHAT DO YOU MEAN, "JAVASCRIPT CRYPTOGRAPHY"?
============================================

We mean attempts to implement security features in browsers using
cryptographic algoritms implemented in whole or in part in Javascript.

You may now be asking yourself, "What about Node.js? What about
non-browser Javascript?". Non-browser Javascript cryptography is
perilous, but not doomed. For the rest of this document, we're referring
to browser Javascript when we discuss Javascript cryptography.

WHAT ARE SOME EXAMPLES OF "DOOMED" BROWSER CRYPTOGRAPHY?
========================================================

You have a web application. People log in to it with usernames and
passwords. You'd rather they didn't send their passwords in the clear,
where attackers can capture them. You could use SSL/TLS to solve this
problem, but that's expensive and complicated. So instead, you create a
challenge-response protocol, where the application sends Javascript to
user browsers that gets them to send HMAC-SHA1(password, nonce) to prove
they know a password without ever transmitting the password.

Or, you have a different application, where users edit private notes
stored on a server. You'd like to offer your users the feature of
knowing that their notes can't be read by the server. So you generate an
AES key for each note, send it to the user's browser to store locally,
forget the key, and let the user wrap and unwrap their data.

[...]

Henry

Social Web Architect
http://bblfish.net/