6 ms·

Thanks for saying exactly the same thing that's come to my mind over and over again. I would totally roll my own crypto on top of an existing cryptosystem if I

Thanks for saying exactly the same thing that's come to my mind over and over again. I would totally roll my own crypto on top of an existing cryptosystem if I could and if someone with this much computational power was in my threat model. That way I would get the best of both. Same goes for hashing by the way: I'd totally stack multiple hash functions on top of each other too. But in this I'd only stack cryptographic ones that have not yet been broken; I wouldn't roll my own.

Taek 10y ago
You never get the best if you roll your own. The problem is that there are many broad classes of attack that cover wide ranges of knowledge. If OpenSSL can't get TLS right, how do you expect to get your home-rolled crypto right? If you choose to roll your own, you will almost certainly have more vulnerabilities that are easier to find. Your gamble is that agencies like the NSA are already holding vulnerabilities to the common libraries, and that it's more expensive for them to break your weaker crypto (it will be weaker even if you are world class) because they have to take time to break it. Edit: stacking multiple hash functions naively is a bad idea as well. As a thought experiment, let's say that I have a hash function that is effectively (because the NSA broke it) as useful as converting the input to all zeroes. Stacking more hashes on top of that hash won't help you, because it will still be trivial to find collisions.
- wfunction 10y ago
  >> 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.
- cryptarch 10y ago
  What if the "stacking" is simply using multiple hash functions in parallel, i.e. not storing one hash but a bunch of hashes all done with different hash functions? Would that not make finding a collision that works in all hash functions nigh impossible, with the trade-off that you're potentially giving away more information about your input data?
  - stolsvik 10y ago
    Yes, or eor them together, as I mentioned in another branch.
    - cryptarch 10y ago
      What's "eor"?
      - wfunction 10y ago
        Probably "e"xclusive "or"

Taek 10y ago

You never get the best if you roll your own. The problem is that there are many broad classes of attack that cover wide ranges of knowledge. If OpenSSL can't get TLS right, how do you expect to get your home-rolled crypto right? If you choose to roll your own, you will almost certainly have more vulnerabilities that are easier to find. Your gamble is that agencies like the NSA are already holding vulnerabilities to the common libraries, and that it's more expensive for them to break your weaker crypto (it will be weaker even if you are world class) because they have to take time to break it. Edit: stacking multiple hash functions naively is a bad idea as well. As a thought experiment, let's say that I have a hash function that is effectively (because the NSA broke it) as useful as converting the input to all zeroes. Stacking more hashes on top of that hash won't help you, because it will still be trivial to find collisions.

wfunction 10y ago
>> 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.
cryptarch 10y ago
What if the "stacking" is simply using multiple hash functions in parallel, i.e. not storing one hash but a bunch of hashes all done with different hash functions? Would that not make finding a collision that works in all hash functions nigh impossible, with the trade-off that you're potentially giving away more information about your input data?
- stolsvik 10y ago
  Yes, or eor them together, as I mentioned in another branch.
  - cryptarch 10y ago
    What's "eor"?
    - wfunction 10y ago
      Probably "e"xclusive "or"