* Harald Braumann <ha...@unheit.net> [100303 14:49]: > As a means to check for filesystem corruptions or non-malicious changes, > MD5 is good enough. So until we have something better, I guess they can > stay.
I'd even say they should stay. The shorter the hash the more useable. And md5 is the shortest well-defined and readily available everywhere. > But it would be great if the whole chain, from beginning to end, was > secured, even against a malicious and presumably very powerful attackers. Checksums for files coming from packages is not really useful to defend against attackers (it's really only reliablity and not security): - an attacker can just divert any binary away and put it's own there. - an attacker can just add some additional binary where it will override another one (/sbin overriding /usr/sbin and so on). - an attacker can add things to configuration and startup files (thanks to .d directories you often not even need changing but only adding files), including search binary or library paths, so one could add binaries or behaviour changing libraries in directories not looking that suspicious. Most of those things can perhaps be fixed, but it needs much work than just replacing some hash. (And many of those tasks might also improve other areas (like http://packages.debian.org/cruft also having the problem that packages create so many files and there is no way a package can tell such programs where they are). > For the hash I would skip SHA-1 and move directly to SHA-256. And not to forget to add the size. Being allowed to create arbitrary large files makes attacking interated hashes much easier... Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100303141608.ga21...@pcpool00.mathematik.uni-freiburg.de
