On Wed, Feb 5, 2014 at 8:26 PM, C. Scott Ananian <canan...@wikimedia.org>wrote:

> Password hashing algorithms are not the same as general hash algorithms.  I
> would prefer we didn't use whirlpool; it is "recommended by NESSIE and ISO"
> as a hash function, but as a password hash.  CWE916 recommends "bcrypt,
> scrypt, and PBKDF2" specifically for password hashing.
>
> To be clear, I have nothing against the Whirlpool hash algorithm itself:
> it's got a long pedigree with a decent amount of cryptoanalysis.  It's just
> the extension to password hashing which is nonstandard.  If you wanted to
> use Whirlpool as a password hash, you should apply it as part of PBKDF2,
> which is parameterizable.  That would be a reasonable way to distinguish
> the WMF hash to avoid general attacks without inventing new cryptography.
>  The default PRF for PBKDF2 is HMAC-SHA-1; you would be replacing this with
> HMAC-Whirpool.  This would be much preferable to using
> str_repeat+Whirlpool.
>   --scott
>

Sorry for the misleading. "Tim's algorithm" was indeed in reference to
using str_repeat vs. the tight xor loop of pbkdf2. Here are the relevant
ways that each do work:

pbdkf2:
for ( $j = 1; $j < $this->params['rounds']; ++$j ) {
$lastRound = hash_hmac( $this->params['algo'], $lastRound, $password, true
);
 $roundTotal ^= $lastRound;
}

Tim's:
for ( $i = 0; $i < $iter; $i++ ) {
$h = hash( 'whirlpool', str_repeat( $h . $this->args[0], 100 ), true );
 $h = substr( $h, 7, 32 );
}

If you look at whirlpool's compression function for the long messages, and
see that pbdkf2 as pretty much a Davies-Meyer compression function, they
have very similar properties. Except where they're subtly different, of
course ;).

The first subtle difference that I like about pbkdf2 is that the password
is mixed in at each round throughout, whereas Tim only mixes it in directly
in the first iteration (which is roughly the same as 3 rounds of pbkdf2 for
an 8 character password and 8 byte salt, since whirlpool is operating on
512-bit blocks). This could make pbkdf2 weaker if a key recovery attack
suddenly showed up in the hmac function, although that seems very unlikely
for hmac-sha256.

Additionally, since Tim's assigns the output to $h instead of xoring into
the previous round, that would be the same as pbkdf2 doing an assignment
every 14 rounds, which would feel a little weaker to me. Tim's could be
updated to keep the last block and do an xor instead, and they would be
more similar.

For someone doing a custom crypto scheme, I think Tim does better than
most, but overall it seems like most people prefer complying with a well
recommended standard than being unique.

So far no one has said they dislike pbkdf2, while bcrypt would require an
extra hash in serial to make sure long passwords can be handled, and would
require the php version bump. Anyone have strong opinions against pbkdf2?



>
>
>
> On Wed, Feb 5, 2014 at 10:00 PM, Marc A. Pelletier <m...@uberbox.org>
> wrote:
>
> > On 02/05/2014 09:34 PM, Tim Starling wrote:
> > > Maybe Chris's phrasing misled you: I didn't invent the Whirlpool
> > > algorithm
> >
> > And so it did; something a quick google would have revealed. In my
> > defense, "The Whirlpool algorithm by Tim" was pretty convincing
> > attribution.  :-)
> >
> > I'd need to read up on that algorithm a bit before I have an opinion on
> > whether length-extension attacks are not an issue with it (which is
> > often particularly nasty when the message repeats or is cyclical).  Most
> > hashes fare better by prepending a nonce as salt than they do by padding
> > or repeating.
> >
> > -- Marc
> >
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> (http://cscott.net)
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to