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 03:00:35 +0400
From: Solar Designer <>
Subject: Re: [PHC] Coding of the in[inlen] array for PHS( )

On Mon, Feb 18, 2013 at 02:02:45PM -0800, Dennis E. Hamilton wrote:
> The ASCII/non-ASCII about desirable test vectors suggest that being character set sensitive is permissible.

The "Call for submissions" talks about "bytes" in all places except for
this one:

"Comprehensive set of test vectors (preferably including non-ASCII

Perhaps this should be changed to:

"Comprehensive set of test vectors (preferably including all byte values
in the 0 to 0xFF range for both the password and the salt inputs)."

Yes, if this "preference" is followed, this implies that we'll have at
least 256 bytes worth of data for each input (across all test vectors).

I think we don't want to get into the complicated issues with
"characters" here.  "Characters" may use different encodings, may be
multi-byte, may vary in endianness, etc.  In PHS(), we deal with bytes.


Powered by blists - more mailing lists