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: Wed, 16 Sep 2015 10:03:22 +0000
From: Jean-Philippe Aumasson <>
Subject: Re: [PHC] Specification of a modular crypt format

KrisztiƔn asks two important questions, regarding the encoding flexibility
and parameters ordering. I don't know what's the usual practice to deal
with those. Can't parameters be in arbitrary order?

On Tue, Sep 15, 2015 at 12:26 PM Jean-Philippe Aumasson <> wrote:

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