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]
Message-ID: <2bd3ad7b10fa4b42b2350570dcfb1827@BLUPR03MB166.namprd03.prod.outlook.com>
Date: Wed, 7 Aug 2013 20:11:29 +0000
From: Marsh Ray <maray@...rosoft.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] Re: scrypt like hash, but with AES and HMAC-SHA-2

> -----Original Message-----
> From: Alex Elsayed [mailto:eternaleye@...il.com]
> Sent: Tuesday, August 6, 2013 9:59 PM
> It's one thing to assume the
> attacker has more parallelism available, but they also can simply parallelize
> their inputs.

Agree. The attacker has basically unlimited parallelism available in the forms of candidate input generation as well as usually also multiple target hashes he needs to attack.

> Although that does bring up an interesting thought: What about driving up
> the cost via multithreading *badly*? Use nonlocal data by a data-dependent
> schedule, forcing either frequent IPI/cache coherency traffic (high-
> parallelism user) or frequent task switches (low-parallelism user)?

Crossed my mind as well. Since A cares less about single-evaluation latency than D, it seems like A can opt to implement such an algorithm serially if that is beneficial.

So maybe this degenerates into the "unpredictable memory accesses are more bad for A than for D"  principle?

> > * Well defined character encoding: UTF-8
> 
> That actually needs more info in order to be 'well-defined' - what
> normalization form are you using? NFC? NFD?

PHC submissions should be well-defined over all byte vector inputs for password and salt, i.e., "8-bit clean". But we may suggest some guidance on character encoding for interoperability. There was strong consensus at the first meeting about ensuring compatibility with the modern /etc/password format.

This stuff seems largely independent of the submission, so designers can just think in terms of byte vectors and not worry about encoding and representation details.

- Marsh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ