[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

On Thu, 2012-10-11 at 11:35 -0500, Peter Samuelson wrote:
> What makes sense is to use a hash that has the properties that are
> needed for a particular application.
Well... I think that's only really required if performance is very
critical, e.g. when you're on embedded devices or so,... but the places
I've mentioned should have probably no disadvantages by using a "strong"
algo,... not to mention that newer algos like Keccack are quite fast.

> To use your example of dpkg file checksums, their purpose has _nothing_
> to do with security.
Well their _intended_ purpose,.. that's right.
But nothing keeps people from using it a security manner (e.g. by
replication it to a "secure" remote node or so).... and in fact... e.g.
rkhunter already has a mode where it uses DPKG directly.

>   They cannot protect against a malicious attacker,
> because an attacker who can corrupt /usr/bin/lsof can also corrupt
> /var/lib/dpkg/info/lsof.md5sums.
Yeah see above... if you have "plain" dpkg,... then yes... but people
may impose further measure to secure these sums (replicating them to
other nodes or attaching MACs to these files as XATTRs, etc. pp..)...
this does not necessarily mean that I'd suggest such things (cause
people should rather use AIDE or friends then).

> Rather, the checksums are for integrity checking in the face of disk
> corruption or administrative snafu.  Basically to answer the question
> "Would it help to reinstall this package?"  MD5 is perfectly well
> suited for that.
In principle you're right here,... and I also use it just for that
purpose... but as said above,... we cannot know what people do... and if
dpkg would have generic mechanisms for storing the sums (e.g. all
in /var/lib/dpkg/info/lsof.sums)... nothing would IMHO speak against
using a "stronger" algo per default.

Anyway... I guess it was clear, that I rather meant secure APT... dsc
files, Release.gpg, etc. pp.

> the
> common knee-jerk reaction "oooh, MD5 is weak, it must be replaced!"
> every time someone sees MD5.  (Or SHA-1.)
Well I quite clearly said, that I wouldn't consider especially the later
as broken.... but experience has shown that such migrations can take
quite some time... and these estimations showed that collisions for even
SHA-1 are not out of the world...


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: