phc-discussions - Re: [PHC] Schvrch is broken

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: <541C2064.5030203@ciphershed.org>
Date: Fri, 19 Sep 2014 08:24:04 -0400
From: Bill Cox <waywardgeek@...hershed.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Schvrch is broken

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/17/2014 11:41 PM, Rade Vuckovac wrote:
> Hi Bill
> 
> 
> 
> Please find schvrch2prelim.h attached.
> 
> 
> 
> Memory cost attempt:
> 
> - write to the memstate is done by state stir stream
> 
> - read is done by getting index of current carry modulo memstate
> array size and reading memstate element with that index
> 
> - read result modifies mixer
> 
> - until next read, stir is run to produce a new current carry (it
> runs statelen times but that can be fine tuned)
> 
> - hash is just a partial final state (every 8th word provides one
> byte =

This is better.  This code stops the strong TMTO attack, as well as
the attacks on evolve and revolve, and it's even simpler.  Very nice!

The t_cost loop is still not right, but applying t_cost securely isn't
how Schvrch will likely be judged, so let's not worry about that for now.

I think you have an operator precedence error on the line that adds
memstate to mixer.  In C, that will be interpreted as (carry % m_cost)
* statelen.  I think you meant carry % (m_cost * statelen).

While I think this is secure hashing, experts (meaning not me) in
hashing will have to help here.  I would have thought Keccak is secure
without the LFSR, and according to Wikipedia, it "breaks symmetry".  I
don't know what that means, but without the LFSR, Keccak is using one
of Wolfram's rules for it's nonlinear mixing.  I think the addition
operation with the mixer should be enough, though, for secure hashing,
in my poorly-informed opinion.

Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUHCBgAAoJEAcQZQdOpZUZ9YMP/0EHxcGUSV/tYRHwI9QiA0IY
PQRrccQfljU0yAhQqJPvu5TKnl4wc3KGXRohy0JwIfEzf+mYoAcnZSrzIALaU8sl
ajr1U8PR0o0/jzSeFAMB/GtIUSZ/8JJzEO1Wf91cvOl5dSqUr+L54EBR4Py+u/aY
pyp+6PZnas6F2qtExJqYt7lT37Hcn+AM03adRTghH/ioHvlIB/yYBMy8Kix36DjO
3pz5oYNu9hjxmunQaEwuBVkWw9T0a+PT9HIi1miaDrFB96a+0m9u7VC+JtQtlHGR
tGt9sT31PZ7zrCJsGokvePP5tbpMmB9PBZSjU5MXAPkob/iyB+LSi4qU070tJw98
nZpJ+8Py8FwXZRsvt8tc4FnGCfaIumeUy/7rzMkfUmQwMfurNASy64u2eZ7KEJYG
Nqr+VzZsjaDv67H00nhMlHVPGm2N1KlapSzjMFDadcvuYgh9OlqJFDxc/HFCaFBR
WIToY+A7mllg9gR7An/0aheFa/kJmARAtAXbL8Z3MEdM30MUMhLlXj9RwoH3lWxU
WfN9WgbaHWiI2Rvm0xw/V6AjgWBgjlBpsHgyei/IRJChXHRmGGJGJ9yrplf2kNMS
of+bbpfY4+dOCqAmjOHE23hv/BGLGnfXM2iOiFxoy5GZ1SVvv1/WsDsRFrgK52fu
qSgocZbPK3HGqlXTNCMy
=gfk0
-----END PGP SIGNATURE-----