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]

Date: Tue, 19 Feb 2013 03:00:35 +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 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
characters)."

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.

Alexander