sha1sum problem

[Michael Stahl]

On 24.02.2017 16:45, Bryan Quigley wrote:
> I'm going to look at adding the SHA256SUM for all the files in
> download.lst.  It looks like we can add them without breaking
> anything.  Then we can test out how we want to switch or if we need to
> support both for a bit (platform dependent?).

right, and as just discussed on IRC that can even be done without having
to rename all the md5-containing filenames on the server, by adding a
variable for the SHA256SUM and just ignoring the hash contained in the
filename.

> On Fri, Feb 24, 2017 at 10:25 AM, Stephan Bergmann <sbergman at redhat.com> wrote:
>> On 02/24/2017 03:47 PM, Norbert Thiebaud wrote:
>>>
>>> The situation with checksum of 'external' files is much worse that you
>>> thought.
>>> They are actually checked with md5.
>>> That being said they are not truly external, since they are hosted on
>>> the project infrastructure

>>> and the original motivation was not so much malicious injection
>>> detection but faulty transfer.
>>> using sha1 there would actually be an 'improvement' :-)

actually AFAICS the MD5 usage here is not currently a problem.

there are 2 different problems with hash functions, collision attacks
and preimage attacks.

https://en.wikipedia.org/wiki/Preimage_attack

the big news about SHA1 is that somebody successfully performed a
collision attack, where they created 2 files from scratch that have the
same SHA1.

but here we have files that already exist and worry[1] that someone
could create another file with the same hash - that is a preimage attack.

https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability

	"In April 2009, a preimage attack against MD5 was published that breaks
MD5's preimage resistance. This attack is only theoretical, with a
computational complexity of 2^123.4 for full preimage."

the SHA1 collision brute-force require 2^80, and less with some clever
mathematical insight, so md5 preimage appears at least 2^43 harder.

still, if somebody wants to implement using a better hash function,
there is no reason to object :)

[1] unless the upstream that creates the tarball is actively malicious,
but in that case we have other problems