[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <653CEFE7-2CD7-43D4-88F4-4C3205FFFB9A@goldmark.org>
Date: Fri, 6 Mar 2015 16:12:53 -0600
From: Jeffrey Goldberg <jeffrey@...dmark.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] PHC output specifics
On 2015-03-06, at 3:26 PM, Marsh Ray <maray@...rosoft.com> wrote:
> From: Thomas Pornin [mailto:pornin@...et.org]
>> 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.
> http://tools.ietf.org/html/rfc2865 :
> 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.
Cheers,
-j
–-
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits
http://agilebits.com
Powered by blists - more mailing lists