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

Powered by blists - more mailing lists