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:22:20 +0000
From: Marsh Ray <>
To: "" <>
CC: "Dennis E. Hamilton "
Subject: RE: [PHC] Coding of the in[inlen] array for PHS( )

> From: Dennis E. Hamilton []
> I am going to risk over-stating the obvious just to make certain that I, as a
> newcomer, am on the same page about what the tacit understanding is
> concerning what PHS( ) effectively operates on.

Thank you :-)

This is definitely something that needs to be addressed by the final stage of the PHC. But it's probably not urgent to finalize it now.

We might look at the history of the RADIUS authentication protocol. It handles username and password data for a variety of clients and servers.

RFC 2058 didn't define or recommend an encoding for strings.
RFC 2865 defined distinct 'text' and 'string' types "Text contains UTF-8 encoded 10646 characters and String contains 8-bit binary data." Presumably this change was made to encourage interoperability, the IETF tends not to invoke ISO 10646 or Unicode lightly.

How about this wording:

"The function must be well-defined for all sequences of octets supplied to the password input. Length constraints should be clearly defined parameters of the algorithm and should generate an error result if violated. Password inputs with embedded NUL (0x00) byte values are allowed and are treated as significant (even trailing NULs).

However, to promote interoperability callers are strongly encouraged to supply character data in the form of a sequence of minimal-length UTF-8 encoded ISO 10646 characters (not including any NULs trailing or otherwise) whenever practical. Note that this specification declines to recommend a specific Unicode normalization form in the hope that implementers will do the right thing.

Case-folding of password inputs is strongly discouraged, i.e., passwords should always be treated case-sensitively."

- Marsh

Powered by blists - more mailing lists