Message-ID: <CAGiyFdfmFMeq6sStLi-CCf9-8ud6MYpzSR=SZZq6jWSPEcz0gQ@mail.gmail.com>
Date: Wed, 16 Sep 2015 10:03:22 +0000
From: Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Specification of a modular crypt format

Krisztián asks two important questions, regarding the encoding flexibility
and parameters ordering. I don't know what's the usual practice to deal
with those. Can't parameters be in arbitrary order?



On Tue, Sep 15, 2015 at 12:26 PM Jean-Philippe Aumasson <
jeanphilippe.aumasson@...il.com> wrote:

> I copied Thomas' draft on the following google doc, where anyone can
> comment, but not edit. Edit rights are granted to Thomas and to the PHC
> panel:
>
> https://docs.google.com/document/d/1QJva4xsY3eHNm2YiT0yPS9spRqd-N8NamYRpF5lkIzM/edit?usp=sharing
>
> On Mon, Sep 14, 2015 at 10:43 PM Thomas Pornin <pornin@...et.org> wrote:
>
>> On Mon, Sep 14, 2015 at 05:05:11PM +0100, Hugo Landau wrote:
>> > The need for key-value extensibility for password hashing functions
>> > is, presumably, nil
>>
>> Actually I am not doing it for extensibility, but for readability.
>> If you have three parameters (say, the p, m and t or Argon2) then
>> you can have something like:
>>
>>     $argon2i$42$5$5000$...
>>
>> but then you have to remember, as a human reader, in which order the
>> p, m and t appear in the string. In my proposal you get:
>>
>>     $argon2i$m=42,p=5,t=5000$...
>>
>> which is clearer (for humans). Since the order is fixed, this should not
>> be more complex to parse (instead of checking "does it start with '$'",
>> code checks for "does it start with ',p='", which is still a single
>> strncmp() call for a C-based parser).
>>
>> Accepting named parameters in arbitrary order, and/or ignoring
>> unrecognized parameters, would indeed make parsing more complex, but I
>> personally don't want that. I want the whole encoding to be fully
>> deterministic so that test vectors work well. This also implies that
>> the parsing can remain relatively easy.
>>
>> I'll try to write the parsing code in a few days, so that we may have a
>> baseline for the complexity of implementations.
>>
>>
>> > I also think parameter values can be limited to non-negative integers at
>> > this time, unless you are aware of any password hashing schemes which
>> > would be incompatible with this.
>>
>> In Makwa, at least, it is preferable to have a binary identifier for the
>> used modulus (in the current spec, it is a hash of the modulus,
>> truncated to 8 bytes). This parameter does not map to a non-negative
>> integer (well, you _could_ make it an integer, since every sequence of
>> bits can be interpreted as an integer, but you see what I mean).
>>
>> Another case would be PBKDF2, which is configurable with an iteration
>> count, an output length, and an underlying PRF (usually HMAC with a
>> given hash function). The hash function name could be made part of the
>> function identifier (i.e. you have 'pbkdf2-sha1', not 'pbkdf2' with a
>> 'sha1' parameter), but, conceptually, you could make the hash function
>> one of the parameters (as a symbolic string).
>>
>>
>> > I'm not convinced by this rationale. Firstly, I'm not aware of any
>> > base64 functionality provided by programming language standard libraries
>> > which does line wrapping, etc.
>>
>> .NET's System.Convert.ToBase64String() includes newlines by default
>> (which might be OS-dependent, even). However, there are four versions
>> of that call, two of which accepting an extra parameter of value
>> Base64FormattingOptions.None to avoid inserting line breaks every 76
>> characters (yes, 76, not 64).
>>
>> "openssl base64" (command-line tool, for shell scripts) also includes
>> line breaks (and requires them upon decoding...).
>>
>> None of this is an irremediable point. "True" Base64 is not harder to
>> implement than the "crypt" variant. I'll give it a go (I already did in
>> both C and Java, neither of which having innate abilities at Base64).
>>
>>
>> (I note that the B64 implementations already in place for bcrypt and the
>> SHA-2-based crypts works only in the encoding direction, which is the
>> easier of the two. For salt _decoding_, we need a decoder, which is
>> relatively harder to implement.)
>>
>>
>> > Developers in this circumstance (or, preferably, people developing
>> > password hashing libraries)
>>
>> Yes, much preferably, please.
>>
>>
>>         --Thomas Pornin
>>
>

Content of type "text/html" skipped

Powered by blists - more mailing lists