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, 8 Jan 2014 16:49:42 -0500
From: Bill Cox <>
Subject: Re: [PHC] A final cheat killer pass with smoke

I meant to run a post-process to a KDF like Catena that runs for a short
time compared to the main Catena, and in this pass it would use the
password for accessing random locations that had been generated by Cantena.
 Being able to detect a password change is a problem, but we could hide it
with smoke.

It's more useful for the the case of multi-threading.  I currently let the
user specify T threads, and if I have M memory locations, each thread
simply hashes it's own M/T block of memory, and the results are hashed
together.  The problem with this is an attacker could decide to run them
one at a time to save memory at the cost of increased time, or vise versa,
giving the attacker TMTO flexibility.

To remove that flexibility, I could do a lengthy final pass that hashes
them all together Catena-style.  It would have to be long because if I only
accessed 1% of the memory, an attacker might only store those.  However, if
I hashed 1% of the memory in a password dependent style, the attacker wont
know before hand which memory locations I am going to access, so he has to
keep most or all of it.  Basically, it would let me eliminate the TMTO,
with only a 1% runtime penalty, but at the cost of password dependent
accesses, which is why I'm interested in hiding it with smoke.

At some point the complexity isn't worth it.  This may be beyond that point.


Content of type "text/html" skipped

Powered by blists - more mailing lists