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: Sun, 27 Sep 2015 09:40:50 -0400
From: Anthony Ferrara <>
Subject: Re: [PHC] Interest in specification of modular crypt format


On Thu, Sep 24, 2015 at 9:32 PM, Solar Designer <> wrote:
> On Mon, Sep 07, 2015 at 01:55:30PM +0300, Solar Designer wrote:
>> If we continue to build upon the traditional crypt(3) alphabet and
>> encoding (like the above specification for scrypt does), then I'd also
>> like to include a way to represent the numeric parameters in a more
>> compact form: let the little-endian encodings be truncated when the
>> values are small.  So e.g. instead of:
>> $7$C6..../....SodiumChloride$kBGj9fHznVYFQMEn/qDCfrDevf9YDtcDdKvEqHJLV8D
>> it would be valid to use:
>> $7$C6$/$SodiumChloride$kBGj9fHznVYFQMEn/qDCfrDevf9YDtcDdKvEqHJLV8D
>> or if we want to keep the number of '$' characters fixed, then either
>> require the '$' delimiters to always be present or maybe introduce '+'
>> or '=' for truncation (a character already used in the other base64
>> encoding's alphabet, so likely safe to use):
>> $7$C6+/+SodiumChloride$kBGj9fHznVYFQMEn/qDCfrDevf9YDtcDdKvEqHJLV8D
>> The savings for classic scrypt are small, but with yescrypt's additional
>> parameters they are more significant.
> BTW, an even more compact encoding of numeric parameters is possible,

Please, can the encoding be kept human-readable? Going with one-off
encodings does look elegant, but it makes the implementation
significantly more error prone.

People are even confused by the fact that the salt-boundary in bcrypt
occurs mid-character (leading to only 4 possible character values for
the last salt character).

Instead, can we focus on readability? For parameters that have well
defined defaults, simply don't require that parameter to be specified.
For those that don't have well defined defaults, then always require
them. Yes, it is a little bit more parsing overhead on the crypt()
implementation, but it greatly reduces the overhead on the calling
code. Especially for those building wrappers (which happens all the

I do like the approach of specifically identifying parameter that was
brought up in the other thread. Something along the lines for scrypt:


But since p=1 could reasonably be default, the following is identical:


Whether a parameter is power-of-2 or base 10 would depend on the
algorithm. Also, please don't define the parameter order as rigid.
It's simple enough to implement arbitrary order, so why put arbitrary

So my overall suggestion is make it easier on the developer using the
API, rather than the one writing it. After all, there are going to be
FAR more people writing a salt string then there will be writing the
backend implementation. Optimize for the greater use-case...

Just my $0.02


Powered by blists - more mailing lists