

Crypt_blowfish 8-bit character mishandling - adulau
http://seclists.org/oss-sec/2011/q2/632

======
pilif
_sigh_ \- this happens just as I completed moving my web app to bcrypt and
once enough time has passed for most of the passwords to be converted from my
old salted-md5 method.

Most of the users are German or French speaking, so I'm sure there will be
8bit characters. I wonder whether just forcing them to use the forgot-my-
password function is good enough or whether I will have to do extra work.

Still. Very detailed email and very helpful thread.

~~~
tedunangst
This depends entirely on what bcrypt implementation you use. The ruby gem for
instance uses a version that's not affected (bcrypt.c from openbsd).

------
X-Istence
That man sure knows how to say he is sorry ;-).

This just goes to show that testing more and especially unexpected input is
extremely important. Test driven development is nice, but in general it only
tests for known valid data and what it should return but doesn't include the
tests to verify that the program still behaves as expected when given invalid
data or data that you aren't expecting it to receive.

------
martinp
I think this exact bug was fixed in another implementation of bcrypt [1] over
a year ago.

[1] <http://www.mindrot.org/files/jBCrypt/internat.adv>

------
Revisor
Can someone please help me understand the implications?

Crypt_blowfish handles 8(and higher?)-bit characters wrong on OpenBSD? Are
other *nix systems also affected? Is the wrong character handling consistent?

~~~
dekz
I don't believe Crypt_blowfish == OpenBSD's implementation, they cannot
interoperate as crypt_blowfish has this inconsistency with 8bit chars. You'd
have to look up with distros use it, there are a number listed in his email
but that might not list all affected platforms. I'd be looking into it if I
was using PHP and blowfish.

------
newman314
Anyone know if scrypt is similarly affected?

~~~
dekz
IIRC scrypt uses SHA256 and AES, not this blowfish implementation. So it's
fine.

~~~
dchest
SHA-256 (in PBKDF2) and Salsa20/8 core.

Colin uses uint8_t* everywhere -- I think it's a standard practice in crypto
code to use types that specify their size and signness right in the name and
avoid using char/unsigned char directly.

Plus, scrypt doesn't do any encoding -- it's user's responsibility to
serialize raw bytes into the suitable format.

