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
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
