Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Mar 2013 22:10:17 +0400
From: Solar Designer <>
Subject: Re: Intentionally Increasing Collisions in Password Hashing Algorithms


On Tue, Mar 12, 2013 at 03:10:28AM -0400, Matt Weir wrote:
> [...] an attacker can take a
> guess, encrypt it using the public key, and then compare it to the encrypted
> password.

Oh, I forgot to mention this detail.  I meant the "encrypt to public
key" at a high level, much like e.g. what GnuPG does, not literally (as
the only thing happening under the hood).

The actual implementation should have a random component involved (like
they usually do), which defeats the attack you've described.  It may
generate a random symmetric key, encrypt the full password hash with
that, encrypt the symmetric key with the public key (if RSA is used,
there will also be random padding here), and store only the
symmetrically encrypted hash and the asymmetrically encrypted symmetric
key.  The symmetric key itself and the unencrypted full hash are not to
be stored.

With this, it will be possible to decrypt the full hashes using the
private key, but not to test candidate passwords against the encrypted
full hashes.


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.