Date: Wed, 16 Sep 2015 13:09:57 -0700
From: Dmitry Khovratovich <khovratovich@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Specification of a modular crypt format

The proposal is really great, and I thank Thomas for working on it.

Argon2 currently allows two additional inputs: key and associated data. The
key input is solely to emulate MACs, whereas the associated data is
supposed to contain username, application data, or whatever
context-specific details.

I suggest using these two inputs as parameters alongside m,p, and t. They
can be binary encoded similarly to salt. The hash string would then contain
the associated data parameter, but not the key parameter. This will allow
hash lookup in the file by the associated data value. The key parameter
should certainly be omitted from the hash string, but there must be
indication that it must be looked up somewhere else. The encoding scheme
should also consider NULL parameter values for key and associated data.

If the password were included as parameter as well, this would allow very
simple Generate/Verify interface with just a single string as the function
input. Does it break the compatibility too much?

On Mon, Sep 14, 2015 at 1: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
>



-- 
Best regards,
Dmitry Khovratovich

Content of type "text/html" skipped

Powered by blists - more mailing lists