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: <CAOqphBeXbZEx=C+DqA9A_xXWOgrOCdH_7JDG_AUBb+p2Aj_U+g@mail.gmail.com>
Date: Sat, 27 Sep 2014 02:23:02 +0530
From: Sweta Mishra <swetam@...td.ac.in>
To: discussions <discussions@...sword-hashing.net>
Subject: Re: [PHC] Sincere apology to the RIG team

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:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
>
> iQIcBAEBAgAGBQJUIr73AAoJEAcQZQdOpZUZbwUQAIFn6ERJda8v4ydyTVv9CG7M
> eCFw1XnKTfoZ7BsX389QVk39IN+Lz8vULeP6C2S21rBcS0xdUOlyDxePo2np2cZz
> ir+LSSg4dQ8ZMjmEWugYICC143IMGpoLQjlb5C3NrV4iddqAu/HS1C3oMVebbkFR
> SBSKxKVJK2S6NzxBbs8gche1EhmkyMGwaZrDKXv0zWT5FJypJ70WkVwEOxr9baHm
> KY0G8qm3nWqRB5LIFjvEFifN0Z2oKrEmqRTfYvvCJycR3tYO6LLOkbjXI+yck0dL
> fx91I3I4ijIZn6GTYMXLlCz8PmBFltH+nbrVhVCtquYZlIKKTWLBCjxcuAA6vthg
> /3DgYcRHP6fJdYJvQH2yn2pt0GBAEzbQSHzjbY14uazTPLzfC0VDQS1bL5wUG5bo
> /D90SiqHVJAm3ROGDYURHnlK36nZPllPAry9MPltzU3FoT2HXA/eJy1ewpRNnJGm
> iKt6B7sx2VnQptsKAtZFXM6fNtGdMwnAjAGsC1jrWz2A5UpgYRMcMVTOTQC+pZRz
> Cv2m8arwZREZoo7raHlI12zEoIfx3hfIn6bc65r5XqXz+ms/Xakz1K/pNoksCoHo
> 64xOq24B5FCvKz2Nksrh0XbRrpxQ3jj1eVjzRsYzNauvOvqrbJK7sd/x7+saihD7
> l61XZZW/5ufBr4JD6o4j
> =ogmF
> -----END PGP SIGNATURE-----
>

Content of type "text/html" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ