Hacker News new | past | comments | ask | show | jobs | submit login

We seem to be on a track now such that in 5 years, all the mainstream browsers will support a set of crypto primitives built into the browser, implemented in C, and exposed via Javascript bindings. And that's fine.

But it means that we're not going to have end-to-end crypto in web applications for another ten years, because these schemes don't degrade gracefully; the majority of users will have to upgrade before they become useful.




And I'm not sure that this would be enough, either. Crypto primitives are nice, but you still have to trust the webapp to deliver JS which calls those primitives every time you visit the webapp. I believe that this is again reducible to trusting the webapp with your plaintext, since the webapp could selectively intercept any message it chooses.


A bigger related problem: the argument that browser crypto extensions should be high-level (autogenerating secure keys, automatically MAC'ing ciphertexts, picking the block cipher mode for you) is not winning the day. So what we're going to end up with is an OpenSSL-style interface:

  x = new Cipher("AES"); 
  x.blockmode = "CBC";
  // defaults to all zeroes
  // x.iv = "ABCDABCDABCDABCD"; 
  x.key = "YELLOW SUBMARINE";
  x.encrypt << "This is my plaintext";
In a sense, this is great news for me, because it means I get another 5-10 years of crypto vulnerabilities to get paid to eradicate. But if you're hoping for simple, usable cryptographically strong security in common web apps... well, keep hoping.


Yea, I know, IE in particular is quite infamous, and people has been saying that IE8 is the new IE6 for a while now.


5 years is eternity on the web. Unless browser crypto is pushed through faster, we're gonna see a lot more of these.




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

Search: