[dagw]

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.

[tptacek]

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.)

[hackermom]

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.

[tptacek]

Say what? SJCL uses full-width binary keys.