Message-ID: <54033082.2010004@ciphershed.org>
Date: Sun, 31 Aug 2014 10:26:10 -0400
From: Bill Cox <waywardgeek@...hershed.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] An additional PHS API to include a string?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/31/2014 09:46 AM, Thomas Pornin wrote:
> On Sun, Aug 31, 2014 at 07:31:22AM -0400, Bill Cox wrote: I do not 
> believe that things will go that way, though. Some people with the 
> "early adopter" frame of mind will not wait; they will use the 
> reference implementations right away (I suppose that some have 
> already begun). Others, based on some assumption of "purity" (or 
> any other name), will insist on using the "reference" code, and
> not any other implementation. For this reason, in the case of
> Makwa, I took care to already define a string-based format and
> implement it right away in the reference code. Thus, Makwa offers
> right now the simplified API that we are talking about here.

Awesome.  I also agree that this is an issue to be dealt with later,
and orthogonal to choosing a winner.  However, I do look forward to
reading that code :-)

> - If you need something like Base64, then please use actual Base64

+1

> - String encoding for the output is fine, but you must also mind 
> the input. Password hashing is about hashing passwords (duh), and 
> passwords tend to be sequences of characters. Invariably, any 
> password hashing function begins by converting a sequence of 
> characters into bytes. C-based implementations often assume that 
> the conversion has already been done, but this is a known source
> of bugs; famously, one widespread implementation of bcrypt had
> trouble processing non-ASCII characters, and I saw the same bug in
> PGP 5.5 code (because of assumptions on the signedness of the
> 'char' C type).

I've written Unicode-32 to UTF-8 before.  It is a bit
tricky.  I did a ton of automated testing vs the reference version
before I believed it worked.  This is not something that belongs
directly in the core of a password hashing function, as it's more
complicated than some of them, and highly error-prone.

I think the implementations should assume the conversion has already
been done, and that the password is now simply key material in an
unsigned array of bytes which can include any value, even 0's.  If we
need to deal with this, it should be done once in a wrapper for the
winner(s) to use.  I'm happy to donate one, if we need one, as the
GNU-licened libiconv code is huge and burdened with the LGPLv2 license
which some users cannot accept.

Support for Microsoft's legacy Unicode-16 is something I would not
want to take on, but I'd vote in favor of supporting UTF-8 and
Unicode-32 formats.

> We cannot ignore the non-Western world; thus, ISO-8859-1 
> ("latin-1") encoding is not appropriate. We have to embrace 
> Unicode, which means UTF-8, UTF-16 or some other encoding. 
> Unfortunately, humans have been extremely creative with regards to 
> writing systems, which means ambiguity (e.g. even a simple "é" 
> character has several possible decompositions in code points). 
> Therefore, it seems best if any implementation of a password 
> hashing function, in a language where strings are strings (i.e. 
> almost all of them except C and C++), takes care to apply strictly 
> defined and unambiguous encoding rules.

+1

Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUAzB+AAoJEAcQZQdOpZUZouMP/ia8rvomZfzUMWgt/x/8JF20
BjVyKJDpPg2kMRWZ5wmaNmucTzTnWLFDJV8Ew2QxSMGQ1NdNWcgn3dyuBTyqxJlT
QWBdeRBJvwRTP/QOx4UTQFZytJIANwTkkKU/Vg6JGaUETTcNFNL9wwLmjqasSBZa
d1AFWbQ58fyIhuwmMAKKoPRlxMfzOtkWVQK+7Goyu9mbkKyXfzvtMJdgKXUWsZlA
U8p6EatHh+jDn1mqeInOyqaFxZUbT8SjXth1t4YgDH/FSdMIae02sp1Cpe49zoWi
BEq0oSCL/cQj0IjOgdHd+BDoVcFbyd4qVs62O5wUf0yqeFBWlw2z9EYVpOaZslLf
l5tDo+vIHfZYNhsZoWIT/C0VdGCtvkXW7d9EV58iiLYeCdsQXmfuKJa9F9ajQqpk
GTBX+nJ6OhxYsvO8KXhsQDS7M/NOOyuQgznc6FhjgyRFVGDSXBGtxyZvJjXhdo9G
EZ2nODV8E1wICR/JjEWwmj3OWK67We9jiqQDiqT1SoLWoEu/JmfV3Q++/qgKL4yF
6GxBpiRPHP14iqjx9Yq2vnvNaBcg76q8O5sAW66LuDyQJN2SNq3yLrfonbVd28Ml
9ueNFHld629wxOMeoCiK4pgklAoTb5TUmrWZm+8sv4cL8jsvf3okZlAKDxTeVMHt
DWOqzj6JO1ELuBaUIqoT
=8XU8
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists