[cryptography] Oddity in common bcrypt implementation

Peter Gutmann 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 mailing list