3 ms·

>> I would totally roll my own crypto on top of an existing cryptosystem [...] That way I would get the best of both. > You never get the best if you roll your

>> I would totally roll my own crypto on top of an existing cryptosystem [...] That way I would get the best of both. > You never get the best if you roll your own. Did you even read my comment? I'm not talking about my own crypto on its own, I'm talking about my own crypto on top of an existing one. Two layers is at least as secure as a single one of either layer. It's as simple as that. There's just no argument to be made for your side here. ------------- EDIT: since you added an edit: > stacking multiple hash functions naively is a bad idea as well Really now? Reading on, though, you say: > Stacking more hashes on top of that hash won't help you Oh, I thought you said it's "bad"? Now you're just saying it "won't help". But that's neither a fact, nor the question in the first place. The question is whether it will hurt, and the answer is that it does not. Again, this is common sense. There's no argument to be made for your side against it.

electronvolt 10y ago
> 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.
- wfunction 10y ago
  > 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.
  - im3w1l 10y ago
    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.
    - wfunction 10y ago
      > 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.
      - im3w1l 10y ago
        There are more points to consider than that. For instance, which order should you apply the ciphers in?
        wfunction 10y ago
        > 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.
- progval 10y ago
  > 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).
- bendbro 10y ago
  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.
fredsir 10y ago
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.
- wfunction 10y ago
  > 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.
  - maxerickson 10y ago
    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.

electronvolt 10y ago

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

wfunction 10y ago
> 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.
- im3w1l 10y ago
  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.
  - wfunction 10y ago
    > 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.
    - im3w1l 10y ago
      There are more points to consider than that. For instance, which order should you apply the ciphers in?
      - wfunction 10y ago
        > 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.
progval 10y ago
> 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).
bendbro 10y ago
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.

fredsir 10y ago

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.

wfunction 10y ago
> 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.
- maxerickson 10y ago
  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.