Hacker News new | ask | show | jobs
by mr_justin 5847 days ago
Can somebody explain the practical, real-world use of a library like this? My first reaction was for encryption of sensitive data before a form post but then don't we have SSL for that? Plus, since it can be decrypted if you know the password, and the password is in the source code ... I don't understand why I would use this.

Maybe for server-side JavaScript, such as node.js, but the authors of this plugin seem to omit server-side JavaScript from their notes for whatever reason.

3 comments

It could be useful in extensions for browsers which support javascript-based plugins, like Firefox and Chrome.
Off the top of my head, the one use a came up with would be to incorporate it into the web front end for a cloud based file storage site. This would give users a quick and painless way to encrypt files before uploading and offer protection against snooping employees.
This is a bad idea. The value of encrypting-before-uploading is that you don't have to trust the server. But you implicitly trust the server when you except encryption code for it.

This fact usually sets off a day-long thread about the things you can do trust the code (read it! hash it! deliver it via SSL from a trusted CDN!), but these arguments always miss the fundamental point that you are trusting code that is (a) delivered over the network (b) at least partly by a server you don't trust (c) in an environment that binds arbitrary evals to every element of the DOM (d) using a language that allows you to override and booby-trap almost every operation. It's just not going to work.

SJCL is awesome. Figuring out how to efficiently implement crypto in Javascript is a really valuable research project. But right now, you shouldn't be using this outside of serverside Javascript or custom clients.

(And, really, if you have to type the letters A-E-S or H-M-A-C, you're doing it wrong anyways.)

The only problem with string-only encryption, as used in Stanford's library, is that you have to base-encode your data first, costing extra time, and causing the data to grow in size (larger storage costs, more bandwidth usage). Using string-only keys is from a security perspective also a larger problem than people realize.
Say what? SJCL uses full-width binary keys.
node.js has OpenSSL bindings.