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  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


Powered by blists - more mailing lists