phc-discussions - Re: [PHC] Initial hashing function. Feedback welcome

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <op.w8zcittsyldrnw@laptop-air.hsd1.ca.comcast.net>
Date: Tue, 31 Dec 2013 15:21:55 -0800
From: "Jeremy Spilman" <jeremy@...link.co>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Initial hashing function. Feedback welcome

If you're willing to make a trivial modification the PBKDF2, you don't  
have to keep the password around past even the first hash...

PBKDF2:
      result = step = HMAC(Password, Salt || 1)
      for 2..n
         result ^= step = HMAC(Password, step)

Modified:
      result = HMAC(Password, Salt)
      for 2..n
         result = HMAC(Salt, result)

Or if for some reason you really want to XOR 'step' into 'result' (in  
order to prevent hypothetical short cycles, which SHA256 protects against  
anyway)...

      result = step = HMAC(Password, Salt)
      for 2..n
         result ^= step = HMAC(Salt, step)


On Tue, 31 Dec 2013 08:48:39 -0800, Bill Cox <waywardgeek@...il.com> wrote:

> On Mon, Dec 30, 2013 at 8:42 PM, Solar Designer <solar@...nwall.com>  
> wrote:
>>> - 2048 rounds of PBKDF2_SHA256 are used at the start to generate an
>>> intermediate derived key.
>>
>> I dislike this.  It's very wasteful in use cases where our total running
>> time is very limited.  This may be all running time we can afford (if at
>> all), not leaving any time for the memory-hard portion.
>
> I made the number of SHA-256 rounds selectable, from 1 up.
>
> I don't think I described the purpose of the sha256 rounds very well.   
> 2048 rounds takes 2.5ms on my linux box using scrypte's sha256.c for  
> PBKDF2->SHA256 key derivation.  If I do this and then clear the  
> password, the plaintext password is only there for 2.5ms.
>
> After that, I do a huge memory hash, and I feel it is common for this  
> sort of memory hog of a process  get swapped out (if mlock is disabled  
> or not >working or available).  Maybe other processes will be swapping  
> and the whole thing is so slow that the user closes his laptop, and  
> hibernation writes >out the contents of RAM to SSD, where files aren't  
> even erased if you overwrite them with 0's.  By doing that 2.5ms of key  
> derivation as a pre-process, >which is tiny compared to the 1s-ish  
> desired for a strong KDF, we make it harder for an attacker to discover  
> the password.  Even if he extracts the >intermediate derived key, he'll  
> need a decent graphics card to get enough speed to brute-force attack a  
> password which is protected with 2048 rounds >of SHA256.  With custom  
> hardware, the 2048 rounds provides essentially zero protection, but how  
> many password crackers out there have such >custom hardware?  Surely the  
> NSA, but hopefully not many scammers.  My personal preference would be  
> to devote about 1% of the key hashing time >to this task, which on my  
> machine would be 8192 rounds.
>
> There's a lot of talk about not writing data derived from the password  
> data to memory to avoid such an attack, but I've convinced myself that  
> we have >to write password-derived data to memory to build a memory-hard  
> KDF, There seems to be no way around it.  I prefer for that data to be  
> somewhat >safe - not NSA safe, but average-joe cracker safe.
Content of type "text/html" skipped