On Mon, Jun 20, 2011 at 2:09 PM, Marsh Ray <[email protected]> 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 -- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
