Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My gripe is the same as the overwhelming majority of people in my industry: that given unlimited resources, in your wildest dreams you couldn't imagine a less hospitable place for cryptographic integrity than the DOM.

Some people are of the opinion that the usefulness of being able to do crypto in people's browsers outweighs exactly how inhospitable it is. I don't share this opinion.

In most circumstances, something bad might be preferable to nothing at all. I think crypto is one of the rare exceptions where "bad" is actually worse than none.

My alternative suggestions are conservative: PGP and TLS

These suggestions aren't particularly exciting, however, so people keep looking for other, newer, ones.

I'm actually in the small minority of security people who don't think it's feasible to discourage people from trying to muck around with crypto. It's like sitting a kid in front of a television,handing them a video game controller, and then telling them not to play video games.

Crypto is an attractive nuisance. It also seems like it answers a lot of our problems (it actually answers far less than we think, and just creates new ones in their place), so people naturally are inclined to experiment with it.

So I hope someday to be wrong about crypto in the browser, because it'd be great. But right now, it's sort of like trying to fancy up a glory hole.



I'll admit that browser-based scripting isn't high on my list of secure environments either. It does, however, do a nice job of getting around the fundamental problem of finding some environment that's reliably and consistently available. It also nicely end-runs the problem of trusting a remote site to hold your data in confidence.

There's the remaining problem of key management, though for many people, browser-based password managers are a reasonable mechanism.

PGP/GPG and TLS still provide key management issues (with several notable registrar incidents in the past year). And even if you're, say, parking a public key on a site to autoencrypt material sent there (assuming it's not encrypted prior to upload), there's the question of how you're going to interact with encrypted data on that site. I see three basic options: server-side encrypt/decrypt, browser-based, or client-side non-browser utilities. In the latter case, you now have a wide range of environments (Windows variants, Mac, Linux, etc.) to support.

Not saying it can't happen, but good crypto is hard.

Even the pros (PGP) ended up using a server-based solution which had both public and private keys on it as their solution to the key-management problem.


http://www.w3.org/2011/11/webcryptography-charter.html

Something like this is the ONLY way I can see crypto in the browser gain any credibility and traction. Crypto in the JS is not only potentially the easiest attack vector, it's also abhorrently slow. With native browser constructs we get access to safe(r) implementations which cannot be DOM manipulated, MITMed or simply replaced at load time. We get access to speed boosts by running natively and on hardware supporting AESNI it can zoom.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: