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: Tue, 19 Feb 2013 05:35:26 +0400
From: Solar Designer <>
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 <> 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.


Powered by blists - more mailing lists