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: Fri, 19 Sep 2014 09:38:00 +0200
From: Dmitry Khovratovich <>
To: "" <>
Subject: Re: [PHC] Missed opportunity re: unpredictable addressing?

If the memory access pattern depends on the salt, it is still known at the
time of computation so that the necessary data can still be prefetched from
the memory.

On Fri, Sep 19, 2014 at 5:59 AM, Alex Elsayed <> wrote:

> On the bus home today, I realized something - I've seen a number of
> discussions regarding the relative merits of password-dependent access
> (foil
> deeply-pipelined/prefetching attackers) vs. no-secret-data-dependent-access
> (foil timing attacks), and I think they may both be satisfiable.
> In particular, a salt is defined as 1.) public and 2.) random. I suspect
> that salt-dependent, password-independent addressing might well prove a
> useful trick.
> It causes the access pattern of the scrambler to be unique per entry in the
> password DB, without leaking anything about secret data.
> I'm working on a PoC now (which may turn out to be a _real_ PoC, I'm no
> cryptographer :P) but I wanted to get the idea out there.
> The idea is that by executing a compute-hard function over the salt-derived
> lookup data at each step, we can further bound attackers. In fact, my PoC
> basically treats the salt the same as the password, except that it's also
> used to decide what to access (and as a seed for the memory-filling stage).

Best regards,
Dmitry Khovratovich

Content of type "text/html" skipped

Powered by blists - more mailing lists