[cryptography] Oddity in common bcrypt implementation

Nico Williams nico at cryptonector.com
Mon Jun 20 15:27:48 EDT 2011


On Mon, Jun 20, 2011 at 2:09 PM, Marsh Ray <marsh at extendedsubset.com> wrote:
> There are certainly more bugs lurking where the complex rules of
> international character data "collide" with password hashing. How does a
> password login application work from a UTF-8 terminal (or web page) when the
> host is using a single-byte code page?

It wouldn't.  If you want to use non-ASCII passwords you need a
consistent choice of encoding (and to be able to use some input method
that allows you to input your non-ASCII password correctly
consistently).

Even then you also need a "stringprep" (see RFC3454) and a stringprep
profile suitable for passwords (see SASLprep, RFC4013) because you
need to have consistent normalization (which otherwise would be a
function of the selected input method), for example.  (Well, only if
you want to derive keys from the password; if you're just sending the
password then the other side can do whatever stringprepping or
normalization-insensitive comparisons it likes.)

> I once looked up the Unicode algorithm for some basic "case insensitive"
> string comparison... 40 pages!

Case-insensitivity is full of special cases...  The good news is that
you do want to preserve case in the case of passwords.  It's
normalization that kills you.  (There's also other things to worry
about, such as what to do about unassigned codepoints.)

Anyways, this is a bit far afield.

>> Another is that unsigned integer types should be used more (by default),

Certainly for char!  Is there really any reason to ever use signed chars?

Nico
--



More information about the cryptography mailing list