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...


Cheers,
Chris.

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

On 2012-10-11 19:38, Christoph Anton Mitterer wrote:
> 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.

Debian on a low power embedded system fits in the "normal" category I
assume?
What is "embedded device" then?

--
brother
http://sis.bthstudent.se


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50770C0E.3010806@bsnet.se">http://lists.debian.org/50770C0E.3010806@bsnet.se

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

On Thu, Oct 11, 2012 at 01:19:58AM +0200, Christoph Anton Mitterer wrote:
> Hi folks.
>
> AFAICS, secure APT and similar things (e.g. dpkg's file hash sums) still
> use even MD5.

dpkg-genchanges and dak both generate md5, sha1 and sha256. So
.deb files themself are hashed by all 3 of them. A as far as I
know all tools that verify those files also check all 3 of those
hashes.

As far as I understand, there is no need to move away from sha256
to SHA-3 when it becomes available at this time.

So basicly the question is if we want to keep the md5 and sha1 in
those files or not.

MD5 is covered by policy, and it's the only mentioned in policy,
maybe that should change.

There are also the md5sums files that are stored in the .deb file.
I'm not really sure what the real use case for them is and
wouldn't have a problem with them going away.

Then there dpkg status file keeps track of config files with md5
to see if they changed on upgrade. I can see no good reason to
change this.

> Wouldn't it make sense to start discussions about moving to the
> "strongest" possible?

I see no reason why we can't also add SHA-3 to the files when the
tools become available.

> Or, like in the case of package files (dsc and friends) make a policy of
> verifying all hashes, and fail if any single doesn't match?

As far that's already the case?



Kurt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121011181855.GA8645@roeckx.be">http://lists.debian.org/20121011181855.GA8645@roeckx.be