> I could easily imagine @Taek (working for NSA) reading your comment and shitting his pants, realising you just touched on the holy grail and wanting to put you off the idea of you putting your own custom crypto on top of industry standard because that way they will have a much harder job than right now where everybody uses the same crypto which they are already specialist at breaking (which we don't know now, but in 30 years they will acknowledge it, and acknowledge that they in 2016 had people roam the Internet forums and school developers about how bad homebrewn crypto is because not using homebrewn crypto makes their job a lot easier).

+1 it's funny, I almost feel the same thing myself. I literally have been wondering why otherwise sane people argue against something so blatantly obvious EVERYWHERE I look online. EVERYBODY says don't roll your own crypto and downvotes you to hell if you suggest you're going to do it, yet it's quite obvious that multiple layers of encryption are better than a single one. Sometimes I almost feel like everyone works for the NSA except me or something.

It depends on if only one of the layers leaks information or not. If the custom layer leaks and the other doesn't, the custom layer is making things worse.

When you take the argument that a big problem with roll your own crypto is the tendency for the implementation to be naive to a bunch of ways for information to leak, well, there you go, gluing a competent implementation to an incompetent one compromises the competent implementation.

What we need is a construction that is as secure as the strongest underlying primitive. For instance, for symmetric encryption: Let M be the secret message, C1 the first cypher, C2 the second cypher, K1 and K2 two randomly generated, independent keys. Oh, and a nonce, but let's ignore that for now.

I Think it is easy to prove that C1(K1, C2(K2, M)) is at least as hard to break as either C1(K1, M) or C2(K2, M). Because if one of the cypher is easy to crack, the other can still work.

Hashes are different, because they're not reversible. In this case, a bad hash could indeed project the input space into a smaller output space than expected, and previous or subsequent hashes cannot reverse this mistake.

Hashes: What about xor'ing together hashes from two or more algos? Even if one just hashed to all-1, it wouldn't matter.

Only if the hash algorithms aren't correlated, they should ideally be of different designs.

Dunno. Looks promising.

I did specify that it's a tradeoff. If you are more worried about someone having a cache of exploits on all the popular crypto than you are worried about someone taking the time to break your home crypto, then perhaps you should roll your own.

But understand that the amount of effort required to break home grown crypto in the first place is usually orders of magnitude lower than to break standard crypto in the first place.

By the same token the amount of effort required to break not one but hundreds of thousands even millions of different home grown crypto becomes orders of magnitude higher.

No, you'd just develop automated processes for identifying the most common mistakes. Home-growers would still likely all be using the same building blocks. And making the same classes of mistakes.

The dragnet probably wouldn't be nearly as effective, but the NSA would be far more likely to be able to compromise all priority targets.