[cryptography] Oddity in common bcrypt implementation
marsh at extendedsubset.com
Tue Jun 14 19:23:35 EDT 2011
Also a discussion on this going on at
On 06/14/2011 05:50 PM, Jack Lloyd wrote:
> I discovered this a while back when I wrote a bcrypt implementation.
> Unfortunately the only real specification seems to be 'what the
> OpenBSD implementation does'.
That is something of a drawback to bcrypt.
> And the OpenBSD implementation also
> does this trunction, which you can see in
> encode_base64((u_int8_t *) encrypted + strlen(encrypted), ciphertext,
> 4 * BCRYPT_BLOCKS - 1);
> Niels Provos is probably the only reliable source as to why this
> truncation was done though I assume it was some attempt to minimize
> padding bits or reduce the hash size.
That's a pretty weird design decision to use this massive 128 bit salt
but then chop bits off the actual hash value to adjust the length.
The 128 bit salt wastes 4 bits in the base64 encoding (22 chars * 6 bits
per char = 132 bits). The 31 character base64 discards 8 of the 192 bit
output bits (31*6 = 186).
If they'd just used "only" a 126 bit salt they could base64 encode it in
21 chars with no wasted space. That would allow them to store the full
192 bits in 32 chars with no wasted space.
So they threw away 8 hash output bits in order to save 2 salt bits.
More information about the cryptography