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... Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature