On Thu, Oct 11, 2012 at 7:38 PM, Christoph Anton Mitterer
<cales...@scientia.net> wrote:
> algo,... not to mention that newer algos like Keccack are quite fast.
I wonder if it is really a good idea to search for a security checksum
based on the metric that it can be quickly calculated … but off-topic.
>> 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.
I think adding "better" checksums here would just encourage people to
think that they could be used in a security relevant way.
And carrying bigger/more checksums around just means that we waste
everyones diskspace to keep up the illusion of security for some people.
> Anyway... I guess it was clear, that I rather meant secure APT... dsc
> files, Release.gpg, etc. pp.
APT will usually negotiate the checksum to use based on what it supports
and what is included in the Release file.
Supported is currently in squeeze (in wheezy):
MD5, SHA1, SHA256(, SHA512)
Usually found in a Release file is currently:
MD5, SHA1, SHA256
so it will take SHA256 and be done with it. apt-ftparchive/wheezy will
generate SHA512 by default as well, I am not sure about dak or others,
but that isn't really a problem just yet.
This falls apart of course as soon as RSA (or whatever ftpmasters will use
in this dystopia) is broken, but I guess we have a problem then anyway.
So dropping MD5 and/or SHA1 would be okay I guess, note through that
apt-get --print-uris outputs md5sum by default as some scripts can't cope
with other checksums. See #576420 as an example why, so you would need
to find and fix these scripts first I guess (or just break them of course).
There is one exception: pdiffs work entirely with SHA1, were is some work
pending on the dak side, I guess while incorporating them into APT we could
work on that. In case of an emergency you could just disable that optional
feature of course (user as well as server side). And in the end of all days,
really interesting is only a pre-image attack, collision is kinda boring …
Oh, and there is "Description-md5". I can't imagine a scenario in which it
would be useful to change the English description of a package for an attack
(which you want to hide by displaying the translations of the not modified
version), but feel free to be the first to launch a successful pre-image
attack on long descriptions (with the "side" problem of not changing size
and checksum of the [compressed] Packages file including the description).
Beside, for Debian this "attack" becomes easier now as the translation is
split out and the md5sum therefore pre-calculated, so you can write whatever
you want in the Translation-* files as a description without caring for
Description-md5 ("side" problem still applies though).
Best regards
David Kalnischkies
--
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/CAAZ6_fAgOpwsdmmjZXm5P_UocZ0CjEsx=ohoe2gg_rybwnc...@mail.gmail.com
