[cryptography] Oddity in common bcrypt implementation

Solar Designer solar at openwall.com
Tue Jun 14 20:50:14 EDT 2011


On Tue, Jun 14, 2011 at 06:50:18PM -0400, Jack Lloyd wrote:
>         encode_base64((u_int8_t *) encrypted + strlen(encrypted), ciphertext,
>             4 * BCRYPT_BLOCKS - 1);

Here's the commit by Niels that fixes the bug in encode_base64() and
replaces it with the explicit "- 1" above:

http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/bcrypt.c.diff?r1=1.11;r2=1.12

That was in 1998.  The commit message not surprisingly says:

"fix base64 encoding, this problem was reported by
Solar Designer <solar at false.com> some time ago."

So it was indeed a deliberate decision not to break compatibility, which
made sense to me.  Who cares if it's 192 or 184 bits, as long as we all
agree on a specific number.  Using base-64 more optimally could be nice,
but not enough of a reason to break compatibility either.

And, by the way, it's not base64, but just a base 64 encoding.  It can
produce any number of characters, not just multiples of 4.  By the way,
it is also subtly incompatible with the base 64 encoding used by other
common crypt(3) implementations... which is not base64 either.

In this posting, I am using base64 (without the dash) to refer to
base64 as in MIME, and base-64 (with the dash) to other base 64 encodings
(which vary).

Alexander



More information about the cryptography mailing list