[cryptography] Oddity in common bcrypt implementation

Marsh Ray marsh at extendedsubset.com
Tue Jun 14 17:52:30 EDT 2011


This guy is wondering why bcrypt test vectors he finds on the web and 
the Python py-bcrypt binding produce 60-byte outputs.

> http://rondam.blogspot.com/2011/06/possible-flaw-in-open-source-bcrypt.html

He quotes this "test vector"
$2a$05$CCCCCCCCCCCCCCCCCCCCC.7uG0VCzI2bS7j6ymqJi9CdcdxiRTWNy

The first 7 chars "$2a$05$" are a configuration string. The subsequent 
53 characters (in theory) contains a 128 bit salt and a 192 bit hash 
value. But 53 is an odd length (literally!) for a base64 string, as 
base64 uses four characters to encode three bytes.

I don't see an official reference for the format of bcrypt hashes. 
There's the Usenix 99 paper, which is a great read in many ways, but 
it's not a rigorous implementation spec.

http://openwall.com/ seems to be a popular source for a C implementation 
of bcrypt. Openwall seems to be getting it from John the Ripper.

I wonder if JtR is simply looking to find a hit and not bothering with 
the last 16 bits?

Solar, did you expect people to use your implementation for validating 
passwords (as well as cracking them) when you wrote it?

- Marsh



More information about the cryptography mailing list