Date: prev next · Thread: first prev next last
2017 Archives by date, by thread · List index


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@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



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.