On Tue, 16 Oct 2018 at 16:35, Sara Golemon <poll...@php.net> wrote:
> On Tue, Oct 16, 2018 at 8:43 AM Rowan Collins <rowan.coll...@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]
