lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 31 Aug 2014 10:26:10 -0400
From: Bill Cox <>
Subject: Re: [PHC] An additional PHS API to include a string?

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


> - 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.


Version: GnuPG v1


Powered by blists - more mailing lists