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: Tue, 15 Sep 2015 10:26:36 +0000
From: Jean-Philippe Aumasson <>
Subject: Re: [PHC] Specification of a modular crypt format

I copied Thomas' draft on the following google doc, where anyone can
comment, but not edit. Edit rights are granted to Thomas and to the PHC

On Mon, Sep 14, 2015 at 10:43 PM Thomas Pornin <> wrote:

> On Mon, Sep 14, 2015 at 05:05:11PM +0100, Hugo Landau wrote:
> > The need for key-value extensibility for password hashing functions
> > is, presumably, nil
> Actually I am not doing it for extensibility, but for readability.
> If you have three parameters (say, the p, m and t or Argon2) then
> you can have something like:
>     $argon2i$42$5$5000$...
> but then you have to remember, as a human reader, in which order the
> p, m and t appear in the string. In my proposal you get:
>     $argon2i$m=42,p=5,t=5000$...
> which is clearer (for humans). Since the order is fixed, this should not
> be more complex to parse (instead of checking "does it start with '$'",
> code checks for "does it start with ',p='", which is still a single
> strncmp() call for a C-based parser).
> Accepting named parameters in arbitrary order, and/or ignoring
> unrecognized parameters, would indeed make parsing more complex, but I
> personally don't want that. I want the whole encoding to be fully
> deterministic so that test vectors work well. This also implies that
> the parsing can remain relatively easy.
> I'll try to write the parsing code in a few days, so that we may have a
> baseline for the complexity of implementations.
> > I also think parameter values can be limited to non-negative integers at
> > this time, unless you are aware of any password hashing schemes which
> > would be incompatible with this.
> In Makwa, at least, it is preferable to have a binary identifier for the
> used modulus (in the current spec, it is a hash of the modulus,
> truncated to 8 bytes). This parameter does not map to a non-negative
> integer (well, you _could_ make it an integer, since every sequence of
> bits can be interpreted as an integer, but you see what I mean).
> Another case would be PBKDF2, which is configurable with an iteration
> count, an output length, and an underlying PRF (usually HMAC with a
> given hash function). The hash function name could be made part of the
> function identifier (i.e. you have 'pbkdf2-sha1', not 'pbkdf2' with a
> 'sha1' parameter), but, conceptually, you could make the hash function
> one of the parameters (as a symbolic string).
> > I'm not convinced by this rationale. Firstly, I'm not aware of any
> > base64 functionality provided by programming language standard libraries
> > which does line wrapping, etc.
> .NET's System.Convert.ToBase64String() includes newlines by default
> (which might be OS-dependent, even). However, there are four versions
> of that call, two of which accepting an extra parameter of value
> Base64FormattingOptions.None to avoid inserting line breaks every 76
> characters (yes, 76, not 64).
> "openssl base64" (command-line tool, for shell scripts) also includes
> line breaks (and requires them upon decoding...).
> None of this is an irremediable point. "True" Base64 is not harder to
> implement than the "crypt" variant. I'll give it a go (I already did in
> both C and Java, neither of which having innate abilities at Base64).
> (I note that the B64 implementations already in place for bcrypt and the
> SHA-2-based crypts works only in the encoding direction, which is the
> easier of the two. For salt _decoding_, we need a decoder, which is
> relatively harder to implement.)
> > Developers in this circumstance (or, preferably, people developing
> > password hashing libraries)
> Yes, much preferably, please.
>         --Thomas Pornin

Content of type "text/html" skipped

Powered by blists - more mailing lists