[Slackbuilds-users] Retire MD5 for SHA256

[David O'Shaughnessy]

On 08/10/2018 11:24 PM, Tim Dickson via SlackBuilds-users wrote:
> my 2cents worth...
> if it aint broke...
> well, the argument is that it is broke, but... using hash collisions 
> means either the source can be compromised, in which case it is not
> reliable, or the compromise is done on the network, in which case the
> network is not reliable.
>  If either network or source are not reliable, then the expected
> checksum - whatever method used could simply be set to match the
> interfered-with source code, so the attacker would not need to "crack"
> the checksum, they could just make what was visible match their version
> of the compromised source.

If SBo maintainers are generating authentic MD5 checksums in the first
place (i.e., GPG verifying the upstream signatures, assuming that they
exist), and SBo admins are then signing off on those checksums, then it
seems unlikely that an attacker could modify the source and the expected
checksums too. However, a subsequent malicious alteration that utilizes
hash collisions (which would seem to be an ideal situation for an
attacker, short of gaining access to signing keys) is undetectable since
the SBo user, in the end, is left with only an MD5 sum as their link to
archive integrity.

The problem then is that the MD5 cannot guarantee that a given (future)
source archive is identical to the one that the maintainer originally
downloaded, and that the SBo admin signed off on. Obviously though if
the attacker has access to the upstream signing keys then it's busted
from the start and the whole checksum thing is irrelevant anyway.

> In other words, as a basic download file corruption check, md5 is simple
> and convenient; any other assumptions about security depend on other
> variables far more than the type of checksum used.

True, it's convenient for that and there are many other variables, but
having the user rely on MD5 still seems like an unnecessary weak spot to me.

--
Dave