[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130312181017.GA15025@openwall.com>
Date: Tue, 12 Mar 2013 22:10:17 +0400
From: Solar Designer <solar@...nwall.com>
To: crypt-dev@...ts.openwall.com
Subject: Re: Intentionally Increasing Collisions in Password Hashing Algorithms
Matt,
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.
Alexander
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.
