On Tue, Jun 28, 2011 at 2:09 PM, Sampo Syreeni <[email protected]> wrote: > On 2011-06-28, Marsh Ray wrote: > >> Yes, but in most actual systems the strings are going to get handled. > > Is this really necessarily true, or just an artifact of how things are > implemented now? Or even a simple-minded implementation. > > Take the case of passwords and usernames. It might make some sense to do a > case-insensitive username comparison. It wouldn't hurt security much, it > might help usability and interoperability, and it constitutes desirable > eye-candy. > > But a case-insensitive password compare?!? For some reason I don't think > anybody would want to go there, and that almost everybody would want the > system to rather fail safe than to do anything but pass around (type-tagged) > bits. I mean, would anybody really like a spell checker in their ATM?
It's not *case* that you want to be insensitive to. It's *form*, specifically Unicode form. Whenever you derive keys from passwords or otherwise use them as inputs to one-way functions you need to put the password into canonical form, which for Unicode means one of NFC, NFD, NFKC, or NFKD, plus some additional mappings. This all relates to things like diacritical marks (accents, etcetera) and such things as variants of periods and whitespace (think of non-breaking space). As Paul H. points out, this is not the right forum to discuss the specifics of Unicode password preparation. So we should stop at noting the fact that ASCII passwords are always canonical while Unicode, non-ASCII passwords require additional preparation in order to be put into canonical form. (This might also be true of other character sets (or codesets), but we should really only concern ourselves with Unicode here.) Nico -- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
