[cryptography] Oddity in common bcrypt implementation
jon at callas.org
Wed Jun 29 21:15:25 EDT 2011
On Jun 29, 2011, at 11:36 AM, James A. Donald wrote:
> Thus the password has to be normalized before being hashed.
> Further, often a variants of a single character with a single meaning also have multiple codes - there is no sharp boundary between the string, and formatting information, though this is more a problem for unicode searching, than for unicode passwords.
I've dealt with this issue in cases where the password is (sadly) by necessity not even unicode, but the series raw scan codes from the keyboard. I've dealt with them like Peter -- they're just a blob of bytes, and had only slightly more problems he's had. There are a couple of possible solutions, but the "use the same keyboard" one has practical appeal.
By experience says that while strictly speaking, you are correct, in practice it's not an issue because you almost always are hashing the same blob of bytes.
Note that I'm not saying it can't go wrong, not that it won't go wrong. Merely that I don't see it as an issue that must be solved up front. It's an issue that needs to be considered, but it's less of a problem than you'd think.
More information about the cryptography