Re: [gentoo-dev] Manifest2 hashes, take n+1-th: one hash to decide them all

[R0b0t1]

On Tue, Oct 24, 2017 at 9:40 PM, Robin H. Johnson <robbat2@g.o> wrote:
> On Tue, Oct 24, 2017 at 11:33:39PM +0200, Allan Wegan wrote:
>> >> That is currently the case with portage, but not an inevitable
>> >> consequence of having 3 hash functions in the Manifest. Portage could
>> >> be made to check only one or two of them (even by default), giving
>> >> the tie-breaking ability to those who need it, and speeding up things
>> >> for those who don't.
>> > No, it can't. The specification (GLEP 59) requires it to check all
>> > hashes.
>>
>> Of course it can: The code of the specification just has to be changed
>> before changing the code of portage. The question is not whether it is
>> possible to make portage skip hash verification - but whether it is a
>> good idea to make it do that...
>>
>> I would not mind as long as the default is to always check all the
>> hashes and the option to disable it is properly named (like
>> "--disable-hash-verification" or something similar) and documented.
> At that point, and this is a serious proposal:
> The package manager shall decide which hashes to check, but is required
> to check at least one hash. The choice may be 'fastest', 'most secure',
> or any local factor.
>
> For local values of 'most secure' or 'fastest'.
>
> I wrote GLEP59, and specified at the time that all hashes should be
> checked, based on prior experience with hash implementation problems.
>
> Skipping them entirely is a bad idea, but only checking one of them is a
> reasonable suggestion.
>

The talk on gentoo-dev related to the security of hash functions still
has me confused as to why anyone would want to remove the
alternatives. Arguably this gives the setup most of its security.

I acknowledge Mr. Böck's observation that most programs only use one
hash. When I first encountered portage, I thought the use of multiple
hashes was a very novel and security conscious design choice. The cost
is negligible compared to the difficulty it adds to generating a
collision.

Of course, the difficulty of generating a collision that results in
usable code is still very high, but there was an interesting paper
that described how it could be easier than most people think. I am not
sure how to find it again. It was based on the principle that the
solution space for collisions that were valid was actually far denser
than the solution space of all collisions. One of the results of this
is that finding usefully malicious collisions is probably easier than
finding a collision in general, although there may be more non-useful
collisions overall.

> I retract my prior suggestion that there should be 3 hashes, as I
> realize a key statements in GLEP59 that were NEVER implemented:
>>> - Removal of depreciated checksums shall happen after no less than 18
>>>   months or one major Portage version cycle, whichever is greater.
>>> ...
>>> After the majority of Portage installations include SHA512 support:
>>> - Remove SHA256.
>
> This GLEP to update the GLEP59 specification should state the following:
> - The package manager or verification tool is required to verify at
>   least one hash, preferably the strongest supported hash.
> - Multiple hashes may be present for transitional periods.
> - SHA3 or BLAKE2B shall be added to the official Manifest2 hashes.
>


I'm still kind of confused as to why these changes are being made. Can
they be justified?

> For implementation:
> - Generation of WHIRLPOOL and SHA256 shall be disabled in the next
>   Portage minor release (as soon as possible)
> - Generation of the next choice of hash, SHA3 or BLAKE2B shall be
>   enabled in an upcoming minor Portage release (soon)
> - 18 months after the next GLEP is approved, SHA512 shall be dropped
>   (put the date into the Portage code so it happens automatically this
>   time, unlike SHA256 that should have been removed in 2010!).
>

This makes sense, but I would hope deprecation can be justified in a useful way.

Cheers,
     R0b0t1