Message-ID: <CAGiyFdc7cj34OcK4FmjUGF0PhZO5d7fi40Yo5bKrWMYyhTW2Tg@mail.gmail.com>
Date: Wed, 16 Sep 2015 19:34:27 +0000
From: Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Specification of a modular crypt format

A deterministic encoding of values indeed reduces the risk of parser bugs.
It's also easier for us to specify. Otherwise, we'd have to decide what
should (not) be tolerated, for example 00001, 1.000, 01.0, etc.

Concerning the parameters' order, we know how to design reliable parsers
for such simple inputs. I don't see how it would hurt.

On Wed, Sep 16, 2015 at 8:36 PM Thomas Pornin <pornin@...et.org> wrote:

> On Wed, Sep 16, 2015 at 10:03:22AM +0000, Jean-Philippe Aumasson wrote:
> > 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?
>
> The way my draft specifies things, there is a unique encoding for a
> given set of parameters and salt value. This is what I call
> "deterministic". Having a deterministic encoding makes parsing a bit
> easier, and, maybe more importantly, makes tests easier as well: you
> can simply verify that you obtain the expected test vector.
>
> This is not an absolute requirement. Right now, existing formats for,
> say, SHA-256 crypt, are not deterministic, since one can omit or include
> the '$rounds=5000' parameter. This does not apparently prevent password
> verification. In the crypt() API, the returned string is the
> concatenation of the salt string, _as it was received_, and the hash
> output, which rather cleanly tolerates all variants in parameter
> encoding.
>
>
> IF we want deterministic encoding, then a numerical parameter of value
> '1' can only be encoded as '1', not '01' or '001' (or, alternatively,
> can be encoded only as '001', not '01' or '1'; or any other convention
> as long as there is no choice). Otherwise, determinism is not achieved.
> This should answer Krisztián's first question: yes, it is intentional
> that '001' be rejected.
>
>
> Krisztián's second question is about lexicographic order. Still under
> the idea that we want a deterministic encoding, then the parameters
> cannot appear in arbitrary order; a fixed order must be specified.
> However, that order can be specific to each function. In the
> specification, I currently defined that lexicographic ordering of
> parameter names must be used, but any convention is as good as any
> other. If, for aesthetic reasons, it is considered that the normal
> parameter ordering for Argon2 is 'm,t,p' and not 'm,p,t', then it is
> certainly possible to define the encoding format for Argon2 to use
> 'm,t,p'.
>
> Defining a systematic rule (lexicographic order) for all hash functions
> potentially helps in writing a generic decoder: each function just has
> to invoke the decoder with a list of parameters to expect; if the rule
> is per function, then the decoder must be invoked with an _ordered_ list
> of parameters. This is not substantially harder, so I'd say that letting
> each function define the ordering of parameters is possible.
>
>
> Of course, if we decide that determinism is not needed or not desirable,
> then both of these questions become irrelevant. However, accepting
> parameters in arbitrary order makes the parser more complex, and we need
> a lot many more test vectors to account for the greater number of
> possible combinations.
>
>
>         --Thomas Pornin
>

Content of type "text/html" skipped

Powered by blists - more mailing lists