[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAyV7nEVmWEvADsLjQikSBDX0innct4+G01Kcfq6KmO0px7ULg@mail.gmail.com>
Date: Wed, 27 Jun 2012 08:02:46 -0400
From: Anthony Ferrara <ircmaxell@...il.com>
To: crypt-dev@...ts.openwall.com
Subject: Re: Simplified PHP Password Hashing
Alex,
> Thanks. I've just provided a relevant reply here:
>
> http://news.php.net/php.internals/60977
Thank you very much!
> Unfortunately, I don't expect to have much time for this during the
> summer. If you're not in much of a hurry to include this in PHP, then
> I'd be happy to review and discuss it with you later.
Not too much, but I'd like to ensure that it makes it in php 5.5...
IIRC the first beta release isn't for several months, so I think we
have some time...
> On a related note, I think that your PHP-PasswordLib has too much stuff
> in it:
>
> https://github.com/ircmaxell/PHP-PasswordLib
I've hear that before too. :-D
> What immediately caught my attention is this:
>
> "Secure Random Number/String Generation
> [...]
> The mixing function is also dependent upon the strength required. For
> non-cryptographic numbers, a simple XOR mixing function is used (for
> speed). As strength requirements increase, it will use a SHA512 based
> mixing function, then a DES based mixing function and finally an AES-128
> based mixing function at "High" strength."
>
> I see no reason to support these four modes instead of just one, e.g.
> based on SHA-512. Just how is DES or AES any better for this purpose?
> Perhaps leave the mode based on SHA-512 only. (I haven't looked at the
> code yet, though.)
The interesting thing there is that it's a holdover from another
project of mine that I forked into PasswordLib: CryptLib
https://github.com/ircmaxell/PHP-CryptLib
In PasswordLib, I actually pulled all but the hash implementation
(SHA-512): https://github.com/ircmaxell/PHP-PasswordLib/tree/master/lib/PasswordLib/Random/Mixer
That documentation is out-dated. I'll update it.
> I do realize that this is a separate project, but I am concerned that
> you might similarly provide too much stuff via your new API right away.
> The API should be generic enough that future stuff would be likely to
> fit it well, but there shouldn't be unneeded stuff available via it now
> just to provide more examples.
That's a very valid concern. My goal was flexibility, portability and
extend-ability. But it did wind up somewhat, well, big...
Thanks for the feedback,
Anthony
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
