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