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?

  • 3
    People writing about security issues mixing up encryption and hashing always makes me a bit skeptical.
    – Jacco
    Sep 7, 2012 at 13:10
  • @Jacco you're right.. he describes himself as a security consultant .... but after all, is cascade hashing a smart beahvior? Sep 7, 2012 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 7, 2012 at 14:43
  • 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? Sep 7, 2012 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. Sep 7, 2012 at 17:08

2 Answers 2


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.


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.

  • would it be possible to share the link to your article/blog/post that you're referring in the answer.
    – iam.Carrot
    Nov 22, 2021 at 6:17

Not the answer you're looking for? Browse other questions tagged .