On Jun 29, 2011, at 4:49 AM, Peter Gutmann wrote: > I realise it's fun to jump in and bikeshed the living daylights out of this,
+1. i18n geeks do this all the time. > but before we do that we'd really need to figure out whether the "cure" is > worse than the disease. +1. When we first applied i18n to passwords, we argued long and hard about it because there were strong arguments on both sides. We ended up with "yes we should do it" and now can evaluate what came of that decision. > 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. That would be "the billion+ people who use the Arabic script for many different written languages". > So far I've had exactly zero complaints about i18n or c18n-based password > issues. And that's a very valuable data point. It weighs heavily against the developer problems we have seen with using stringprep in password preparation. In retrospect, I believe we made the wrong choice to go with "process passwords with this complex algorithm", but I don't think we could have known that at the time. --Paul Hoffman _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
