Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103324
MIME-Version: 1.0
References: <CAESVnVq-oQreEyNDQZPWJ+fxuXs_66WWBTywRii7AFEFjqxBNQ@mail.gmail.com>
 <CALKiJKrhB9pKtdF=PdBwrJB-81QLCGtr1TKF6rQ0p8XtGhFrrA@mail.gmail.com> <CAESVnVpXjvR2-3n6AdSA+TwzsGEEeAD0L2dH18wiDtHnwE7uHA@mail.gmail.com>
In-Reply-To: <CAESVnVpXjvR2-3n6AdSA+TwzsGEEeAD0L2dH18wiDtHnwE7uHA@mail.gmail.com>
Date: Tue, 16 Oct 2018 17:54:43 +0100
Message-ID: <CALKiJKqxgFd=fQvapDrX3tJLtuEkEXk-qHwv=XrNfM5OURROHg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bcdce005785b6939"
Subject: Re: [PHP-DEV] Password Digest Registry
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000bcdce005785b6939
Content-Type: text/plain; charset="UTF-8"

On Tue, 16 Oct 2018 at 16:35, Sara Golemon <pollita@php.net> wrote:

> On Tue, Oct 16, 2018 at 8:43 AM Rowan Collins <rowan.collins@gmail.com>
> wrote:
> > As I understand it, the purpose of the $foo$ syntax is to uniquely
> identify
> > each algorithm, so would it make sense to pass the prefix string to the
> > register call, and maintain a lookup table internally of prefix =>
> handler?
> >
> If that's an assumption we can definitely make, then absolutely, that
> simplifies a lot of the design.  When preparing this I wasn't 100%
> confident that this would hold true (maybe
> $foo${hashspecificstuff},v=1 is different from
> $foo${hashspecificstuff},v=2), and I didn't want to create a problem
> for future us.  But I suppose we can always extend the protocol if it
> comes to that.
>

The format seems to have become a de facto standard, with the first part
identifying the algorithm, and later parts algorithm-specific. Among the
references on Wikipedia are:

- a man page discusssing glibc's implementation of the crypt() function [1]
describing the format as $id$salt$encrypted
- a document from the Password Hashing Competition [2] describing it as
$<id>[$<param>=<value>(,<param>=<value>)*][$<salt>[$<hash>]]

I think encoding that assumption in PHP is following the general consensus,
and in the absence of a stronger standard we're not obliged to follow an
implementation that varies from that consensus anyway. In other words, if
someone implements MyAwesomeHash as a C library that doesn't use a unique
prefix of the appropriate form, the PHP wrapper can always prepend
$MyAwesomeHash$ to the C library's output, and strip it off again when
verifying.

In your $foo${hashspecificstuff},v=2 case, the handler could register for
prefix "foo", then delegate internally by parsing out the v=1 or v=2 token.
The chance of those two algorithms being in separate extensions which are
completely unaware of each other seems pretty slim.

[1] http://man7.org/linux/man-pages/man3/crypt.3.html
[2] https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md

Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000bcdce005785b6939--