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.