[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOLP8p5QwtrdemWeym-gmmezYQoz0NFPk1c0crbcND2r06JaNA@mail.gmail.com>
Date: Wed, 8 Jan 2014 16:49:42 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
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.
Bill
Content of type "text/html" skipped
Powered by blists - more mailing lists