Hacker News Reader

Comment by jamestimmins | Hacker News Reader

This is awesome. It was fun to see where my intuition was way off. Had no idea indexing/not-indexing a column would make a 25,000x difference (makes sense though as logN on a 10-million row table is 13, which is a lot less than a linear scan).

Was also very surprised to see how slow Bcrypt is.

edit: Yes, BCrypt, is designed to be slow. I just had no idea how slow. I assumed it was 100-1000 times faster than it is/can be.

View on HN

> Was also very surprised to see how slow Bcrypt is.

Though unlike all the other examples here, this one is actually intentional. If/when computers become considerably faster, the cost factor of typical bcrypt implementations will be raised so that it stays slow, to keep it difficult to throw brute-force attacks at it.

For sure, that's an important piece. But when I hear "slow hashing" I assumed it meant 1k-10k times per second, not <10 times per second. That's practically human speed.

“Practically human speed” is exactly what they’re aiming for. It’s meant to be used in human-speed applications, and to be as slow as possible in those use-cases without causing perceptible lag.

The bcrypt example is the only one that's off the mark. "How fast is this function that we've explicitly designed to be arbitrarily slow?" Well, it depends, how slowly did you configure it to run?

Basically the important argument to bcrypt is literally the amount of time you want it to take to run on your hardware (ie the number of rounds).

This one threw me off as well. I didn't see any configuration so I just assumed that it was only 1 iteration by default. After being off by several orders of magnitude, I looked it up and apparently it defaults to 4096 iterations.

Reply on news.ycombinator.com