lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Apr 2013 08:00:55 -0700
From: bitweasil Bitweasil <>
Subject: Re: [PHC] Let's not degenerate when if the PRF is too narrow for
 desired output

> So unless you are storing a several kilobyte hash there is almost no
difference in time.

"I'd tell 'ya what I'd do with a 3 character password.  4096 bytes of
encryption key at the same time."

On Wed, Apr 17, 2013 at 7:50 AM, Steve Thomas <> wrote:

> **
>  > On April 17, 2013 at 7:25 AM Matthew Green <>
> wrote:
> >
> >
> > I think this statement could be relaxed a bit, but I also agree that
> overall computational cost should be dominated by the work factor specified
> as input to the function -- it should not depend strongly (i.e., linearly)
> on output length.
> >
> > This would be a real issue in an authentication system where the
> defender was generating long 'hashes' but an attacker could save cycles by
> only computing a shorter prefix to test against.
> >
>  The problem is that people don't know that PBKDF2 is for generating keys
> and not password hashes. Even Microsoft gets this wrong:
>  The correct way to use PBKDF as a password hash:
>  * hash = Encrypt(PBKDF2(pw, salt, iterations, keySize),
> staticOrKnownText) // Encrypt(key, message)
>  * hash = MAC(PBKDF2(pw, salt, iterations, keySize), staticOrKnownText) //
> MAC(key, message)
>  * hash = PBKDF1(pw, salt, iterations, keySize) // I don't think this is
> an approved use of PBKDF1, but I see nothing wrong with it. I.E. don't use
> this.
>  not:
>  * hash = PBKDF2(pw, salt, iterations, keySize)
>  In the case with AgileBits, they are generating a key and an IV and only
> the key is needed to verify the padding. This would have been a non-issue
> if AgileBits took the first 128 bit as the IV and the second 128 bits as
> the key. Although with access to SIMD instructions, such as SSE2, there is
> little to no difference in time between PBKDF2_HMAC_SHA1(pw, salt,
> iterations, 128) and PBKDF2_HMAC_SHA1(pw, salt, iterations, 256).
>  > By the way, this would seem to be an issue for scrypt as well, since it
> uses PBKDF2 for the final generation.
> >
>  No this is not a problem with scrypt because it uses an iteration of 1
> with PBKDF2. This is after the hard part is done which takes a few
> milliseconds. So unless you are storing a several kilobyte hash there is
> almost no difference in time.
> > We should discuss whether we want this to be a criteria for PHC.
> >
>  This is already in a sense is a requirement, but this is impossible to
> follow perfectly. With all hash functions you can do an early exit to skip
> a couple steps, but with properly iterated hashes this saves an almost
> negligible amount of time. Also early exit is not allowed by the defender
> since this leaks info about the stored hash.

Content of type "text/html" skipped

Powered by blists - more mailing lists