phc-discussions - Re: [PHC] Re: Interest in specification of modular crypt format

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 7 Sep 2015 17:49:21 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Re: Interest in specification of modular crypt format

On Mon, Sep 07, 2015 at 02:37:25PM +0100, Hugo Landau wrote:
> On 06/09/15 21:02, Simon Josefsson wrote:
> > https://gitlab.com/jas/scrypt-unix-crypt/blob/master/unix-scrypt.txt

> In ignorance of the above specification I have been using my own, which
> looks like this:
> 
>   $s2$N$r$p$salt$hash
> 
> salt and hash are RFC 4648 base64-encoded strings, and N, r and p are
> ASCII decimal integers. The salt is properly decoded before use.
> Passwords are UTF-8.
> 
> This seems like a simpler style of format.
> 
> As a format invented in 30 seconds, this could work for Argon2i:
> 
>   $a2i$p$m$t$nonce$hash

Perhaps move p to after m and t.

Should there be a shortcut syntax where some parameter can be omitted
and a default used?  e.g. have p and t default to the smallest supported
(which is generally what I would recommend for password hashing use
anyway).  If so, it'd be preferable to use another delimiter between the
parameters.

> This format assumes that K = "" and X = "" (or are contextually
> provided), which will probably(?) be appropriate for most use cases.
> Let tag length be 32 bytes. Let p, m and t be ASCII-encoded positive
> decimal integers. Let nonce and hash use RFC 4648 base64 encoding. Let
> the passphrase use UTF-8.
> 
> What are the issues with this, I wonder?

No major issues.  Something like this is within consideration.  The use
of decimal and RFC 4648 base64 is scripting language friendly.  The use
of decimal is human friendly (except for parameters that are naturally
binary, such as a set of flags).

If others go for an approach like this for PHC schemes now, I will
probably do the same for yescrypt for consistency.

Minor drawbacks are:

A few chars are wasted on padding, which is meaningless here (3 chars
with a 128-bit salt and a 256-bit hash, so not a big deal).

Similarly, larger numbers consume more chars in decimal than in crypt
base64 encoding, but that's also just a few chars more.

I'd expect many (possibly most) implementations not to insist on the
decimal numbers having proper syntax (digits only) and being in range
(except after decoding, where an overflow may have already occurred).
It's just too tempting to simply use atoi() or a scripting language's
equivalent, instead of proper use of strtoul() (with its somewhat weird
semantics) or checking the string against a regexp first (including a
length limit).

Alexander