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: Fri, 10 Jan 2014 11:32:11 -0800
From: Andy Lutomirski <>
To: discussions <>
Subject: Re: [PHC] What's your favorite entry so far, and why?

On Fri, Jan 10, 2014 at 11:02 AM, Bill Cox <> wrote:
> On Fri, Jan 10, 2014 at 11:34 AM, Christian Forler
> <> wrote:
>>> My only  gripe is that if I'm going to spend 1
>>> second on a KDF, I'm going to want to hash a lot of memory.  Script's
>>> speed (about 1/4 GB/second on my development machine) should be
>>> considered the lower bound on acceptable efficiency, IMO.
>> "Of course it is not secure, but look how fast it is!" :-)
> Surely security comes first.  It is unclear to me under what
> conditions Catena will be more secure than scrypt.  Catena and any KDF
> hashing L2 resident memory wins in a way that I think is more
> significant than timing attacks: leaked memory, due to swapping,
> hibernation, core dumps, or failure to clear after freeing.  Scrypt
> wins vs FPGA and ASIC attacks due to the memory bandwidth limit on
> FPGAs and ASICs, even if Scrypt could be several times better than it
> is in this regard.  Scrypt security is pretty good.  I'd prefer that a
> successor be clearly capable of winning in all these situations,
> including FPGA and ASIC attacks.  As I said, I think there's no reason
> Catena can't get there.
>>> There is no reason Catena has to run slowly, and I haven't looked at the
>>> code, so I don't know what efficiency changes have been made.  For
>>> example, you could run with two rows small enough to fit in L1 cache,
>>> and then do a ton of rows, followed by a final round that hashes all
>>> memory from all rows 4KB at a time.
>> Nope. We are not interested that Catena can not efficiently computed
>> without tones of  L1 and L2 cache misses since this also effects
>> the performance of GPU implementations.
> This is a very interesting point.  Catena, with efficient enough inner
> loop hashing, should be pretty secure against GPU attacks, and going
> to external GDDR5 DRAM just means they're stuck with the same cache
> miss penalties you are.  That's a good thing, because it gives you a
> bunch of cycles to catch up on the hashing.
> However, vs FPGAs and ASICs, an attacker can use QDR SRAM from Cypress:
> An FPGA can have several of these bad-boys off chip, and according to
> Cypress, they're 45X lower latency than DDR3.  I've not checked that
> math, but its an issue to worry about.

Those things are expensive (~$2/Mbit).  I guess that means that
they're comparable in price to CPU cache, which is good.


> Bill

Andy Lutomirski
AMA Capital Management, LLC

Powered by blists - more mailing lists