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]
Message-ID: <5425FA69.3000904@ciphershed.org>
Date: Fri, 26 Sep 2014 19:44:41 -0400
From: Bill Cox <waywardgeek@...hershed.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Sincere apology to the RIG team

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

Excellent news.  I look forward to seeing the update!

Bill

On 09/26/2014 04:53 PM, Sweta Mishra wrote:
> Dear Bill,
> 
> Thanks for the encouraging words on our design Rig. We sincerely
> appreciate your comments. However, there is no need to apologize
> for the previous comments once you do not accuse us of any
> wrongdoing. Your earlier mails had raised some technical points as
> well, and some comments on the code too. We agree that we did not
> write the most efficient or most good looking code at the time of
> the submission since we felt that this was only intended to be a
> test implementation. Further, there was indeed a mistake in the
> bit-reversal permutation as we used it. We would like to thank you
> for carefully reading the code and pointing out the issues. We are
> currently revising the document as well as the code. We intend to 
> complete the work within this weekend and will post the revised
> document and the code by Monday. Hope you and the PHC will consider
> the revision within the scope, as we are only making slight changes
> to the previous version. We are also detailing the document a lot.
> Hopefully this will make it easier to understand how the design
> prevents various attacks.
> 
> You had made a positive comment on the speed of Rig. We are happy
> to inform that the new version of Rig code is "much" faster than
> the one we initially submitted. We now have an optimized
> implementation and as far as we can see, it is by far the "fastest"
> entry in the PHC in software platforms. Our team put a lot of
> effort in last few weeks to make the code this efficient.
> 
> Thanks again for your mail.
> 
> Regards, Sweta (on behalf of the Rig team)
> 
> 
> On Wed, Sep 24, 2014 at 6:24 PM, Bill Cox
> <waywardgeek@...hershed.org> wrote:
> 
> The worst mistake I made during my reviews was accusing the RIG
> team of trying to take credit for other people's ideas.  I still
> feel very bad about it.  I was wrong, and I was the one being
> dickish.  I strayed from attacking code into attacking authors, and
> that was stupid.
> 
> The RIG team independently came up with two great ideas.  First
> was using the reduced Blake2b round, including the exact code from
> the original author, just like the Lyra2 team.  This is a *very*
> high performance hashing function which makes RIG the clear speed
> leader in the cache-timing resistant category.  Second was XORing
> over data rather than overwriting it, strengthening their TMTO
> defense without causing much slowdown.  This helps correct a
> potential weakness covered by the Argon authors in their
> cryptanalysis of Catena.
> 
> They also came up with the idea of writing only part of the hash
> to memory, making it difficult to determine the Blake2b state.
> This is similar to how Lyra2 writes only part of their sponge's
> state to memory.  RIGs idea also can be used to reduce memory
> usage, which in some cases could be helpful.
> 
> The RIG team was creative and original.  Their code does need some 
> fixes, but I look forward to their update.  I found nothing in my
> code review that cannot be fixed with tweaks.  I certainly hope the
> judges did not take my tirade about RIG looking similar to other
> entries into account when picking round 2 candidates.
> 
> Before picking them for round 2, I would prefer to see a code
> update, but assuming it fixes the one critical bug, they seem like
> a strong entry to me, from a code point of view.
> 
> Bill
>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUJfpmAAoJEAcQZQdOpZUZ+dYP/0QyjQHKXIXZNY/E3cD87wTa
LA0tzpDFEH8z4gTyH+GyWr67NDmMp+id70KDS2rQZAXTvmvZZ6CQ/h1LLIxJPVJE
2rxWotwUGgq4KgDQJCo9LUbyxuMs2kHLYcXyzWsIzHiiW8iKvmld8Kjq5Q9pC3BU
KBCoJkZchzgAEXDK6fRNciiVuRIc39EdsepSV4qc2vihfjIqKgLcQyycqjbTZKUO
NTraa7uk0nf2lYo+Sz33QxoIUMQVhzFX3E+hS/ZqjIYJffOItUKJygf827R4Q3kO
aaQN/2CNCAv/CzPVQ6uRUAip0jZIwvlJHXRRqTMSB3ty8jn/33Hsd8VJYIrIyf84
eoOiwTzq4ZTadd77io8akd/RcpcYv9zw3gEkYntEqZKI8QOQ5eurCIdpUSkBWSuP
Q1FKOXu+PaocDYRKuc5dEEzRJ9wq1/gSCYiKTPrOwP1vc64aJrd0GJAhOuCrhxA7
0qwsbJCQzBId+G/wduRg4D/r6Z+sxFmJa1O0CHXAjlCbbiSJwGJK8RC3po+pAMch
szpk8zCFuDxhMY61OX1m5qG3VaiiZHrA3sSibgbJeyagvENYlDd6bb14RIEnZ0lE
FEq2WFbtFbG7lgym+qdXf8m+zw/e3Blj3erQ0rLX+APFHXagGLHpovLgRY3AxnnJ
+q2AtvDKqqOT7AnQX6ap
=ki5x
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ