[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/
- [woes] Fwd: Javascript Cryptography Considered Ha… Peter Saint-Andre