phc-discussions - RE: [PHC] Re: scrypt like hash, but with AES and HMAC-SHA-2

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: 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