6 ms·

One the solutions is to start using algorithm cascades instead of single algorithms where performance doesn't matter. If you are using 10 ciphers or 10 hash fu

by devit 11y ago

One the solutions is to start using algorithm cascades instead of single algorithms where performance doesn't matter. If you are using 10 ciphers or 10 hash functions or 10 signature schemes, then you need 10 different breakthroughs before it all falls down. There is really no reason to not do this unless performance is important, and a lot of times performance does not really matter. NOTE: obviously you need to this properly and use a different key for each cipher, concatenate hashes, concatenate signatures and so on. Also, you should start encrypting with the best implemented ciphers, so that plaintext is not leaked if the worst ciphers happen to have timing/cache vulnerabilities.

stcredzero 11y ago
Then you're creating an unwieldy situation where analysis is very difficult. That's just an advanced form of security by obscurity. What you're saying is, that it's better to go in blind, wearing lots of armor and padding. That strategy works if your enemies don't have anything more potent than a knife. It absolutely doesn't work if they have guns and explosives. Better to clearly know what you're up against.
- ocdtrekkie 11y ago
  I doubt devit was suggesting we stop analyzing the individual methods. If we (and to use a really stupid simple example on largely insecure functions because I'm a simpleton) hash something with... sha1(md5(things)) We can both study the relative security of sha1() and md5() separately, but also know that using both means that an attacker must defeat both methods. This isn't security by obscurity so much as security insurance. If either sha1() or md5() is compromised, the data is still protected by the other. Similarly, if we use ten different encryption methods on top of each other... we know a few things: - If we're studying all of those methods for flaws, the initial challenge of beating it is defeating all ten methods. - If a method is found to be compromised, our data is still protected by nine other methods. - At the very least, we've made brute forcing this a pain in the rear, because nine of those ten layers' output is probably really hard to tell are correct. If you have a crypto 'stack' of ten methods, and you find one is now easy to compromise, you can napkin math realize you've lost one layer of protection, so when a zero day happens on one method, you don't have to panic and assume all of your data is compromised. But your goal remains to ensure as many of those individual layers work against 'guns and explosives'.
  - nhaehnle 11y ago
    Your post is a good example for why cascades are so dangerous. hash1(hash2(...)) is not as secure as the stronger of the hash functions, it may only be as secure as the weaker of the hash functions. Your example is sha1(md5(...)). Well, md5 is no longer considered collision-resistant, which means that sha1(md5(...)) also isn't collision-resistant. If you're able to obtain two different inputs that are mapped to the same hash by md5, computing the sha1 of that hash is still going to lead to the same value, i.e. a collision overall. So your assumption that an attacker must defeat both is clearly wrong and dangerous. In the case of hash functions, I believe it would be safe two concatenate the hashes (instead of composing the functions), but now you have a bigger hash size in addition to a slower running time.
    - richardwhiuk 11y ago
      I'm not convinced that concatenating hashes is safer than a single hash function either. Let's say you have an entirely broken hash function for which hash(A) = A. Clearly if you cocatenate hash(A) + sha256(A), you still end up with something is broken. I think if you concatenate the hash function, you may well end up with something which is strictly worse than using either hash function (as breaking one will break both). Also, if you have the result of both hash functions, then you may have provided data which warps the probability chart, as you now have much more information on the output state of the data, which isn't combined in a clearly useful way. Their might be a way to combine two hashes in a way which does preserve the properties of a hash function, but I think it would be significantly tricky that you would have essentially created a new hash function using other hash functions as building blocks. (That might be good grounds for generating a hash function resistant to attack - combine multiple different styles of hashing, but it doesn't seem to be common when hash functions are designed which suggest to me there are fundamental problems. (e.g. most hash functions repeat the same functional blocks, rather than having a large selection of different blocks).)
      - leni536 11y ago
        > Clearly if you cocatenate hash(A) + sha256(A), you still end up with something is broken. Now it could depend on your treat model. You want to hash passwords (A is secret)? If yes, then this is broken. You want an integrity check / tamper resistance on A, but A is public (see git)? Then this could be fine. Correct me if I'm wrong.
duskwuff 11y ago
> There is really no reason to not do this unless performance is important... There are very few situations where performance is not important in cryptography, and those situations do not, generally speaking, have sufficiently unusual security requirements that it would make sense to use a completely different set of crypto primitives for them.
- baby 11y ago
  > There are very few situations where performance is not important in cryptography source?
tptacek 11y ago
Since cryptosystems designed by experts virtually never use cipher cascades, having one is a pretty good indicator that your system hasn't been designed by an expert. More importantly: Guttman's argument isn't that it's unsafe that we have this "monoculture" (how would that work? DJB turns evil and reveals the secret trapdoor in Curve25519?) --- it's that it's sad that things ended up this way.
- derefr 11y ago
  > how would that work? I can imagine a hypothetical world where DJB creates three crypto building-blocks, gets hailed as the next coming of Alan Turing, and then we don't do nearly the fact-checking we should when he creates a fourth, and it ends up having a horrible flaw. That seems to be half of what this article is warning against: a blind optimistic trust that anything that DJB creates in the future will be perfect. It's not that he's an infallible god of cryptography; it's that everyone else is making obvious mistakes, and he at least has eyes.
  - tptacek 11y ago
    I've heard that from some other people too. But look at the CFRG curve selection debate. There were very few appeals to Bernsteininess in that debate; it was pretty rigorous. To the extent DJB's brand played a part, it seemed to be a liability.
  - habitue 11y ago
    If you look at backdoored algorithms, there are red flags all over the place. A hallmark of DJB algorithms is that they use minimal constants that satisfy publicly declared constraints. If you look at the spec for DUAL_EC_DRBG, the backdoored rng standard, the first thing that you notice is that the constants have no explanation for how they were derived, and that they are large enough to hide a cryptographic key in. If DJB releases a crypto algorithm with huge glaringly unexplained constants, you'd better believe people will ask questions. I don't think it's possible to both use "nothing up your sleeve numbers"[1] and to backdoor an algorithm. You'd likely need the computing power needed to brute force the EC in the first place in order to do it. [1] https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number
woodman 11y ago
> ...concatenate hashes... Bad idea, using 10 128-bit hash functions instead of a single 1280-bit hash function. Instead of a single post hash view of the hidden data - you've given an attacker 10 different perspectives. Instead of studying and securing one function - you now have to secure 10 functions and study their interaction in 10 dimensions... If 1 in 10 of your functions is broken, the damage isn't limited to a 10% reduction in keyspace. > ...start encrypting with the best implemented ciphers... If that is known up front then the whole exercise is pointless. You can't know that because you can't see into the future.
- devit 11y ago
  Yes, that's true. Encrypting the data before hashing with a secret key solves this issue if applicable. > You can't know that because you can't see into the future. The "best cipher" is the single one you would have used if you had not decided to use a cipher cascade. The idea is to make sure that your cascade is never worse than that single cipher.
jstarks 11y ago
Performance is always important. That's really been the main point of DJB's work -- crypto isn't widely used because it is too slow, so let's build fast crypto.

by devit 11y ago

stcredzero 11y ago

Then you're creating an unwieldy situation where analysis is very difficult. That's just an advanced form of security by obscurity. What you're saying is, that it's better to go in blind, wearing lots of armor and padding. That strategy works if your enemies don't have anything more potent than a knife. It absolutely doesn't work if they have guns and explosives. Better to clearly know what you're up against.

ocdtrekkie 11y ago
I doubt devit was suggesting we stop analyzing the individual methods. If we (and to use a really stupid simple example on largely insecure functions because I'm a simpleton) hash something with... sha1(md5(things)) We can both study the relative security of sha1() and md5() separately, but also know that using both means that an attacker must defeat both methods. This isn't security by obscurity so much as security insurance. If either sha1() or md5() is compromised, the data is still protected by the other. Similarly, if we use ten different encryption methods on top of each other... we know a few things: - If we're studying all of those methods for flaws, the initial challenge of beating it is defeating all ten methods. - If a method is found to be compromised, our data is still protected by nine other methods. - At the very least, we've made brute forcing this a pain in the rear, because nine of those ten layers' output is probably really hard to tell are correct. If you have a crypto 'stack' of ten methods, and you find one is now easy to compromise, you can napkin math realize you've lost one layer of protection, so when a zero day happens on one method, you don't have to panic and assume all of your data is compromised. But your goal remains to ensure as many of those individual layers work against 'guns and explosives'.
- nhaehnle 11y ago
  Your post is a good example for why cascades are so dangerous. hash1(hash2(...)) is not as secure as the stronger of the hash functions, it may only be as secure as the weaker of the hash functions. Your example is sha1(md5(...)). Well, md5 is no longer considered collision-resistant, which means that sha1(md5(...)) also isn't collision-resistant. If you're able to obtain two different inputs that are mapped to the same hash by md5, computing the sha1 of that hash is still going to lead to the same value, i.e. a collision overall. So your assumption that an attacker must defeat both is clearly wrong and dangerous. In the case of hash functions, I believe it would be safe two concatenate the hashes (instead of composing the functions), but now you have a bigger hash size in addition to a slower running time.
  - richardwhiuk 11y ago
    I'm not convinced that concatenating hashes is safer than a single hash function either. Let's say you have an entirely broken hash function for which hash(A) = A. Clearly if you cocatenate hash(A) + sha256(A), you still end up with something is broken. I think if you concatenate the hash function, you may well end up with something which is strictly worse than using either hash function (as breaking one will break both). Also, if you have the result of both hash functions, then you may have provided data which warps the probability chart, as you now have much more information on the output state of the data, which isn't combined in a clearly useful way. Their might be a way to combine two hashes in a way which does preserve the properties of a hash function, but I think it would be significantly tricky that you would have essentially created a new hash function using other hash functions as building blocks. (That might be good grounds for generating a hash function resistant to attack - combine multiple different styles of hashing, but it doesn't seem to be common when hash functions are designed which suggest to me there are fundamental problems. (e.g. most hash functions repeat the same functional blocks, rather than having a large selection of different blocks).)
    - leni536 11y ago
      > Clearly if you cocatenate hash(A) + sha256(A), you still end up with something is broken. Now it could depend on your treat model. You want to hash passwords (A is secret)? If yes, then this is broken. You want an integrity check / tamper resistance on A, but A is public (see git)? Then this could be fine. Correct me if I'm wrong.

duskwuff 11y ago

> There is really no reason to not do this unless performance is important... There are very few situations where performance is not important in cryptography, and those situations do not, generally speaking, have sufficiently unusual security requirements that it would make sense to use a completely different set of crypto primitives for them.

baby 11y ago
> There are very few situations where performance is not important in cryptography source?

tptacek 11y ago

Since cryptosystems designed by experts virtually never use cipher cascades, having one is a pretty good indicator that your system hasn't been designed by an expert. More importantly: Guttman's argument isn't that it's unsafe that we have this "monoculture" (how would that work? DJB turns evil and reveals the secret trapdoor in Curve25519?) --- it's that it's sad that things ended up this way.

derefr 11y ago
> how would that work? I can imagine a hypothetical world where DJB creates three crypto building-blocks, gets hailed as the next coming of Alan Turing, and then we don't do nearly the fact-checking we should when he creates a fourth, and it ends up having a horrible flaw. That seems to be half of what this article is warning against: a blind optimistic trust that anything that DJB creates in the future will be perfect. It's not that he's an infallible god of cryptography; it's that everyone else is making obvious mistakes, and he at least has eyes.
- tptacek 11y ago
  I've heard that from some other people too. But look at the CFRG curve selection debate. There were very few appeals to Bernsteininess in that debate; it was pretty rigorous. To the extent DJB's brand played a part, it seemed to be a liability.
- habitue 11y ago
  If you look at backdoored algorithms, there are red flags all over the place. A hallmark of DJB algorithms is that they use minimal constants that satisfy publicly declared constraints. If you look at the spec for DUAL_EC_DRBG, the backdoored rng standard, the first thing that you notice is that the constants have no explanation for how they were derived, and that they are large enough to hide a cryptographic key in. If DJB releases a crypto algorithm with huge glaringly unexplained constants, you'd better believe people will ask questions. I don't think it's possible to both use "nothing up your sleeve numbers"[1] and to backdoor an algorithm. You'd likely need the computing power needed to brute force the EC in the first place in order to do it. [1] https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number

woodman 11y ago

> ...concatenate hashes... Bad idea, using 10 128-bit hash functions instead of a single 1280-bit hash function. Instead of a single post hash view of the hidden data - you've given an attacker 10 different perspectives. Instead of studying and securing one function - you now have to secure 10 functions and study their interaction in 10 dimensions... If 1 in 10 of your functions is broken, the damage isn't limited to a 10% reduction in keyspace. > ...start encrypting with the best implemented ciphers... If that is known up front then the whole exercise is pointless. You can't know that because you can't see into the future.

devit 11y ago
Yes, that's true. Encrypting the data before hashing with a secret key solves this issue if applicable. > You can't know that because you can't see into the future. The "best cipher" is the single one you would have used if you had not decided to use a cipher cascade. The idea is to make sure that your cascade is never worse than that single cipher.

jstarks 11y ago

Performance is always important. That's really been the main point of DJB's work -- crypto isn't widely used because it is too slow, so let's build fast crypto.