lists.openwall.net   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: Thu, 18 Sep 2014 09:50:08 -0400
From: Peregrine <peregrinebf@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] omegacrypt and timing

On 09/18/2014 05:07 AM, epixoip wrote:
>
> On 9/17/2014 6:58 PM, Peregrine wrote:
>> If we had a widely used password hash function that was extremely
>> secure against offline attacks but leaked enough timing
>> information for attackers to find the password, then offline
>> attacks would severely decline and timing attacks would rise.
>
> descrypt, bcrypt, and scrypt all have theoretical timing attacks,
> yet offline attacks for these algorithms have certainly not
> declined.
>
> I believe a timing attack that actually reveals the password is
> pretty far-fetched. The best you can probably hope for is leaking
> some information that enables early-reject for offline attacks,
> and that's provided you have the hash+salt in addition to the side
> channel. And if an attacker only has the side channel and doesn't
> have the salt, the side channel attack is largely irrelevant.

The lack of decline in offline attacks against descrypt, bcrypt, and scrypt
indicates that it's cheaper/easier to do than to use a timing attack. A
goal of this contest is to improve upon these algorithms' offline attack
resistance.  If this improvement is wildly successful then it could become
cheaper/easier to use a timing attack or other side-channel. Thus, it's
probably worth having a side-channel resistant portion to a design, as long
as the design as a whole is sufficiently strong against offline attacks and
adding the resistant portion does not compromise security elsewhere.

On Thu, Sep 18, 2014 at 9:12 AM, Bill Cox <waywardgeek@...hershed.org>
wrote:

> It does make the algorithm more complex.  It's not an easy call.  I
> consider several entries that make no attempt at timing defense of any
> kind as still strong candidates.  I would rather have one of those
> defending my passwords than a pure timing-attack resistant algorithm.
>  Unpredictability puts extra hurt on brute-force attackers.
>

Agreed.  The current state of the art doesn't have good timing defense, and
has some weaknesses to offline attacks (eg low-memory scrypt on GPUs.) A
stronger but non-timing resistant algorithm would still be an improvement:
timing and other side-channel attacks will still be expensive/difficult to
pull off, and the overall success of password cracking should go down. A
timing-resistant first loop just provides security against a possible
future attack type. That's good to have, but not strictly necessary the way
offline attack resistance is.

Content of type "text/html" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ