phc-discussions - Re: Some KDF stumbling blocks, plus Common "memory-hard" approaches and amortized attack costs.

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]

Date: Sat, 13 Dec 2014 04:30:54 +0000 (UTC)
From: Adam Back <adam@...herspace.org>
To: discussions@...sword-hashing.net
Subject: Re: Some KDF stumbling blocks, plus Common "memory-hard" approaches and amortized attack costs.

Jeremy Spilman <jeremy@...> writes:
> What I've been calling Blind Hashing takes the bounded retrieval model  
> (wish I knew that term back in 2012!) and combines it with delegation to a  
> untrusted central data pool using a keyed hash to adaptively index the  
> data pool and retrieve a second [512-bit] salt/key for use in further  
> hashing.

interesting idea, but if the remote site is supposed to trust the security
of your server (if they dont they can break in and do ram reads at high
speed without restriction) then you could as easily use D_k( h ) with 
some defences against repeated probing of h values and save
the storage?

I suppose your point is that even if they do that they cant exfiltrate
the memory while they can ex-filtrate k.  Well I reckon you could fix
that robustly and fairly easily with a hardware implementation of D 
that keeps k in the hardware.  (That would be a compact hw 
implementation of what you did in software basically, plus it
can be even larger because k can be a 128-bit key).

Anyway just to add some comments and design permutations that you
probably considered.

Adam