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: Fri, 6 Mar 2015 16:12:53 -0600
From: Jeffrey Goldberg <>
Subject: Re: [PHC] PHC output specifics

On 2015-03-06, at 3:26 PM, Marsh Ray <> wrote:

> From: Thomas Pornin [] 
>> To be unambiguous, one has to also specify the normalization. Unicode defines NFC, NFD, NFKC
>> and NFKD. In general, NFC is what you get from existing user interfaces, so standardizing on
>> NFC is probably the best idea. But that is debatable (and debated).

Ah. This sounds like the answer to a problem that we’ve been facing at AgileBits. And if this works, I think that Thomas is correct. Some normalization will be needed.

> :
>     Text contains UTF-8 encoded 10646 characters and
>     String contains 8-bit binary data.  Servers and
>     servers and clients MUST be able to deal with embedded nulls.
> ...
>      It is recommended that
>      the message contain UTF-8 encoded 10646 [7] characters.

I think that that without normalization, that is too weak.

That is what do for 1Password Master Passwords, but it does not solve the problem for us in
that a password like “Gödel” can be a different string of bits depending on the keyboard and OS that it was typed on. So although we accept UTF-8, we encourage users to stick with US-ASCII to
avoid such problems. 

I’ve only just started to look at the normalization schemes, but I do think that the PHC
is going to have to recommend one.



Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits

Powered by blists - more mailing lists