Thanks for sharing aes.io. That's the first I've heard of this service. Since their a web app with client-side encryption, I presume their using javascript. If so, any idea how they address the problems mentioned in this post ( http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... ).
Update: Looks like they are using some kind of embedded flash. Does that mean a flash or actionscript cryptography implementation?
1. all encryption/decryption is done in JS. BouncyCastle java source code is used (slightly tweaked for performance) - it is compiled into JS using Google's GWT compiler.
2. flash is only used for triggering file save dialog, similarly to downloadify, in browsers that do not support HTML5 alternatives. In Chrome, which supports <a download>, flash is not used (100% JS/HTML5)
3. problems mentioned in the post you referenced can be generalized into two groups: (a) hijacking the server to serve "trojaned code", and (b) inherent JS limitations such as the absence of proper PRNG.
Concern (a) is valid. However, most client systems have auto-updating software products installed, with auto-updating enabled (browsers auto-update themselves; anti-viruses and OSes do the same, etc. - the Flame worm was using Windows Update to sneak in, I think). It is a universal issue in the modern "connected" world, and most users have to live with this threat if they want to use the Internet in any meaningful way; I can't imagine a person eyeballing the source of every patch they compile/apply on their system.
Concern (b) is not really valid now, IMHO. As mentioned above, it is possible to use a solid open-source crypto library either directly (e.g. Stanford Crypto JS library) or compile one into JS, to use proper PRNG, etc. With proper testing (standard/published test vectors; cross-platform tests - encrypt in JS and decrypt in java, etc.) it is possible to make good crypto in JS. And things like side-vector attacks do not look relevant here, as the attacking code needs to run on the client, which means the client has been compromised already.
Thanks for replying. Excellent choice on BouncyCastle and it never occurred to me the clever compilation to JS using GWT. With that said, why not use the OpenPGP (RFC 4880) support instead of PKCS#1?
How about doing a ShowHN so we can get some more eyes on your new product? There are quite a few security folks here who can more adroitly chime in regarding the use of clientside JS. You may have seen this post as well, http://www.matasano.com/articles/javascript-cryptography/ , which was written by Thomas (user tptacek) who is quite active in participation here.
Will do ShowHN when I'm allowed to (getting "You're submitting too fast. Please slow down. Thanks.")
Re: OpenPGP vs PKCS1: historical reasons (have a well-tested code for PKCS1). If at some point it becomes clear that OpenPGP is much better, adding it won't be a big issue.
Update: Looks like they are using some kind of embedded flash. Does that mean a flash or actionscript cryptography implementation?