Is there any comparison of bcrypt versus scrypt? I am particularly interested in how bcrypt(10) bcrypt(20) or even bcrypt(30) scales in comparison to scrypt(1)?


1 Answer 1


Comparison is complex because scrypt and bcrypt don't play on the same parameters.

For bcrypt, the computation involves doing a lot of operations over a 4 kB array of RAM. The array is accessed in a pseudorandom way, so the only way to make this run at a decent speed is to have an actual block of RAM of at least that size. This is true for normal CPU, that have (typically) about 32 or 64 kB of very fast RAM (called "level 1 cache"). This is not true of GPU, where there is no per-core fast RAM (there is RAM in a GPU, but it is shared). Good FPGA has embedded fast RAM blocks of a few kilobytes; thus, a sophisticated attacker using FPGA will get an edge over the defender (because the defender uses a PC; that's the central assumption).

With scrypt, the operations are somewhat different, and, in particular, there is a much bigger array of RAM (size if configurable but a typical size would use several megabytes). For a CPU, a bigger RAM needs exercising level 2 cache or even main RAM, which is slower than level 1 cache. However, a PC suffers much less than a FPGA when going to big RAM arrays. So the theory is that the best architecture to attack scrypt is, indeed, a PC, just like the one that the defender use. This brings attacker and defender back to strict equality of means, which is the best that we can hope for.

What matters is not the actual speed of either algorithm, but the relative efficiency of different architectures when implementing the algorithm. A password hashing function is "optimal" if the best architecture to crack passwords (the hardware which will allow the highest number of tried passwords per second, for a given budget) is what the defender has to use, i.e., basically, a PC. Therefore, comparing bcrypt with scrypt means trying to measure how well either of them fulfils that ideal characteristic. For instance, with bcrypt, we know that 10000$ worth of FPGA allow for more cracking performance than 10000$ of PC.

We can put figures on these, but these will be extremely sensitive to a lot of architectural and economic parameters. Every year, availability of new hardware, and evolution of hardware prices, considerably alter any figure you could have gathered. Moreover, the RAM size and time budget of scrypt also modify the picture. The original scrypt article uses assumptions which are not necessarily realistic (e.g. that a normal user accepts a 5-second delay for login, and that a busy server has no more than a dozen login attempts per minute); moreover, the estimates were done for 2009 hardware -- what kind of silex did they use at that time ?

Summary: I don't have any reference to any recent comparison, but for the reasons explain above, I can claim that, with high probability, any such comparison that you may find will probably be quite meaningless and inapplicable to your own situation.

  • 4
    Scrypt was mainly designed with file encryption in mind (Colin Percival sells an encrypted backup solution). Taking a couple of seconds to mount a volume or decrypt a backup should be acceptable. Securing password hashes for login is more of an afterthought. Jan 22, 2014 at 23:15
  • An attacker could build a static-RAM-only system more cheaply than a defender could add cache. I would think a better way to equalize attacker and defender would be to have the defender buy a decent GPU and have an algorithm that can use it, since a commodity GPU can offer more bang for the buck with operations it's good for than FPGAs.
    – supercat
    Jul 13, 2015 at 22:28

You must log in to answer this question.

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