phc-discussions - "Slowing" down Keccak-f

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>] [day] [month] [year] [list]

Date: Mon, 16 Feb 2015 11:58:29 +0800
From: Ben Harris <mail@...rr.is>
To: discussions@...sword-hashing.net
Subject: "Slowing" down Keccak-f

I was looking at the "too fast" criticisms of the entries that are using
Keccak, and tried to use Bill's suggestion of multiplication and the
approach taken by Rabbit (http://www.ecrypt.eu.org/stream/e2-rabbit.html)
of squaring and XOR to reduce.

Without claiming to know enough about Keccak's randomness proofs, the
simplest spot to add a squaring is in the roh step on the lane[0][0]. The
roh step rotates each lane, but the first lane is left as is. This could
instead be squared and XOR-reduced. This is a 64->128 bit square (or chain
thereof) per round for Keccak[1600].

This adds another non-linear step to Keccak so would complicate the
existing analysis. I don't have the knowledge to know the security impacts,
but could this be a simple way to increase the time*area of an ASIC
implementation of PHC candidates?

Content of type "text/html" skipped