Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends) (http://www.linux-archive.org/debian-development/711573-debian-should-move-away-md5-best-also-sha1-secure-apt-friends.html)

Andrey Rahmatullin 10-11-2012 06:42 PM

Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
 
On Thu, Oct 11, 2012 at 08:18:55PM +0200, Kurt Roeckx wrote:
> 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.
debsums(1) aka "what packages on my system are corrupt by a recent FS
failure"

--
WBR, wRAR

Kurt Roeckx 10-11-2012 10:35 PM

Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
 
On Fri, Oct 12, 2012 at 12:42:57AM +0600, Andrey Rahmatullin wrote:
> On Thu, Oct 11, 2012 at 08:18:55PM +0200, Kurt Roeckx wrote:
> > 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.
> debsums(1) aka "what packages on my system are corrupt by a recent FS
> failure"

I know about debsums, I just don't find it useful.

For the case of corruption I would either use backups or
reinstall the whole thing. If there is corruption it
ussually screws up more than the files covered by the md5sums.


Kurt


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

Charles Plessy 10-11-2012 10:43 PM

Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
 
Le Thu, Oct 11, 2012 at 08:18:55PM +0200, Kurt Roeckx a écrit :
>
> MD5 is covered by policy, and it's the only mentioned in policy,
> maybe that should change.

Hi Kurt and everybody,

For control files, Checksums-Sha1 and Checksums-Sha256 are covered in chapter
5, where they are marked as recommended.

-----------------------------------------------------------------------------
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Checksums

These multiline fields contain a list of files with a checksum and size for
each one. Both Checksums-Sha1 and Checksums-Sha256 have the same syntax and
differ only in the checksum algorithm used: SHA-1 for Checksums-Sha1 and
SHA-256 for Checksums-Sha256.

Checksums-Sha1 and Checksums-Sha256 are multiline fields. The first line of
the field value (the part on the same line as Checksums-Sha1: or
Checksums-Sha256:) is always empty. The content of the field is expressed as
continuation lines, one line per file. Each line consists of the checksum, a
space, the file size, a space, and the file name. For example (from a .changes
file):

Checksums-Sha1:
1f418afaa01464e63cc1ee8a66a05f0848bd155c 1276 example_1.0-1.dsc
a0ed1456fad61116f868b1855530dbe948e20f06 171602 example_1.0.orig.tar.gz
5e86ecf0671e113b63388dac81dd8d00e00ef298 6137 example_1.0-1.debian.tar.gz
71a0ff7da0faaf608481195f9cf30974b142c183 548402 example_1.0-1_i386.deb
Checksums-Sha256:
ac9d57254f7e835bed299926fd51bf6f534597cc3fcc52db01 c4bffedae81272 1276 example_1.0-1.dsc
0d123be7f51e61c4bf15e5c492b484054be7e90f3081608a55 17007bfb1fd128 171602 example_1.0.orig.tar.gz
f54ae966a5f580571ae7d9ef5e1df0bd42d63e27cb505b2795 7351a495bc6288 6137 example_1.0-1.debian.tar.gz
3bec05c03974fdecd11d020fc2e8250de8404867a8a2ce8651 60c250eb723664 548402 example_1.0-1_i386.deb

In the .dsc file, these fields should list all files that make up the source
package. In the .changes file, these fields should list all files being
uploaded. The list of files in these fields must match the list of files in the
Files field.
-----------------------------------------------------------------------------

For MD5, it is only mentionned in the description of the Files field (same
chapter), in appendix D about other control fields (MD5sum), and in appendix E
about configuration file handling.

Please let us know if there is something else missing about SHA-1 or SHA-256
checksums.

Cheers,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121011224310.GA12464@falafel.plessy.net">http://lists.debian.org/20121011224310.GA12464@falafel.plessy.net

Christoph Anton Mitterer 10-12-2012 12:30 AM

Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
 
On Thu, 2012-10-11 at 20:18 +0200, Kurt Roeckx wrote:
> 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.
Ah? Ok... I somehow had in mind that a) generating the "stronger" ones
was just optional,... and that they were not yet everywhere verified.


> So basicly the question is if we want to keep the md5 and sha1 in
> those files or not.
Probably... and nothing speaks against adding sha512... or (once it has
been well introduced) Keccack.


> MD5 is covered by policy
:-/


> , and it's the only mentioned in policy,
> maybe that should change.
Guess so.


> 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.
Well these are the ones for dpkg, aren't they?
Where it was mentioned before, that they are not primarily intended for
security (but where I replied, nothing keeps users from using them for
this purpose).


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


I further looked around:
e.g. the Release file seems to only use MD5.... not so good :(



Sources files seems to use MD5, SHA1 and SHA256... though MD5 seems to
have a "special status" (Files vs. Checksums-<algo>).
That might be just historic, though.

Similarly the Packages files... MD5/SHA1/SHA256...

If they are all checked (and verification is considered to be failed if
a single one doesn't match)... then I guess I'm quite happy. Though I
would still think, that on a mid-/long-term-range it doesn't harm to
drop MD5/SHA1 e.g. in favour of SHA512/Keccack.



> > 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?
That would be good :)



Cheers,
Chris.

Bob Proulx 10-12-2012 01:57 AM

Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
 
Kurt Roeckx wrote:
> Andrey Rahmatullin wrote:
> > Kurt Roeckx wrote:
> > > 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.
> > debsums(1) aka "what packages on my system are corrupt by a recent FS
> > failure"
>
> I know about debsums, I just don't find it useful.
>
> For the case of corruption I would either use backups or
> reinstall the whole thing. If there is corruption it
> ussually screws up more than the files covered by the md5sums.

The use case for debsums is for *detection* of corruption. And
neither is it a security mechanism. But it is a useful integrity
check mechanism.

Bob

Paul Wise 10-12-2012 02:09 AM

Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
 
On Fri, Oct 12, 2012 at 8:30 AM, Christoph Anton Mitterer wrote:

> I further looked around:
> e.g. the Release file seems to only use MD5.... not so good :(

Wrong, the Release file has had all 3 since sarge. woody had MD5 & SHA-1.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAKTje6F-37FUhWCGFNXMU-mD-quTORa6MWJewXhRzFUeHG7i9g@mail.gmail.com">http://lists.debian.org/CAKTje6F-37FUhWCGFNXMU-mD-quTORa6MWJewXhRzFUeHG7i9g@mail.gmail.com

Paul Wise 10-12-2012 02:14 AM

Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
 
On Fri, Oct 12, 2012 at 8:30 AM, Christoph Anton Mitterer wrote:

> Sources files seems to use MD5, SHA1 and SHA256... though MD5 seems to
> have a "special status" (Files vs. Checksums-<algo>).
> That might be just historic, though.
>
> Similarly the Packages files... MD5/SHA1/SHA256...

Only since wheezy has that been true for all files listed in
Packages/Sources though. squeeze Packages is missing SHA-1 and SHA-256
for 1905 binary packages.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAKTje6EHRFK2Qj7H7A4=UF3SqnroEMeAd4xA=Pfzum8=A7sLW g@mail.gmail.com

"Bernhard R. Link" 10-12-2012 07:17 AM

Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
 
* Christoph Anton Mitterer <calestyo@scientia.net> [121011 19:39]:
> 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.

There is a disadvantage of having longer hashsums, thus making it harder
for people to compare. The only reason that for those md5 is optimal and
not crc32 is that there is only one md5 and there is a nice always
available tool to compute it, so people can compare it more easy.

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

Everything doing something like that can also create those sha2 sums on
their own and use them. Using the debsums system (which has no security
part at all) will only weaken security. So I think what you say is an
argument for keeping md5sum, so that noone think they can use that
information for security.

Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121012071732.GA4094@client.brlink.eu">http://lists.debian.org/20121012071732.GA4094@client.brlink.eu

"Adam D. Barratt" 10-12-2012 07:26 AM

Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
 
On 12.10.2012 01:30, Christoph Anton Mitterer wrote:

I further looked around:
e.g. the Release file seems to only use MD5.... not so good :(


You didn't look very far / well.

$ wget -O- -q http://ftp.debian.org/debian/dists/squeeze/Release | grep
-v "^ "

Origin: Debian
Label: Debian
Suite: stable
Version: 6.0.6
Codename: squeeze
Date: Sat, 29 Sep 2012 11:31:27 UTC
Architectures: amd64 armel i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips
mipsel powerpc s390 sparc

Components: main contrib non-free
Description: Debian 6.0.6 Released 29 September 2012
MD5Sum:
SHA1:
SHA256:

Please check more carefully before making such assertions.

Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8de9b71d74d88d059285a00be8b529b5@mail.adsl.funky-badger.org">http://lists.debian.org/8de9b71d74d88d059285a00be8b529b5@mail.adsl.funky-badger.org

David Kalnischkies 10-12-2012 11:10 AM

Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
 
On Thu, Oct 11, 2012 at 7:38 PM, Christoph Anton Mitterer
<calestyo@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAAZ6_fAgOpwsdmmjZXm5P_UocZ0CjEsx=oHoe2gG_ryBwNcGx Q@mail.gmail.com


All times are GMT. The time now is 02:08 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.