Date: Tue, 22 Sep 2015 19:09:34 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Specification of a modular crypt format

Hi Thomas and all,

On Sun, Sep 13, 2015 at 08:26:50PM +0200, Thomas Pornin wrote:
> here is my take at specifying a string format for the output of a
> password hashing function; this aims at supporting password verification
> in a way compatible, in particular, with the Unix crypt() API and the
> /etc/shadow files. This is not for use of a function as a KDF. I tried
> to remain as generic as possible, although of course the primary target
> is Argon2.

First of all, thank you for working on this!

Then, I'm sorry for being a bit late with my feedback.  Yet maybe better
late than never, so here goes:

I dislike use of <param>=<value>, as opposed to just listing the values.

I also find it inconsistent that the proposed syntax mixes bloated
constructions such as long identifier names, use of <param>=<value>, and
use of decimal with the more compact choice of crypt(3) base64 encoding
rather than RFC Base64.  I think we should consistently opt for a
compact or a bloated encoding, and I'd prefer compact, but if you do
bloated, then do it to the fullest extent (and we'll have a compact
alternative then).

I do see value in listing of the parameters in a fixed order (and in
having no defaults and in listing all parameters all the time as well,
despite of the drawbacks).  However, when that fixed order comes from
lexicographic order of parameter names it may end up being otherwise
weird, and inconsistent with what we already have for scrypt.  Given
that yescrypt builds upon scrypt and supports scrypt compatible mode,
I'd like to have its parameters common with scrypt listed first and in
the same order as is commonly used with scrypt.  This is N, r, p, but
lexicographic order would result in N, p, r.  I find having to introduce
this inconsistency, if we adopt your proposal as currently specified,
unfortunate.

It could also be nice to be able to omit yescrypt's additional
parameters that are not in scrypt - in other words, use this opportunity
to introduce a syntax for scrypt that would address some limitations of
what we previously defined for scrypt, without having to list yescrypt's
parameters.  Well, I guess we can do that within your specification by
allocating a separate identifier string for scrypt.

The use of crypt(3) base64 could help encode the parameters in a more
compact way, e.g. use just one char (and no separator before/after it)
for (ye)scrypt's log2(N).  I find it suboptimal to go for crypt(3)
base64 yet not take full advantage of it.

Overall, I think this verbose syntax might hamper adoption by some
projects.  I also think that if we go for a verbose and human and
scripting friendly syntax for the parameters anyway, we should as well
bite the bullet of RFC Base64 with its extra padding characters.  Having
3 extra characters is negligible compared to the bloat we already have
in the proposed long identifiers and the encoding of parameters.
I actually prefer crypt(3) base64, but I dislike the bloat already
proposed enough that going for RFC Base64 just doesn't make it all that
much worse for me, while making it better for others.  I'll probably
come up with an alternative compact encoding anyway, and this one may be
bloated to the fullest extent then.  OTOH, it's nice to have a common
encoding type (and common code) between the compact and bloated forms,
so maybe your choice is right from that point of view.

Also, if we go for a bloated syntax anyway, we probably should use the
opportunity to allow for encoding of arbitrarily small or large salts,
and arbitrary hash sizes.  So that e.g. if crypt() is available via
pgcrypto or something, thus via SQL queries in this example, its support
for a PHC scheme could then be reused to compute that scheme with
arbitrary inputs with no artificial restrictions.  e.g. to derive
multiple keys at once (where 256 bits could be too little).  I don't
feel about this strongly, but overall I feel that we should either avoid
bloat or use the potential advantages of the bloat to the fullest,
whereas the proposed encoding does neither.

Sorry for the criticism.  Again, I appreciate the effort.

Thanks,

Alexander

Powered by blists - more mailing lists