Any reason PBKDF2 shouldn't be used for (storing) hashed passwords?
Seems like it solves many problems:
1) slowing down guesses (at cost of slowing valid entries too)
2) parameterized iteration
3) IV/salt/uniquification
4) widely deployed, tested
5) difficult to parallelize (iterations)
6)
One curious note is that NIST recommends PBKDF2 for master key derivation,
and specifically write, The MK [PBKDF2 output] shall not be used for other
purposes. Perhaps the document was meant to document just KDFs. Since the
hashes are one-way anyway, I don't see it making a difference for use as
On Wed, Aug 15, 2012 at 8:46 PM, Patrick Mylund Nielsen
cryptogra...@patrickmylund.com wrote:
Blizzard Entertainment has been receiving a lot of flak from tech and mass
media lately for choosing to employ SRP in their Battle.net clients and
games. A lot of these outlets have been suggesting
On Thu, Aug 16, 2012 at 02:46:58AM +0200, Patrick Mylund Nielsen wrote:
Blizzard Entertainment has been receiving a lot of flak from tech and mass
media lately for choosing to employ SRP in their Battle.net clients and
games. A lot of these outlets have been suggesting that SRP is weaker
than
On Thu, Aug 16, 2012 at 02:25:34AM +0200, Patrick Mylund Nielsen wrote:
PBKDF2 is certainly decent, and often the easiest choice if you intend to
comply with e.g. FIPS 140-2/ISO 27001, but the biggest argument against it
is that it _isn't_ difficult to parallelize, since it is just e.g.
