|
Message-ID: <038601ce1f8f$995bd5c0$cc138140$@edu> Date: Tue, 12 Mar 2013 22:08:03 -0400 From: "Matt Weir" <cweir@...edu> To: <crypt-dev@...ts.openwall.com> Subject: RE: Intentionally Increasing Collisions in Password Hashing Algorithms Solar, Oh hey, that would work really well! Sorry I misunderstood you earlier. That helps a lot since I certainly didn't have a good answer to that problem. Matt -----Original Message----- From: Solar Designer [mailto:solar@...nwall.com] Sent: Tuesday, March 12, 2013 2:10 PM To: crypt-dev@...ts.openwall.com Subject: Re: [crypt-dev] 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.