phc-discussions - Re: [PHC] 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]

Message-ID: <CAGiyFdep+6rX4GuN8W4O3yZZrvdBLXSigT83oL-pEb9G-p-7AQ@mail.gmail.com>
Date: Sun, 04 Oct 2015 09:06:32 +0000
From: Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Interest in specification of modular crypt format

IMHO compatibility with b64 en/decoders is worth the extra ='s, and
sticking to the RFC probably simplifies the specs. But I don't have a
strong opinion on that subject.



On Sun, Oct 4, 2015 at 11:00 AM Solar Designer <solar@...nwall.com> wrote:

> On Mon, Sep 28, 2015 at 01:15:15AM +0300, Solar Designer wrote:
> > On Sun, Sep 27, 2015 at 04:46:48PM -0400, Anthony Ferrara wrote:
> > > On Sep 27, 2015 2:52 PM, "Solar Designer" <solar@...nwall.com> wrote:
> > > > For PHP and such, I think this pretty much implies the encoding will
> > > > also need to use RFC Base64.  Then it's just sprintf of some decimal
> > > > numbers and some base64()'s.  So my point remains that Thomas'
> proposed
> > > > encoding is neither here nor there.
> > >
> > > Completely fair. I am less concerned around the encoding of the salt
> than
> > > the encoding and specification of the parameters. If a high level api
> is
> > > provided for generating the salt, then awesome. That helps a lot.
> Though I
> > > would still suggest keeping it readable.
> >
> > Regarding crypt B64 vs. RFC Base64, Alexander Cherepanov has just
> > pointed out to me that there are in fact major issues with common
> > base64 decoders.
>
> Alexander Cherepanov has since posted about it in here.
>
> > Thomas had hinted at that, but I didn't realize just
> > how bad things actually were.  So I withdraw that suggestion for now.
>
> So it looks like we've chosen to use a verbose encoding:
>
> https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md
>
> and it looks like we've switched to (almost) RFC Base64:
>
> "The B64 encoding is the standard Base64 encoding (RFC 4648, section 4)
> except that the padding  =  signs are omitted, and extra characters
> (whitespace) are not allowed"
>
> As much as I am for compact encodings, I think if we chose to go verbose
> anyway, we should not omit the padding '=' signs.  Just to make it
> easier to use standard encoding/decoding functions.
>
> A reason to omit them is to ensure that '=' are only seen between
> parameter names and values, but this is not necessary for parsing.
> Even something like this may be parsed unambiguously:
>
> $id$param1=123,param2=B64here==,param3=B64there=$salt==$hash=
>
> It's not pretty, but it's simpler to create and parse when you already
> have base64 encoding/decoding functions.  Unfortunately, those decoding
> functions on their own typically won't ensure strict syntax (they're
> about as broken as strtoul() in this respect, or maybe slightly worse
> even), but that may be a reason for us not to choose RFC Base64 rather
> than to omit padding, I think.
>
> Alexander
>

Content of type "text/html" skipped