Precisely which vetted, client side, JS crypto library would you prefer the authors use to satisfy your concerns? I haven't looked at the code, and only recentl

Precisely which vetted, client side, JS crypto library would you prefer the authors use to satisfy your concerns? I haven't looked at the code, and only recently started paying attention to the JS-Crypto space. I'm aware of implementations where scrypt was compiled to target the asm.js subset, however, this doesn't really mean the resulting JS running on platform x, in browser y is as secure as the resulting binary on the platform/OS it was targeted for. Scramble has not been widely vetted, so don't rely on it to protect you just yet. The authors put the above line as part of the very first bit of marketing you encounter. Until the JS has full (vetted, industry standard) crypto functions designed to be secure for the each target platform, vetting this kind of crypto is going to be hard. The addition of a cryptographically sound PRNG is a big move in the right direction. That said, I believe the authors got it right with what is currently available: Inform the user in such a way that there is no confusion, open source the code so others can participate in vetting, get some attention to the project so others are motivated to participate in vetting, and continue to improve as problems are discovered. That's really the best you can do, IMHO. In security, the author of a library needs to be correct 100% of the time while an attacker needs to be correct only once.