|
Additionally, it is almost impossible to verify the security of a system that uses encryption via javascript in the browser. The algorithms aren't that hard to verify, but making sure that keys are handled securely, and that you don't open yourself to timing and side channel attacks is really hard with such a big stack of things competing for scheduling, managing memory etc. So there are two problems: 1) You get code from the server and execute it -- it might not be the code you think it -- it might not be the code you got yesterday (and there might be third party code injected, if there is an XSS vector -- or you know, your browser doesn't check to see if the servers ssl certificate has been revoked...). 2) Even if you run the code locally (say distribute it as html+js+css "app" in a zip file signed with gpg) -- it is still running on top of a pretty rickity rack of technologies, your javascript vm, the browser dom, a mess of ui toolkits and c/c++ routines that manage memory -- and has been seen again, and again -- it is really hard to actually implement crypto in such a way that there are no side channel attacks, no timing attacks and no information leaks. Essentially 1) running random code isn't secure, and 2) implementing good crypto is hard. Really hard. The only real solution is to get a good crypto-api into html5/browsers, but even then things aren't "safe". Say you could: plaintext = api.crypto.decrypt(AES-256-CBC, \
ciphertext, key)
Now, what happens with plaintext? Is it written to swap? Cahces? If you use that to show an image in the browser, is the image cached along with other files? |