[cryptography] Oddity in common bcrypt implementation
pgut001 at cs.auckland.ac.nz
Wed Jun 29 07:49:13 EDT 2011
"James A. Donald" <jamesd at echeque.com> writes:
>I rather think it is the right forum, for this forum is applied cryptography,
>and application usually requires password handling.
>If we are going to go beyond seven bit ascii, unicode is the only thing that
>is going to avoid compatibility hell.
I realise it's fun to jump in and bikeshed the living daylights out of this,
but before we do that we'd really need to figure out whether the "cure" is
worse than the disease. For example my own code treats a password as an
opaque string of bytes in whatever the local system's character set is. It's
used all over the place, including CJK countries and other places whose
character sets are about as far removed from ASCII as you can get.
So far I've had exactly zero complaints about i18n or c18n-based password
Yup, just counted them again, definitely zero. Turns out that most of the
time when people are entering their passwords to, for example, unlock a
private key, they don't have it spread across multiple totally dissimilar
systems. Now I'm sure I could dream up all manner of pathological corner
cases where the straight stream-of-bytes approach won't work, but in practice
they just don't seem to crop up. So "compatibility hell" isn't.
Given the high level of difficulty in dealing with this (I suspect that
reliably handling all types of character encodings, not to mention assorted
bugs and erratic behaviour in different implementations, across all possible
systems, is a more or less unsolvable problem) and the fact that so far it's
never cropped up as an issue, I'm sticking with the string-of-bytes
More information about the cryptography