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] [day] [month] [year] [list]
Date: Mon, 22 Sep 2014 07:50:26 +1000
From: Rade Vuckovac <rade.vuckovac@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Schvrch is broken

"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)."

Yes carry % (m_cost * statelen) is correct.

Rade

On Fri, Sep 19, 2014 at 10:24 PM, Bill Cox <waywardgeek@...hershed.org>
wrote:

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

Content of type "text/html" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ