password length vs hashing time

1 SETUP.md

Experiment setup

I'm gonna use Ruby since it's the most readily available right now. Combined with Ruby I'm gonna use the bcrypt gem version 3.1.11.

Create the inputs

head -c 100M </dev/urandom > /tmp/100M
head -c 10M </dev/urandom > /tmp/10M
head -c 1M </dev/urandom > /tmp/1M
head -c 100k </dev/urandom > /tmp/100k
head -c 10k </dev/urandom > /tmp/10k
head -c 1k </dev/urandom > /tmp/1k

Run the experiment

1. Open the Rails console
2. Read each file x = File.read("/tmp/1G"); nil (To prevent Rails from messing up your console)
3. Execute the benchmark p Benchmark.measure { BCrypt::Password.create(x) }

Threats to validity (written before the experiment)

1. I'm running this in a Vagrant machine,
2. Executed it only once,
3. Didn't check other libraries, so it might be that slowness in another component dominates the computation time,
4. Never used Benchmark for this kind of things before, so I might miss something here.

Threats to validity (after experiment)

1. Seems to be a bit to constant for me tbh

Results

If and only if these values are accurate (please recheck them yourself!), the time required for BCrypt in Ruby seems to be dominated by something else than length. And in any way, it's still quite performant (only tested the single thread case here though).

Hardware

• 2GB RAM Vagrant machine
• MacBook Pro (Retina, 15-inch, Mid 2015)
• 2,8 GHz Intel Core i7
• 16 GB 1600 MHz DDR3

2 RESULTS.md

Size	Real	Total
1k	0.0542749730000196	0.04999999999999716
10k	0.057278257000007216	0.060000000000002274
100k	0.054528344000004836	0.04999999999999716
1M	0.05409632800001418	0.060000000000002274
10M	0.05627492300004633	0.04999999999999716
100M	0.05555815100001382	0.05000000000000071
"123456"	0.05668177500001548	0.04999999999999716

3 Erratum to results.md

See https://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length

So all in all, this is quite a useless benchmark

Thanks to https://twitter.com/SleeplessByte/status/1025488949299560448 for pointing this out