phc-discussions - Re: [PHC] Coding of the in[inlen] array for PHS( )

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <20130219013526.GA22949@openwall.com>
Date: Tue, 19 Feb 2013 05:35:26 +0400
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Coding of the in[inlen] array for PHS( )

On Mon, Feb 18, 2013 at 08:26:23PM -0500, Daniel Franke wrote:
> Solar Designer <solar@...nwall.com> writes:
> 
> > Yes, PHS() is defined to accept inlen, but in many scripting languages
> > and in many other APIs NULs may be problematic anyway.
> >
> > Should PHS() support embedded NULs even when the password hashing
> > scheme's primary implementation - one intended for actual use - does not
> > support embedded NULs?  Well, perhaps it should...
> 
> Does there exist a scripting language that's so broken with respect to
> dealing with embedded nulls that it's unreasonable for us to expect the
> primary implementation of our scheme to deal with them properly?

That's a good question to which I have no answer.

The issues I am aware of are from calls into C-provided functions, with
conversion to C strings, e.g. with crypt() in PHP and Perl.  It is
generally possible to avoid such calls and then have a scripting
language implementation of a password hashing scheme that will process
embedded NULs like any other bytes.

So we may want to insist on support for embedded NULs, yes.

Alexander