[cryptography] Oddity in common bcrypt implementation

Marsh Ray marsh at extendedsubset.com
Tue Jun 14 19:23:35 EDT 2011


Also a discussion on this going on at
http://news.ycombinator.com/item?id=2654586

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
>
> ftp://ftp.fr.openbsd.org/pub/OpenBSD/src/lib/libc/crypt/bcrypt.c
>
> with
>
>          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.

- Marsh



More information about the cryptography mailing list