> Two layers is at least as secure as a single one of either layer.

This is not uniformly true for cryptosystems--it is not naively the case that P(Q(X)) is a secure form of encryption, just because P/Q is. A contrived example is when P and Q are inverses (so P(Q(X)) is plaintext), but it should be obvious that if P has the wrong interaction with Q it might make some of the message easier to attack.

> The question is whether it will hurt, and the answer is that it does not. Again, this is common sense.

It can hurt. It's subtle, but consider if a hash in the middle has a distribution issue (extreme case--hash in the middle maps everything to 0, now your entire hash stack is broken). In short: stacked hashes are no stronger than the first hash in the sequence (collision there = collision in the stacked algorithm) and have the potential to be weaker.

> This is not uniformly true for cryptosystems--it is not naively the case that P(Q(X)) is a secure form of encryption, just because P/Q is. A contrived example is when P and Q are inverses

If P and Q are inverses, then Q is not secure, because you could just apply P to its output.

The same holds true for encryption: if you have two independant keys K1 and K2, then if Mallory can crack P(Q(X, K2), K1), then she can crack Q(X, K2) just by picking a K1 at random and computing P(Q(X, K2), K1).

> A contrived example is when P and Q are inverses

I feel like you should already realize this (in which case I don't get why you're posting the comment), but while that's a cute mathematical existence proof, it's totally irrelevant as it's not something that can just happen out of the blue. Ciphertext looks random; you can't just reverse randomness without having the key/seed. So that's impossible in practice unless you've either somehow (a) broken the crypto, or (b) used related keys for both algorithms (which is obviously stupid and not something you would do if you thought about this for 5 seconds) or (c) something else silly along those lines, all of which even rudimentary knowledge of cryptography (or one might even argue, common sense) would prevent.

> It can hurt. It's subtle, but consider if a hash in the middle has a distribution issue

I don't know when you read my comment, but I edited it (I think) some ~15 minutes before you posted your comment to clarify that I wasn't referring to stacking arbitrary hashes. Read it again. I was referring to stacking hashes that are already thought to be cryptographically secure.

> I don't know when you read my comment, but I edited it (I think) some ~15 minutes before you posted your comment to clarify that I wasn't referring to stacking arbitrary hashes. Read it again. I was referring to stacking hashes that are already thought to be cryptographically secure.

It still doesn't make a difference in my argument. My point is that you gain no added strength via a stacked hash implementation because it's as weak as the first hash in the sequence, and that it is potentially worse because you can also attack it via attacks on later hashes in the sequence.

A stacked hash is as weak as the first hash in the sequence--this should be obvious. A collision in the first hash function will obviously cascade into all later ones, so your stacked hash function is as weak, or strong, as the first hash function. That means you gain no strength.

What I was showing via an obvious/contrived example (to keep the math easy) was that it is also possible to attack a stacked hash via weaknesses in later hashes in the sequence. I wasn't (I thought obviously) implying that you'd intentionally choose a hash that was weak for a middle one--but there are all sorts of hashes we once thought were secure that we don't think are secure anymore.

> I feel like you should already realize this (in which case I don't get why you're posting the comment), but while that's a cute mathematical existence proof, it's totally irrelevant as it's not something that can just happen out of the blue.

Fundamentally, all modern crypto relies heavily on math. I made a "cute mathematical existence proof" to make it obvious how stacking ciphers can weaken an encryption system. The reality is that exactly how ciphers interact is a subtle and hard to measure point, but it isn't safe to assume that composing cryptosystems will be as secure as either cryptosystem on its own, because features of the two systems could interact to weaken the overall security of the cryptosystem.

> It still doesn't make a difference in my argument. My point is that you gain no added strength via a stacked hash implementation because it's as weak as the first hash in the sequence

God, I wish really I could downvote replies.

Nobody said you should be applying the hash functions in sequence. There are at last 3 obvious approaches: (1) applying the functions sequentially, (2) concatenating their outputs, (3) XORing their outputs. None of these takes rocket science to figure out, and some 5 seconds of thinking would easily rule out #1 and #2 as inferior to #3.

Honest question: did you even spend 5 seconds actually thinking about what I wrote before deciding I must be wrong? I'm not sure if you realize this, but when you reply so confidently without thinking, you (and many others) active harm the whole field of infosec. I'm so frustrated and fed up with you and so many other people's overconfidence and lack of willingness to think for 5 seconds when it comes to cryptography.

>> I feel like you should already realize this (in which case I don't get why you're posting the comment), but while that's a cute mathematical existence proof, it's totally irrelevant as it's not something that can just happen out of the blue.

> Fundamentally, all modern crypto relies heavily on math. I made a "cute mathematical existence proof" to make it obvious how stacking ciphers can weaken an encryption system

Again: are you reading and thinking? Or are you just writing?

You're simultaneously literally claiming that two secure ciphers can be combined to result in an insecure cipher when their keys are generated independently. This is far more astonishing than the claim that the ciphers you're using are actually secure in the first place. You're already accepting the latter despite any sort of proof, yet you're bothered by the former? Hell, you haven't even shown shown this is possible for any pair of secure ciphers; your "example" was missing the most crucial part of the cipher -- the key. The whole argument is so crazy it's just utterly ridiculous.

> here are at last 3 obvious approaches: (1) applying the functions sequentially, (2) concatenating their outputs, (3) XORing their outputs. None of these takes rocket science to figure out, and some 5 seconds of thinking would easily rule out #1 and #2 as inferior to #3.

This is wrong. Concatenation would be harder to attack than XOR. Finding two things which hash to to two particular values in two separate hash functions is necessarily harder than finding two things which will hash to values which will XOR to the same value--almost a priori. You replace a double collision (across two hashes) which is very unlikely with an XOR collision, which is going to be exponentially easier.

> You're simultaneously literally claiming that two secure ciphers can be combined to result in an insecure cipher when their keys are generated independently. This is far more astonishing than the claim that the ciphers you're using are actually secure in the first place.

Since you seem to want practical examples on recent crypto: consider meet in the middle attacks on 2DES as an example of why combined cryptosystems are not necessarily as strong as you'd imagine. It's admittedly a weak example--still stronger than 1DES, and an old system. Fundamentally, combining cryptosystems, even with separate keys, gives you a new cryptosystem which requires separate analysis.

> Hell, you haven't even shown shown this is possible for any pair of secure ciphers; your "example" was missing the most crucial part of the cipher -- the key. The whole argument is so crazy it's just utterly ridiculous.

If I had a good attack on RSA + ECC, I'd be writing a paper about it. I'm gonna posit that if that's the kind of proof you want to believe you're "wrong", you'll remain happily "correct" in this scenario.

> This is wrong. Concatenation would be harder to attack than XOR. Finding two things which hash to to two particular values in two separate hash functions is necessarily harder than finding two things which will hash to values which will XOR to the same value

No, you're the one who's wrong. You're assuming the hash is secure and then trying to brute-force it. But the entire discussion is not about brute force; it's about when an adversary breaks the hash, i.e. one who is able to produce multiple inputs with the same hash much more quickly than with brute force. This means they can attack the hashes independently, whereas if you XOR, they can't do that. Heck, if you XOR, the probability that they'll be able to tell which algorithms you used already becomes astronomically low, let alone them breaking it.

> Since you seem to want practical examples on recent crypto: consider meet in the middle attacks on 2DES as an example of why combined cryptosystems are not necessarily as strong as you'd imagine.

Again, you're wrong. You said you were "making it obvious how stacking ciphers can WEAKEN an encryption system". All you proved is that it isn't twice as strong. I never claimed nor even imagined that it was twice as strong. I merely claimed that the probability of it being WEAKER is astonishingly lower than the probability of the crypto layers being strong in the first place. Why do you keep changing your arguments?

>> Hell, you haven't even shown shown this is possible for any pair of secure ciphers; your "example" was missing the most crucial part of the cipher -- the key. The whole argument is so crazy it's just utterly ridiculous.

> If I had a good attack on RSA + ECC, I'd be writing a paper about it. I'm gonna posit that if that's the kind of proof you want to believe you're "wrong", you'll remain happily "correct" in this scenario.

Way to keep changing the topic just to win the argument. I just pointed out that your counterexample ciphers didn't even have independent keys, for God's sake!! Instead of accepting that you made silly mistake, you're spreading meaningless FUD. Why can't you just accept you made an error instead of giving me this nonsense? Are you just a troll? If you keep trolling don't expect me to respond.

If you have a combined hash that is XYZ = weak_hash(m) XOR strong_hash(m), then you still have a birthday collision attack available. Just keep permutating the message in various ways, and in 2^(hash length / 2) operations you have two identical hashes with different inputs.

Edit: yes, this isn't new, but it is strictly weaker than to append the two hashes. It increases the difficulty as you have two hard targets you must hit with the same input, vs one target, which may even be weakened.

You're also assuming the hashes are fully uncorrelated. If the designs are similar, there could be a correlation between the two which biases the output, such that some bits often will be the same or different in certain ways. This can drastically reduce the number of possible outputs in known ways, and could even enable cryptanalysis to break it faster than bruteforce if part of the weaker hash counteracts parts of the other.

You also forgot timing attacks and other sidechannels in layered encryption.

> If you have a combined hash that is XYZ = weak_hash(m) XOR strong_hash(m), then you still have a birthday collision attack available. Just keep permutating the message in various ways, and in 2^(hash length / 2) operations you have two identical hashes with different inputs.

You understand what "good enough" means, right? Brute force is irrelevant if your hashes are long enough (e.g. say, 256 bits). Again, like the other guy, you're confused: we're trying to guard against broken hashes, not brute force attacks. Brute force attacks are trivial to guard against just by changing the length.

> Edit: yes, this isn't new, but it is strictly weaker than to append the two hashes. It increases the difficulty as you have two hard targets you must hit with the same input, vs one target, which may even be weakened.

I thought I already explained this, but I'll explain it again. For a brute force attack, sure, it's weaker. But like I said, that's already trivial to guard against already, so that's irrelevant. For a broken hash, it's MUCH STRONGER, since in the concatenation case, both hashes can leak information about the input (meaning breaking one can help break the other), whereas in this case it's the opposite: the adversary won't get any information about the input unless he breaks both hashes simultaneously.

You're thinking about the problem wrong.

> You also forgot timing attacks and other sidechannels in layered encryption.

Somebody already mentioned this in another comment chain. I initially thought of it but then forgot it, yeah. But it's just something to watch out for, not an argument for not doing it in the first place. It's also trivial to guard against if you apply a standard layer first (which doesn't preclude applying another standard one last, and putting your own layer in between).

Common sense is not so common. I would certainly find it very useful if the cryptographic community developed best practices for how to stack algorithms.

> Common sense is not so common. I would certainly find it very useful if the cryptographic community developed best practices for how to stack algorithms.

Here's the list of best practices for encryption:

1. Have at least one well-established & accepted cipher (e.g. AES).

2. Generate the keys for all the layers independently.

Source: my (apparently un-)common sense.

There are more points to consider than that. For instance, which order should you apply the ciphers in?

> There are more points to consider than that. For instance, which order should you apply the ciphers in?

No. The order shouldn't make any difference unless for some reason you're sending extra data in cleartext that is encrypted with one cipher but not the other. This is because the output of the standard cipher (e.g. AES) would look random, so that implies the final output must look random, and hence they won't be able to tell there's another layer on top just based on the order of the ciphers. That is, unless they've already broken the other standard cipher (in which case now you're only dealing with the custom layer regardless). If the final output isn't random, it means you're partially reversing the standard crypto, which, as I said above, cannot happen unless you've broken the crypto or avoided using independent keys.

Edit: I suppose the theoretically optimal thing to do may be to apply the standard cipher last, to absolutely, positively ensure that the adversary is forced to break that before they even know you have another layer underneath (to avoid parallelizability of breaking both). I can't imagine this ever being worse. But at this point we're talking about theoretical optimality; from a practical standpoint I don't see this mattering. But at the same time since I don't have an argument for doing it the other way, you might as well always do it this way.

I would suggest the standard cipher first. Because, if the home brewed one is used first, it may leak information over side channels.

Another concern is that if the home made cipher creates a cipher text with differing lengths depending on the content of the plain text, the standard cipher will not be able to obscure that length.

> I would suggest the standard cipher first. Because, if the home brewed one is used first, it may leak information over side channels.

Ahh! I remember realizing this once but then I completely forgot about it. It's a good point, thanks for mentioning it. The thing to note here though is that the only side-channel attack here is the time taken for the encryption to occur, since we're talking about networks (and not physical penetration of the system's environment)... which is admittedly nontrivial to defend against with modern CPUs, but which is not quite as hard to do as it might seem, if by side channel people think of the same thing I normally do (e.g. E/M waves from the monitor or something).

So maybe apply a standard layer initially, add your custom layers, then top it off with another standard layer?

> Another concern is that if the home made cipher creates a cipher text with differing lengths depending on the content of the plain text

I guess I assumed it was obvious you would never do this because it's common sense if you know even basic cryptography, and as far as I know, this is literally the only possible failure mode with regards to information leakage in the ciphertext itself, so it's not like you have to worry about other similar situations either. (But do correct me if I'm wrong.)

The odds that your homegrown function is an inverse to the dank-dispensary-function you've layered below it are as low as somebody cracking dank-func without insider knowledge. Dank-func would be worthless in all situations if it were the case.

Unless state-actor is willing to spend time decrypting homegrown-func, you have succeeded.

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

That's a joke in regards to @Taek, but it could very well be. It must be a lot easier for NSA and all other intelligence agencies when everybody uses the same crypto tech.

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