phc-discussions - Re: [PHC] Sincere apology to the RIG team

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]

Date: Wed, 24 Sep 2014 16:03:08 -0400
From: Jim Manico <jim@...ico.net>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Sincere apology to the RIG team

Everyone makes mistakes, owning up to those mistakes in public is rare. Keep on keepin' on, Bill!

Aloha,
--
Jim Manico
@Manicode
(808) 652-3805

> On Sep 24, 2014, at 8:54 AM, 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-----