[jvdongen]

This piece has surfaced before. Then and now I see people coming out of the woodwork with seemingly smart ideas about how it still should be possible to safely use crypto in the browser one way or another.

One of the things my company does is security testing of web applications. Regularly we encounter 'creative' use of cryptographic techniques (both in the browser and server-side) and each time it makes the hacker in us smile, because we know it is not a matter of 'if' we'll crack it but 'when' we'll crack it. Good crypto is a roadblock, bad crypto is just a challenge. And although it is very hard to decide if the crypto is 'good (enough)', the 'bad' is usually glaringly obvious.

With the current state of crypto in the browser - just forget it. That's what Thomas is trying to get across: forget it - if you think you've found some smart way around one of the weakness he addresses, you're very most likely wrong. And even if you seem to have got it right, you're probably wrong still without anyone realizing it (yet).

Same is true for building a crypto-system from primitives. Use what's out there, designed by the few people who know what they're doing.

Remember: from the defensive side you need to get everything right. As an attacker I only need 1 hole. That's what makes it "capital-H Hard".

[haberman]

I don't know if you're referring to my comment or not (http://news.ycombinator.com/item?id=5123674), but I was not saying anything about what is safe. I was merely objecting to false equivalences that the article was drawing.

To say that localStorage is literally no better than server-side storage is a strong statement, and one that does not appear to be literally true. Taking issue with that equivalence is not the same as saying that any particular system/design is safe as a whole.

[jvdongen]

I was not referring to your comment per se, but indeed your comment fits the general sentiment I was referring to.

And I think that localStorage is indeed literally no better than server-side storage. Whether it is any worse depends on the situation - but better it is not.

"This ignores the scenario of app deployment models like Chrome Packaged Apps, in which the JavaScript code gets downloaded up-front and then is only used locally. Since you don't re-download the code every time, you only depend on the security of the code once, up-front, instead of on a continuous basis. You aren't affected by server compromise (well, no more than compromise of your OS vendor, but surely you aren't arguing that we might as well send all our keys to Microsoft, Apple, and Canonical)."

It's true that you do not re-download the code every time. Still, the trustworthiness of the code you received initially depends on the trustworthiness of the server you received it from.

So you say, "but what if I have reason to trust it initially and not later on?", e.g. when the government comes knocking.

Well, there are two things to keep in mind in that case:

a) you download other stuff with your browser. Stuff that can influence the environment where your secure and trusted packaged app runs in. See also comment of zimbatm - even if it is not formally meant to be that way, in practice there are bound to be ways around any limitations - sandboxing in browsers is still nowhere near perfect unfortunately. Server security is not entirely peachy either, but at least on a properly secured server only a limited, carefully screened set of applications is allowed to run which makes things hell of a lot easier.

b) Chrome packaged apps support auto-updating, so unless you take steps to prevent that from happening, you're never sure you're running the same version today as you did yesterday. Again, trusting the server to serve you a trustworthy version of the app repeatedly. And if you're trusting the server already, local storage is no better than server side storage.

So I guess you could say local storage is better than server side storage (for some definition of better) if you run one and only one packaged application ever in a specific installed browser in an isolated environment. The browser + locally installed web app then effectively becomes a natively installed application without an Internet dependency. More secure indeed, but kind of defeating the purpose of that whole web thing ;-)

[haberman]

Chrome packaged apps support auto-updating, so unless you take steps to prevent that from happening, you're never sure you're running the same version today as you did yesterday. Again, trusting the server to serve you a trustworthy version of the app repeatedly. And if you're trusting the server already, local storage is no better than server side storage.

Again, I think this reduces to "Microsoft/Apple can auto-update your OS, so you might as well send your keys to Microsoft/Apple." Would you argue that? If not, why?