Dnia 23 października 2017 10:16:38 CEST, "Robin H. Johnson" <robb...@gentoo.org> napisał(a): >On Fri, Oct 20, 2017 at 05:21:47PM -0500, R0b0t1 wrote: >> In general I do not mind updating the algorithms used, but I do feel >> it is important to keep at least three present. Without at least >three >> (or a larger odd number) it is not possible to break a tie. >> >> That may ultimately be beside the point, as any invalid hashes should >> result in the user contacting the developers or doing something else, >> but it is hard to know. >I'm dropping the rest of your email about about exactly which hashes >we're bike-shedding, to focus on the number of hashes. > >I agree with your opinion to have three hashes present, and I've give a >solid rationale with historical references. > >The major reason to have 3 hashes, is as a tie-breaker, to detect if >there was a bug in the hash somehow (implementation, >compiler/assembler, >interpreter), and not the distfile. This also strongly suggests that 3 >hashes should have different construction.
1. How are you planning to distinguish a successful attack against two hashes from a bug in one of them? 2. Even if you do, what's the value of knowing that? > >It's come up enough times in Gentoo history already. Here's 3 of the >instances that came to mind and I could link up with bugs easily. I >also >recall an instance where the entire SHA2 family was bitten by a buggy >arch-specific (mips? arm?) GCC patch, but I can't the bug for it. > >2006: https://bugs.gentoo.org/121182 >pycrypto RMD160 on ia64 (and many other 64bit arches) >(it also had a big cleanup for the tree as a result: >https://bugs.gentoo.org/121124) > >2009: https://bugs.gentoo.org/255131 >app-crypt/mhash-0.9.9 segfaults with NULL digest in whirlpool/snefru >(portage uses python-mhash bindings) How is this one relevant? AFAICS it did not cause wrong result. > >2012: https://bugs.gentoo.org/406407 >sys-apps/portage-2.1.10.49: internal version of whirlpool algorithm >generates wrong hash > >Since we're going to much newer hashes, I think there is a non-zero >chance we WILL hit errors in the hashes again, and it would be wise to >cover the bases. > >This ends up probably looking like: SHA512, BLAKE2B, SHA3_512 -- Best regards, Michał Górny (by phone)
