Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ