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-next>] [day] [month] [year] [list]
Date: Mon, 18 Feb 2013 14:02:45 -0800
From: "Dennis E. Hamilton" <>
To: <>
Subject: Coding of the in[inlen] array for PHS( )

The ASCII/non-ASCII about desirable test vectors suggest that being character set sensitive is permissible.  (That is how Java screwed up PBKDF2).  I suspect that is not intended.

To be clear about it, I suggest specifying in[inlen] to be a sequence of storage units in in[0] to in[inlen-1] progression and that is all there is to know about it.  It is probably necessary to specify that the values must be between 0x00 and 0xFF as well (just in case the storage units are larger).  If the array is blocked into words in some manner internal to PHS, the tranformation should be explicit without assumption of some big/little-endian orientation.  (Ditto for the out[outlen] of course.

It is best to consider that, within those constraints, the in[inlen] array consists of arbitrary values, whether or not indistinguishable from random.

I don't think *anything* about character set encoding and whether or not the password that is used is well-formed in any way should cross the API barrier.  It seems to me that reproducible use of PHS() falls on the external application.  The application needs to ensure that the same password value is coded in response to the same password text entry (if that is the scheme) on the part of an user or user agent that enters via a different path.  That's where any constraints need to be. 

In this way, it is entirely admissible to submit hashes to the function, as when extending an existing system to use the stronger PHS( ) by feeding it the hash previously retained by an authenticating service.  This is a way to upgrade without requiring knowledge of any password that produced the hash (or some indistinguishable from random) value being extended.  (The previous hash now becomes an intermediate value in the extended derivation.)

 - Dennis

Powered by blists - more mailing lists