Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stanford Javascript Crypto Library

crypto.stanford.edu

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Stanford Javascript Crypto Library

#71

Post by anon1385 »

3JPLW wrote: post #26
anon1385 wrote: post #10

Earlier quoted context omitted.

>This is wrong, because using both means that the web service we are using (for example) never knows our plaintext password, so they can't attack us under the assumption of password reuse, like in http://xkcd.com/792/ TLS doesn't protect you against a malicious site that is collecting passwords. Even if you were to examine the javascript code to verify that it isn't sending the plaintext[1], they could send a differe…

You must always trust something . In the case of a SpiderOak-like service, you must trust one of their client implementations to use it. Whether it is their compiled binary (which isn't even open source[0] "yet") or a javascript client in the browser delivered securely. Even in the case of tarsnap, with open source implementations that don't self-update, you must trust your own code review or somebody else's -- not a…

Yes one must always trust something[1], but the impression I get is that people seem to want to use JS crypto specifically so that users don't need to trust the server with their data. But crypto in a js webapp can't provide that assurance.

I struggle to see what the point of it is[2]. You are already (hopefully) sending all the user data securely over the wire. In a current app the user needs to trust the server with their plain text data. With a js crypto app the users needs to trust the server to provide the crypto code to encrypt their plain text. Either way the user has to trust the server and once the server is compromised their data is trivially retrievable. At best it would prevent your data being seen until you login. If all you are interested in is data storage that is secure because nobody ever retrieves the data then I can offer you a great price on such a service.

[1] http://cm.bell-labs.com/who/ken/trust.html

[2] other than attempts to provide plausible deniability for legal reasons

Re: Stanford Javascript Crypto Library

#73

Post by sneak »

jonpaul wrote: post #20

Anyone interested in signed JavaScript? Initiatives like this are great. However, I'm most interested in signed JavaScript. I'm surprised that there isn't more of a discussion going about this since JavaScript crypto is near worthless if it's served from an untrusted server. For example, let's say that you have an application that uses client-side crypto in JavaScript. Then let's assume that the server (that serves u…

Signed by whom? Signatures distributed how?

Re: Stanford Javascript Crypto Library

#74

Post by sneak »

methehack wrote: post #56
tptacek wrote: post #42

Earlier quoted context omitted.

You don't just need to authenticate sjcl.js (or whatever). You need to authenticate every page element that can influence the JS, because JS is malleable. The service you propose won't work.

Well, couldn't checksum the whole page? I know that creates a big pain in the ass in terms of modifying the page and in terms of making the page dynamic, but bracketing those two concerns -- why wouldn't that work?

You can checksum the whole page, but any externally loaded JS can monkeypatch any other part. Use analytics? How about a payment widget? All of these can affect every part of the js environment, overwriting anything from jQuery to sjcl. Alternately, they could leave the crypto alone and just hook into keystroke handlers or the DOM and steal your plaintext that way.

Also, some browsers will run JS from urls referenced in img tags as long as they are served with a text/javascript MIME type.

It's far too big an attack surface.

Re: Stanford Javascript Crypto Library

#75

Post by sneak »

malandrew wrote: post #23
meshko wrote: post #4

Obligatory quote from http://www.matasano.com/articles/javascript-cryptography/ WHAT ABOUT THINGS LIKE SJCL, THE STANFORD CRYPTO LIBRARY? SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document. SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young. The authors of SJCL themselves say, "Unfortuna…

What if the sites used SJCL by default, but urged the user to install an official browser plugin that detects the presence of SJCL on a page and falls back to the browser's own copy of SJCL, always trusting it over any copy sent over the wire. It's not perfect but at least gives users a stepping stone to secure communications. The biggest problem with getting users to adopt crypto is giving them stepping stones to so…

Then instead of backdooring the sjcl, the malware would just steal the plaintext out of the DOM or hook into keystroke handlers.

The problem is JavaScript.

Re: Stanford Javascript Crypto Library

#76

Post by sneak »

tghw wrote: post #54
sdevlin wrote: post #53

Earlier quoted context omitted.

How would this protect you against a malicious server?

If the server serving the HTML is pwnd, then it doesn't, but it doesn't really matter then, either. This protects against any external scripts being unexpectedly modified, e.g. someone MITM your jquery source.

If you don't allow external scripts to be modified, why host them externally at all? Why not just wget them and host them locally alongside the checksum document and skip all this silliness?

Oh, also, those scripts can themselves load in other scripts you haven't checksummed.

This is madness you're suggesting.

Re: Stanford Javascript Crypto Library

#78

Post by bigiain »

anon1385 wrote: post #71
3JPLW wrote: post #26

Earlier quoted context omitted.

You must always trust something . In the case of a SpiderOak-like service, you must trust one of their client implementations to use it. Whether it is their compiled binary (which isn't even open source[0] "yet") or a javascript client in the browser delivered securely. Even in the case of tarsnap, with open source implementations that don't self-update, you must trust your own code review or somebody else's -- not a…

Yes one must always trust something[1], but the impression I get is that people seem to want to use JS crypto specifically so that users don't need to trust the server with their data. But crypto in a js webapp can't provide that assurance. I struggle to see what the point of it is[2]. You are already (hopefully) sending all the user data securely over the wire. In a current app the user needs to trust the server wit…

I've got an odd use-case where JS crypto _might_ be a sensible choice…

A piece of hardware, with an embedded linux machine and wifi capabilities – intended as a piece of consumer electronics(1) – with the main user interface being an HTML5 webapp intended to run on a phone(/tablet/computer). The hardware will either boot up and establish a wifi access point that you connect your phone to, or you'll be able to configure it to connect to your home(/office/shop/venue) wifi network where it'll (typically) live behind your NAT gateway on a 10...* or 192.168.. network. In either of those two configurations, it's difficult to ensure TLS secured communication between the phone and the hardware – where by "difficult" I mean "without big scarey 'YOURE ABOUT TO CONNECT TO AN UNTRUSTED SERVER' warnings baked into browsers when they hit TLS certs without proper root-CA-trusted signatures, for a bit of inexpensive consumer electronics aimed at your Mom or grandparents - accepting self-signed certs or installing self generated trusted keys is a difficult UX problem, and buying real trusted-CA-signed certs for production runs of 10,000 is expensive (and it's impossible to then secure those private keys against anyone with a screwdriver).

I'm currently deciding between relying on WPA2 encryption and forbidding access to things requiring sensitive data (passwords) if the wifi isn't encrypted, or using a modified version of OAuth2 and relying on a cloud service that I can TLS secure with a CA-signed cert (OAuth2 assumes you'll TLS secure all the redirects, but I can't use TLS for the phone/hardware segment as described above. I've got an "I hope not too screwball" workaround involving generating public/private keys on the hardware, sending the public key to the cloud server, doing the OAuth there, and instead of sending the auth token back over a TLS secured channel, encrypt it to the public key first then send it over regular old http). I'm now wondering is JS crypto might solve that part of my problem…

(1) in my case, intelligent Christmas tree lights – http://holiday.moorescloud.com for the curious, and http://dev.moorescloud.com for the (open sourced) hardware and software details.

Re: Stanford Javascript Crypto Library

#80

Post by RazerM »

franze wrote: post #68

i built Masel with it (as a demo for our local javascript meetup) i.e.: http://replycam.com/m/ pretty much serverless encrypted message sharing. its MIT L. and unfinished https://github.com/franzenzenhofer/masel

Off-topic, but 'masel' is the Scots word for 'myself'.
Post reply on HN