5

I've read here that hashing with differents algorithms would be a good idea.

Can you confirm that?

In your experience, is it useful and safe? Does it entail any security holes?

Surfer on the fall
  • 787
  • 3
  • 8
  • 17
  • 3
    People writing about security issues mixing up encryption and hashing always makes me a bit skeptical. – Jacco Sep 07 '12 at 13:10
  • @Jacco you're right.. he describes himself as a security consultant .... but after all, is cascade hashing a smart beahvior? – Surfer on the fall Sep 07 '12 at 13:15
  • I'm no crypto expert, but I've learned enough to be afraid of subtle aggregation problems that pop up when combining multiple tricks. A good hash will maintain all of the properties it needs, and there should be no need to use it as in input to another hash. I'd use SHA-512, it is NIST-approved, it has an adjustable number of rounds, the default number of rounds is 5000, and the salt is 16 bytes. It is sufficiently slow when trying to crack it. JtR gives me about 1200 keys/sec on a 4-core 3.2GHz i7. – Marcin Sep 07 '12 at 14:43
  • Possible duplicate: http://security.stackexchange.com/questions/8940/are-different-hash-algorithms-ever-used-together. See also: http://crypto.stackexchange.com/questions/270/guarding-against-cryptanalytic-breakthroughs-combining-multiple-hash-functions – Andrei Botalov Sep 07 '12 at 16:09
  • I've wavered a bit on closing this... I think perhaps discussion of the fact that breaking the **weaker** of the two will yield the attacker with the password could be much clearer here than in the other duplicate question since bCrypt and sCrypt are designed for passwords. That said, the linked questions above are very relevant. – Jeff Ferland Sep 07 '12 at 16:57
  • 1
    @Marcin The question seems to be talking about password hashing (since they mention bcrypt and scrypt), in which case SHA-512 isn't good enough. Also, SHA-512 has exactly 80 rounds (not adjustable), and doesn't handle salting. Maybe you mean PBKDF2 with SHA-512? – Brendan Long Sep 07 '12 at 17:03
  • 3
    @Marcin The problem with PBKDF2 isn't the cracker performance on a CPU. It's no worse than the other schemes in that regard. The problem is that on GPUs or even worse, specialized hardware PBKDF2 is much weaker than scrypt, and somewhat weaker than bcrypt. I expect a 10 times speedup on a GPU, and a lot more with specialized hardware. – CodesInChaos Sep 07 '12 at 17:08

2 Answers2

9

Generally speaking, cascading algorithms is rarely a good idea. Cascading works very well at making software more complex and less responsive, which is hardly desirable. The usual "justification" of cascading is that it should somehow (possibly magically) resist complete breakage of one of the algorithm, but not of the other. In practice, this is not so, for several reasons:

  • There are several ways to "cascade" and they do not do the same thing. For instance, if you have hash functions f and g, and you want to protect against preimages, then cascading as f(g(x)) might work; but if you want to protect against collisions, that's f(x)||g(x) which makes sense (i.e. concatenation, not composition). People who request cascading rarely think about what they actually want with sufficient depth in that respect.

  • Let's face it, this is not 1938 anymore. The algorithm itself is never the weak point; what's weak is how it is (mis)used. Cascading is like looking at a steel door on a wood cabin, and claiming that it should have an extra, heavy padlock in addition. It is a great and time-honoured way to avoid dealing with real security issues.

  • In the specific case of password hashing, there is one glaring weakness, which is the password itself: passwords are guessable. So we want slow hash functions, and we defeat the attacker by putting more CPU into it ourselves (i.e. we increase the number of iterations, so that the hash is as expensive as possible; the attacker's advantage becomes how much more CPU he can muster when compared to the honest server). The server's CPU is his line of defense. Cascading means wasting precisely that lifeforce, just for the fuzzy feeling that it will make things more resistant to fabled cryptanalytic breaks.

So no, don't cascade. At best, it will just make your life harder. More often, it will more or less directly decrease security.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
3

Seeing that I wrote that blog post I thought I would chime in. First, let me explain that it was a quick 5-minute writeup so it was not some well-analyzed theory, more of an off-the cuff comment. I wrote it because I had seen several discussions at the time arguing which specific algorithm was best.

The original point was, rather than argue which one is better, just use both and be done with it.

Since writing that, I have done considerable more research in the area and clearly I had overstated the benefits. Simply doing something like sha256(blowfish(data)) is not as resistant to attack as it sounds. There are ways to pull it off but doing it correctly takes some solid understanding of cryptography, there are some tradeoffs, and it would be too easy to mess up. It's highly unlikely that you would make it less secure, but the gains are minimal for the most likely attacks.

That post of mine perfectly illustrates how hard it is to do cryptography correctly and how you should take great care in how you implement it. The concept of combining algorithms sounds perfectly logical but when you sit down and properly analyze it, the results are not as great as expected, or in some cases, could even be worse.

Mark Burnett
  • 2,810
  • 13
  • 16