| 1 |
On Mon, Nov 20, 2017 at 9:00 PM, R0b0t1 <r030t1@×××××.com> wrote: |
| 2 |
> Hello friends! |
| 3 |
> |
| 4 |
> On Wed, Nov 15, 2017 at 3:02 PM, Robin H. Johnson <robbat2@g.o> wrote: |
| 5 |
>> Replying to your original question here, to repeat the answer I emphasised |
| 6 |
>> before, along with significantly more detail in the history of Portage hashes |
| 7 |
>> (pulled from my notes back to GLEP57 and some minor updates). |
| 8 |
>> |
| 9 |
>> On Wed, Nov 08, 2017 at 12:57:49PM -0600, R0b0t1 wrote: |
| 10 |
>>> These posts are concerning because it looks like someone became stir |
| 11 |
>>> crazy and invented a problem to solve. The changes proposed to date |
| 12 |
>>> have remained poorly justified, and no one has addressed the concern |
| 13 |
>>> that multiple hashes *is* actually more secure. |
| 14 |
>>> |
| 15 |
>>> If it was deemed necessary at one point, what justification was used? |
| 16 |
>>> I.e. https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence. |
| 17 |
>> On Wed, Nov 15, 2017 at 11:47:41AM -0600, R0b0t1 wrote: |
| 18 |
>>> Does the existence of a decision mean I would need to contact the trustees |
| 19 |
>>> if I feel the changes have not been adequately justified? |
| 20 |
>> |
| 21 |
>> In GLEP59, I referenced a paper by Joux [J04], in which it was shown that a |
| 22 |
>> concatenation of multiple hashes is NOT much more secure against collisions |
| 23 |
>> than the strongest of the individual hashes. |
| 24 |
>> |
| 25 |
>> That was cited as original logic in GLEP59 for the removal of SHA256 (that |
| 26 |
>> removal was never implemented). WHIRLPOOL & SHA512 were kept out of an |
| 27 |
>> abundance of caution at the time, mostly to implementation bugs in hashes (as I |
| 28 |
>> have referenced in the related threads since). |
| 29 |
>> |
| 30 |
>> Your logic regarding removing something you think I don't understand is wrong |
| 31 |
>> (Chesterton's Fence): |
| 32 |
>> |
| 33 |
>> If you dig in the history of Portage, you will see that it's always been valid, |
| 34 |
>> to have just a SINGLE hash for each file in a Manifest. Required hashes has |
| 35 |
>> NEVER contained more than one hash. |
| 36 |
>> |
| 37 |
>> If multiple hashes are present, then Portage will validate all of them, but a |
| 38 |
>> potential attacker can still modify the Manifest and have only a single hash |
| 39 |
>> listed. Exactly which hash MUST be present has changed over time. |
| 40 |
>> |
| 41 |
>> Manifest1 is very old, and was stored in $CAT/$PN/files/digest-$P |
| 42 |
>> Manifest2 is the current $CAT/$PN/Manifest (and soon in more locations per MetaManifest). |
| 43 |
>> |
| 44 |
>> 1999/xx/xx: Portage starts with Manifest1 format, MD5-only (CVS) |
| 45 |
>> 2004/08/25: Portage gets SHA1 support in Manifest1, but is problematic, SHA1 generation manual only. |
| 46 |
>> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/pym/portage_checksum.py?revision=1.1&view=markup |
| 47 |
>> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/pym/portage.py?r1=1.485&r2=1.486 |
| 48 |
>> 2005/12/19: Portage Manifest1 supports MD5,SHA1,SHA256,RMD160, but still requires only a single hash present. Generates MD5+SHA256+RMD160. |
| 49 |
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=cd3e3775966a9f58aebb91f58cbdb5903faad3de |
| 50 |
>> 2006/03/24: Manifest2 introduced. |
| 51 |
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=f993747ca501e8a70d6f6174711149a172cfc3c2 |
| 52 |
>> 2007/01/20: MANIFEST2_REQUIRED_HASH introduced, SHA1, it must be present & pass |
| 53 |
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=e768571187d1655fbb558c23d61fa2983e48e411 |
| 54 |
>> 2007/12/18: MANIFEST1_REQUIRED_HASH introduced, MD5, it must be present & pass |
| 55 |
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=d9b10deaa03ce174d5ccc3b59c477549ad87e884 |
| 56 |
>> 2008/02/28: Manifest1 support dropped. |
| 57 |
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=66940e1f2f0549ee8f01dad59016e168105e193d |
| 58 |
>> 2011/10/02: GLEP59 implemented, MANIFEST2_REQUIRED_HASH changes to SHA256 |
| 59 |
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=c8cd3a985cc529299411d7343a11004b7d1330ef |
| 60 |
>> 2017/06/15: MANIFEST2_REQUIRED_HASH changes to SHA512 |
| 61 |
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=e6abcc0b7cbdca481862a5c7cca946c01c471ffb |
| 62 |
>> |
| 63 |
>> [J04] Joux, Antoie. (2004). "Multicollisions in Iterated Hash Functions - Application to Cascaded Constructions;" |
| 64 |
>> Proceedings of CRYPTO 2004, Franklin, M. (Ed); Lecture Notes in Computer Science 3152, pp. 306-316. |
| 65 |
>> Available online from: http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf |
| 66 |
>> |
| 67 |
> |
| 68 |
> This is the information I was looking for, thank you. I feel that the |
| 69 |
> matter has been adequately explained. I apologize for missing your |
| 70 |
> response. |
| 71 |
> |
| 72 |
> The paper gives a counter intuitive result, so I suspect I will have |
| 73 |
> to spend more time with it. |
| 74 |
> |
| 75 |
|
| 76 |
I appreciate the thought that robbat2 gave to his response, but I |
| 77 |
would like to clarify that it is beyond and above what I expected. |
| 78 |
|
| 79 |
What I wanted to avoid was something I encountered on the GCC mailing |
| 80 |
list: When I asked why GCJ was removed, I was told that it was hard to |
| 81 |
maintain. When I asked for an example of past maintenance issues (and |
| 82 |
made it clear I had no interest in disputing whether the issues were |
| 83 |
valid or not) I received no reply from the maintainer except his |
| 84 |
original answer, leaving me to wonder whether GCJ was actually hard to |
| 85 |
maintain. |
| 86 |
|
| 87 |
I have seen similar exchanges associated with other projects. |
| 88 |
|
| 89 |
Cheers, |
| 90 |
R0b0t1 |
Archives