The terminus of your argument admits to using ROT13 as a cipher. Surely there's some attacker ROT13 bars. While you're at it, Base64 the "ciphertext". There are professional pentesters that can't recognize Base64 on sight! And if you want to get really tricksy, swap the Base64 alphabet around. That'll hoist that fruit up higher.

In reality, no credible cryptosystem accepts the flaws I'm talking about.

No, it doesn't. My definition of 'low hanging fruit' means anything that can automated to the point of mass data consumption and processing within the scope of a private corporation's resources.

ROT13 clearly falls within this formula.

AES 256 client side encryption, even in JS, over a 256 bit SSL connection with 32 character base key-phrases, uniquely generated for every message, expanded into the full key and exchanged and stored in a secure fashion separate from the location of the encrypted data itself falls outside of this scope currently.

That's true, but I'm not sure everyone should be quite so defeatist as you with respect to implementing crypto. It has and can be done, after all, it just requires care beyond "hey, my PHP script outputs some HTML." The same goes for many, many aspects of programming: design, object lifecycle, memory allocation, error handling, etc. Programming is hard, and implementing crypto is no different. The difference is that mistakes are not immediately obvious and that they can be severe. But that, again, is the case with many things.

If there's anything I've learned so far after observing the security world for a few years, it's that implementing crypto is very different. I think that this mindset from programmers -- "crypto is just like programming" -- is what causes them to constantly, and almost without fail, screw up their password storage systems, their authentication mechanisms, their crypto functions, and pretty much everything else security-related.

Software development in general tolerates (and in some ways even encourages) "acceptable risk". Programmers don't often try to prove that their functions are correct and free of any potential errors. In security-related programming, you can't take the same approach.

Implementing crypto is very, very different. If you're "iterating" the design of your crypto functions, you're doing it wrong.

The reason people screw up password storage is because they don't know they are supposed to think about it. If they flipped the "oh, this is important" switch, the result would be better. But at the end of the day, their bosses are asking them for shiny widgets, not a secure backend. So they are doomed to fail.

The same goes for the non-security things I've listed. The problem is much deeper than getting crypto wrong -- most programmers today get everything wrong. That's why I think if you're the type of person that can think about programming, it's not too unsafe to implement AES in Javascript and use it. You know what the weaknesses of Javascript-based crypto are, and you know how to implement crypto. In that case, why not do it?

Remember: most non-crypto software is massively incorrect. If we can trust people to implement crypto, why can we trust them to be programmers at all?

I think I see where you're coming from, but I still disagree: I've seen way too many examples of otherwise competent programmers still stuck on, for instance, the notion of using salts with fast hash functions for password storage. Hell, MtGox had a post just the other day about their all-new triple-salted SHA256 password storage! Somewhere that day, there was a faint groan from the dismally small set of people who are knowledgeable in password storage and are interested enough in Bitcoin to have read about that.

The difference between bugs in non-crypto software and bugs in crypto software is that bugs in crypto software can have much more severe and far-reaching consequences. So, while I might trust a programmer to write decent non-crypto software, I would prefer not to trust them with writing crypto software.

edit: actually, there's more to it than that, on second thought. Crypto also requires a greater depth and breadth of expertise. The math knowledge required for general programming is trivial by comparison; about the worst it usually gets is vector-based math, or simple calculus, or big-O notation. But to understand crypto well enough to implement it correctly requires a much greater knowledge of mathematics -- something which most programmers don't have.

> You know what the weaknesses of Javascript-based crypto are, and you know how to implement crypto. In that case, why not do it?

Because I (the rhetorical "I" in this case) know what the weaknesses of JavaScript-based crypto are. :-)

Do you know where the weaknesses of Javascript crypto are? I'm not sure I know all of them, and I know a couple that don't have solutions that don't require browser plugins.

Where has Javascript crypto been done successfully? I'm not aware of any application with a sound use of it. There are a few narrowly-tailored experiments, all of them backed by SSL, that don't have obvious flaws. But the best-known examples, like what Meebo did a few years ago, were deployed despite glaring security flaws.

No, I don't think it can-and-has-been-done.

That looks suspiciously like security theatre: "this adds no actual security, but it will discourage simple attacks."