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  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 <>
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:
> >

> 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

> 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).


Powered by blists - more mailing lists