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  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: Thu, 25 Jun 2015 00:31:50 +0000
From: Marsh Ray <>
To: "" <>
Subject: RE: [PHC] Why protect against side channel attacks

>  However, it is expensive per password cracked, similar to an off-line attack, maybe 2-6X cheaper.

Keep in mind about half of typical users tend to pick passwords from the 10,000 most common. For this huge set of users, a successful side channel leak means they are compromised, regardless of it taking *amortized* 6x more work for the attacker.

-          Marsh

From: Bill Cox []
Sent: Wednesday, June 24, 2015 5:21 PM
Subject: Re: [PHC] Why protect against side channel attacks

On Wed, Jun 24, 2015 at 12:12 PM, Greg Zaverucha <<>> wrote:
Suppose you use password hashing function X in many products and services, in a range of contexts (on mobile devices, PCs, servers, in VMs, etc…).  Now suppose that cache-timing attacks against X are shown to be practical, someone has released an attack tool, and it’s in the news under the name PasswordBleed, and someone has even made a logo for it.  The tool needs the salt and username.  It works by observing the cache access pattern of a victim process/VM, which narrows down the search space to a set of passwords small enough to attack online (i.e., the tool re-computes the hashes for passwords in a dictionary and compares their access patterns to the observed pattern, those that are close are kept). So no breach has occurred and no hashes were leaked.  (I realize that in most systems the salts aren’t public, but I think we all agree that X should not get weaker if the salt is known).

While this is true, I still would prefer to see a "main" winner that uses a hybrid architecture, with a cache-timing resistant first loop followed by an unpredictable memory access loop (like Scrypt and Lyra2, and Yescrypt in Scrypt compatible mode).  As a special additional category, I'd also like to see a "cache-timing resistant" winner, with the understanding that most users would be advised to use the "main" winner.

Here's the trade-off I see in security for a hybrid architecture like Lyra2 vs a pure cache-timing resistant architecture like Catena/Argon2i:


- An attacker with usernames and salts, who can mount a cache timing attack and associate the cache timing signatures with user accounts, can recover the password and does not require a password hashes to do it.  However, it is expensive per password cracked, similar to an off-line attack, maybe 2-6X cheaper.
- Without the salts, an attacker can still see when cache-timing signatures re-occurred, leaking knowledge of when users login.
- The hybrid architecture retains full time*memory defense against common off-line attacks.
- The hybrid architecture retains full defense against common TMTO attacks.

Cache-timing resistant:

- Against the common off-line guessing attack, it will be 2-3X cheaper to crack passwords, since cache-timing-resistant algorithms run with 2-3X lower memory*time defense in general.
- Massively parallel attacks are more effective, since the data access pattern is known in advance.  Memory I/O can be heavily pipelined.
- In a TMTO attack, any required computations can be done in advance, since an attacker knows when the data is needed, speeding up the attack.
- In a TMTO attack, an attacker does fewer recomputations, since he can choose values to free from memory that he knows can quickly be recomputed.

I feel that the overall security advantage lies heavily with the hybrid architecture.


Content of type "text/html" skipped

Powered by blists - more mailing lists