PBKDF2 and bcrypt are configured with an "iteration count", which means that they can be made as slow as you want. Therefore, there cannot be a table which shows how fast they go. What you need to do, instead, is to decide how much time you allocate to the function (e.g. you want it to take 0.05 seconds on your server) and then set the iteration count accordingly. This very much depends on the computing abilities of your server, so this is a matter of measure on your target hardware.
For the other functions, you can find an awful lot of data on this site for performance measures of many hash functions on a lot of platforms (although all these platforms tend to be servers, desktop systems, or at worst smartphones -- smaller embedded systems are not covered). The high-level picture is that:
- Performance depends a lot on the hardware.
- Performance depends a lot on the implementation.
- All currently defined hash functions are way too fast to be adequate for password hashing by themselves; you need some kind of slowdown through thousands or millions of iterations.
While PBKDF2 adds iterations properly, it can still be made much faster in the context of a parallel attack, by using a GPU; therefore, you may prefer to use a function which is GPU-unfriendly, and, right now, this means bcrypt (scrypt being a nice candidate, when it becomes old enough to be trusted). See this answer for details.
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes;
– Shubham Chaudhary Jan 04 '18 at 06:46md5 32526.28k 94598.98k 207205.21k 297106.77k 338960.38k; sha1 36823.75k 104859.48k 228837.80k 324861.43k 367695.19k; sha256 32061.67k 71195.82k 123225.51k 150144.34k 160303.79k;