Message-ID: <20150922211838.GA19113@openwall.com>
Date: Wed, 23 Sep 2015 00:18:38 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Specification of a modular crypt format

On Sun, Sep 13, 2015 at 08:26:50PM +0200, Thomas Pornin wrote:
> The hash output size for password verification should be fixed
> (otherwise, if people have to choose that length, it is unavoidable that
> some will do something stupid). While collisions are not a concern, it
> would probably be a good marketing move to use an output size which is
> "naturally" immune to collisions, i.e. 256 bits. This is what SHA-256
> outputs, and is larger than the 192 bits of bcrypt. A 32-byte output is
> not too huge with regards to the rest of the string, and also with
> regards to existing hash strings that rely on SHA-256 crypt or, even
> more so, SHA-512 crypt. While a 128-bit output would save some resources
> and make more sense (cryptographically speaking), a 256-bit output
> should ensure wider acceptance by the user base.

While I agree with the above, possible reasons to support other hash
output sizes are:

1. Desire to be able to convert from possible alternative encodings to
our would-be canonical one.  If someone uses e.g. Argon2 with 128-bit or
512-bit output, those hashes would end up not having canonical encoding
equivalents.  (It's basically the same reason why we may want to store
the salt encoded, and decode it when passing into the PHC scheme.  The
proposed scheme implements that, but not variable hash output size.)

2. Potential KDF use via an API that only provides encoded output, e.g.
pgcrypto and SQL queries.  (Arguably, this would be a hack.)

To reduce the risk of someone doing something stupid (and accept that we
won't be able to convert such hashes to our encoding), maybe the minimum
size should be set at 16 bytes (and the maximum at 128 bytes, which is
enough e.g. for 4 256-bit keys?)  Of course, then implementations might
not enforce that, allowing for potential extension... and misuse.

I am not sure this is worth it; I am just thinking out loud.  If we go
for a compact encoding instead of what Thomas proposed so far, then
output size being 256 bits only makes more sense.  But with a bloated
syntax, we could as well encode the requested output size in there.

A reason not to allow output sizes other than 256 bits is that some
features such as hash upgrade and server relief may reasonably only be
defined for a fixed size like this.  (This is the case for yescrypt.)

> I limit the salt length for Argon2 to a maximum of 48 bytes (64
> characters after B64 encoding) so as to help decoders (stack buffers
> again...). Argon2 can process much longer salts, but that does not make
> a lot of sense for password verification, where a 16-byte salt (say, an
> encoded UUID) is already fine.

No objections about the maximum, but what should the minimum be?  For
actual use, I'd set the minimum to 12 bytes (16 B64 chars), but for
ability to convert from alternative encodings that might not have had
such minimum, should we possibly support shorter salts in the encoding
syntax and in verification (but not when generating new hashes)?  This
is tough.  Supporting shorter salts (even zero length?) anywhere at all
might make such misuse more likely.  (Again, just thinking out loud.)
Anyway, this is easy to extend, and e.g. JtR will probably support a
wider range.  With hash output size, it's trickier (need a parameter to
request it and to ensure hash comparison expects a certain length).

Alexander

Powered by blists - more mailing lists