Re: Time to replace MD5?
Bernd Eckenfels [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED] you wrote: I don't understand why DSAs for etch include md5sums and manual upgrade instructions at all. Apt can verify the checksum and gpg signature and handle the upgrade after all, and probably more securely than the average user following the manual instructions. Because open source is all about choice. There might be admins using dpkg -i or security officers who build their local mirrors manually. Then they can wget the Release.gpg file, Release file, Packages file and check each in turn. Their choice. As for local mirrors: debmirror and reprepro already check the Release.gpg file if wanted and anybody using something else to mirror should do so too. So both aren't really good arguments to complicate the mails. Gruss Bernd MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
* Steffen Schulz: On 070613 at 10:43, Florian Weimer wrote: AND the fact that it needs to be a valid .deb archive, they are probably more than strong enough. This is actually not much of a problem: http://www.cits.rub.de/MD5Collisions/ One example how to create two files with same hash that act differently. Should work with most active content. The problem is ambiguous content, not the collision. This has been thoroughly debunked, I don't know why they continue publishing this. It's easy to exploit their fictional document signing process without creating an MD5 collision, which strongly suggests (proves) that the process itself is flawed. Since you are located at RUB, could you please make sure that they correct their analysis? Kaminsky did the same with self-extracting executables: http://www.doxpara.com/md5_someday.pdf Yeah, but the evil twins must be created *by* *the* *same* *party*. In the Debian case, this party is already trusted, so the current attacks make no difference. That, and the evil twin package would have to be prepared by the securty team as well, which isn't a relevant scenario (because they could put a backdoor in the original without attacking the hash). So apt-get signatures use a secure hash function? Secure against currently known attacks, yes. And we can distribute a new hash function to clients pretty easily (something which is quite unusual). With the above results, it would be possible to officially distribute nice behaving software but present specific targets with modified packages that do evil. Yeah, right. Guess what? Distributors can do this even without using MD5 attacks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
* Steffen Schulz: If for whatever reason people get untrustworthy, it would be nice to know as soon as possible, no? Government, Money, .. Well, in this case, you're barking up the wrong tree. What you really want is some kind of audit trail, which might increase confidence in the integrity of the package creation process. A chain of cryptographic hashes which is put in place at the very end of that process is *not* an audit trail. It only secures distribution across the mirror network, and MD5 is currently good enough for that. Using SHA-384 for this purpose might even give a wrong sense of security. And again, this is just one attack vector. To check the impact and list the mitigating factors sure is good for employment. Security design is something else. Security design is mostly about risk analysis. If you built security in from the start, it's unlikely your system will ever make it to the point where you see actual attacks (which means, in most systems: fraud). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
In article [EMAIL PROTECTED] you wrote: Then they can wget the Release.gpg file, Release file, Packages file and check each in turn. Their choice. Which is much more complicated than checking a given fingerprint (which is very usual for Advisories) Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
On 070614 at 00:00, Michael Stone wrote: On Wed, Jun 13, 2007 at 11:14:15PM +0200, Steffen Schulz wrote: http://www.cits.rub.de/MD5Collisions/ One example how to create two files with same hash that act differently. Should work with most active content. Cool. So the security team can rig an executable that can be modified and still have the same md5. Point was: md5 collisions are a real-world problem. With the above results, it would be possible to officially distribute nice behaving software but present specific targets with modified packages that do evil. Yup. Or the security team could just plant a regular backdoor, [..] The critical bit was included in the sentence you removed: What hashes does apt-secure use? Judging from this documentation, md5 is used for apt-secure, too: http://people.debian.org/~walters/monk.debian.net/apt-secure/x35.html So every maintainer could distribute nice binaries and then inject malicious packets to certain targets. The overall point of writing my comment: Don't check all conditions, protocols, use cases. Just replace md5 some time soon. If you don't trust the security team, you probably shouldn't install security updates. Sorry for being unclear, Steffen -- Um sich in einer Schafherde wohlzufühlen, muss man vor allem Schaf sein. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
On Thu, Jun 14, 2007 at 11:37:33AM +0200, Steffen Schulz wrote: On 070614 at 00:00, Michael Stone wrote: On Wed, Jun 13, 2007 at 11:14:15PM +0200, Steffen Schulz wrote: http://www.cits.rub.de/MD5Collisions/ One example how to create two files with same hash that act differently. Should work with most active content. Cool. So the security team can rig an executable that can be modified and still have the same md5. Point was: md5 collisions are a real-world problem. If they are, you've failed to show it. With the above results, it would be possible to officially distribute nice behaving software but present specific targets with modified packages that do evil. Yup. Or the security team could just plant a regular backdoor, [..] The critical bit was included in the sentence you removed: What hashes does apt-secure use? Judging from this documentation, md5 is used for apt-secure, too: http://people.debian.org/~walters/monk.debian.net/apt-secure/x35.html So every maintainer could distribute nice binaries and then inject malicious packets to certain targets. Every maintainer can do that without dicking around with md5 collisions. If you don't trust the security team, you probably shouldn't install security updates. Sorry for being unclear, If you don't trust the debian maintainers, you probably shouldn't install debian. Sorry for being unclear. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
On 070614 at 13:40, Michael Stone wrote: So every maintainer could distribute nice binaries and then inject malicious packets to certain targets. Every maintainer can do that without dicking around with md5 collisions. Not as good. The chances of detection grow with the install base. If you don't trust the debian maintainers, you probably shouldn't install debian. Trust is something that is to be reduced where possible. If for whatever reason people get untrustworthy, it would be nice to know as soon as possible, no? Government, Money, .. And again, this is just one attack vector. To check the impact and list the mitigating factors sure is good for employment. Security design is something else. I don't say it's highly critical. But usage of md5 and sha-1 should be discouraged. The attacks will only get better. Systems should migrate, however slow they think is appropriate. /Steffen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
* Henrique de Moraes Holschuh: On Tue, 12 Jun 2007, Touko Korpela wrote: Debian Security Advisories currently contain MD5 checksums. As MD5 is no longer strong enough, maybe it should be replaced by SHA1 or SHA256? When combined with size information Size information doesn't buy you that much. AND the fact that it needs to be a valid .deb archive, they are probably more than strong enough. That, and the evil twin package would have to be prepared by the securty team as well, which isn't a relevant scenario (because they could put a backdoor in the original without attacking the hash). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
On Wed, 13 Jun 2007, Florian Weimer wrote: On Tue, 12 Jun 2007, Touko Korpela wrote: Debian Security Advisories currently contain MD5 checksums. As MD5 is no longer strong enough, maybe it should be replaced by SHA1 or SHA256? When combined with size information Size information doesn't buy you that much. When we are talking about a binary blob that matches the *same* md5sum? Yes, it does. Causing a MD5 colision with a message of the same size is far more difficult. AND the fact that it needs to be a valid .deb archive, they are probably more than strong enough. That, and the evil twin package would have to be prepared by the securty team as well, which isn't a relevant scenario (because they Would it? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
On Wed, Jun 13, 2007 at 10:37:26AM -0300, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Wed, 13 Jun 2007, Florian Weimer wrote: On Tue, 12 Jun 2007, Touko Korpela wrote: Debian Security Advisories currently contain MD5 checksums. As MD5 is no longer strong enough, maybe it should be replaced by SHA1 or SHA256? When combined with size information Size information doesn't buy you that much. When we are talking about a binary blob that matches the *same* md5sum? Yes, it does. Causing a MD5 colision with a message of the same size is far more difficult. Especially when it has to be a valid .deb file (which means an ar archive of 2 correctly gzipped tar files) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
On Tuesday 12 June 2007 22.41:23 Touko Korpela wrote: Debian Security Advisories currently contain MD5 checksums. As MD5 is no longer strong enough, maybe it should be replaced by SHA1 or SHA256? Strong enough for what? You can get an md5 collision quite easily, but is 2nd preimage also broken? Note that you'd not only need a 2nd preimage for a given .deb, but the resulting file also needs to have the same size as the original and be a valid deb package. quite a lot of conditions there. cheers -- vbi -- OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481 signature.asc Description: This is a digitally signed message part.
Re: Time to replace MD5?
Mike Hommey wrote: On Wed, Jun 13, 2007 at 10:37:26AM -0300, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Wed, 13 Jun 2007, Florian Weimer wrote: On Tue, 12 Jun 2007, Touko Korpela wrote: Debian Security Advisories currently contain MD5 checksums. As MD5 is no longer strong enough, maybe it should be replaced by SHA1 or SHA256? When combined with size information Size information doesn't buy you that much. When we are talking about a binary blob that matches the *same* md5sum? Yes, it does. Causing a MD5 colision with a message of the same size is far more difficult. Especially when it has to be a valid .deb file (which means an ar archive of 2 correctly gzipped tar files) But did somebody check if dpkg handle correctly (error) if there are extra data after a gz or at the end of a dpkg? ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
* Henrique de Moraes Holschuh: Size information doesn't buy you that much. When we are talking about a binary blob that matches the *same* md5sum? Yes, it does. Causing a MD5 colision with a message of the same size is far more difficult. Oh, in this case, please show us a collision of two messages of 641 and 642 bytes. 8-) AFAIK, the currently published attacks do not work well against the final block with padding, so it's still not possible to change the length. AND the fact that it needs to be a valid .deb archive, they are probably more than strong enough. That, and the evil twin package would have to be prepared by the securty team as well, which isn't a relevant scenario (because they Would it? With the currently published attacks, yes. If significantly better attacks appear, they might also apply to message digests in the same family, so this is only a slightly convincing argument for replacing MD5 with SHA-1 (or even SHA-256 ). Actually, there isn't much Debian can do, other than to wait. We don't share many of the problems because or protocols are proprietary, and we've got a working software distribution process to end users. Lots of other stuff (especially in the IETF context, think appliances) needs to preserve interoperability with other people's code, or can't be field-upgraded. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
On 070613 at 10:43, Florian Weimer wrote: AND the fact that it needs to be a valid .deb archive, they are probably more than strong enough. This is actually not much of a problem: http://www.cits.rub.de/MD5Collisions/ One example how to create two files with same hash that act differently. Should work with most active content. Kaminsky did the same with self-extracting executables: http://www.doxpara.com/md5_someday.pdf That, and the evil twin package would have to be prepared by the securty team as well, which isn't a relevant scenario (because they could put a backdoor in the original without attacking the hash). So apt-get signatures use a secure hash function? With the above results, it would be possible to officially distribute nice behaving software but present specific targets with modified packages that do evil. Workaround would be to check two hashes(md5,sha1) or an XOR of them. /pepe -- # (o_ #+49/1781384223 //\-xgpg --recv-key A04D7875 V_/_Use the source, Tux! mailto: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
On Wed, Jun 13, 2007 at 11:14:15PM +0200, Steffen Schulz wrote: On 070613 at 10:43, Florian Weimer wrote: AND the fact that it needs to be a valid .deb archive, they are probably more than strong enough. This is actually not much of a problem: http://www.cits.rub.de/MD5Collisions/ One example how to create two files with same hash that act differently. Should work with most active content. Cool. So the security team can rig an executable that can be modified and still have the same md5. With the above results, it would be possible to officially distribute nice behaving software but present specific targets with modified packages that do evil. Yup. Or the security team could just plant a regular backdoor, and not worry about the md5 hash. A sha hash isn't going to change that at all. If you don't trust the security team, you probably shouldn't install security updates. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
On Tue, Jun 12, 2007 at 07:39:38PM -0400, Joey Hess wrote: Bernd Eckenfels wrote: Because open source is all about choice. So it's there because of a platitude? There might be admins using dpkg -i or security officers who build their local mirrors manually. Then why don't we include md5sums and wget commands for all packages in stable point release annoucements? Why not include them in major release announcements too? Or are these things somehow less all about choice? Yes, there are a lot of us who use dpkg -i, and do it very often. I may be missing something in this thread because it seems to blatently obvious to me that this is a necessary and important tool that I am having difficulty understanding where this is going. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Time to replace MD5?
Debian Security Advisories currently contain MD5 checksums. As MD5 is no longer strong enough, maybe it should be replaced by SHA1 or SHA256? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
On Tue, 12 Jun 2007, Touko Korpela wrote: Debian Security Advisories currently contain MD5 checksums. As MD5 is no longer strong enough, maybe it should be replaced by SHA1 or SHA256? When combined with size information AND the fact that it needs to be a valid .deb archive, they are probably more than strong enough. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
Touko Korpela wrote: Debian Security Advisories currently contain MD5 checksums. As MD5 is no longer strong enough, maybe it should be replaced by SHA1 or SHA256? I don't understand why DSAs for etch include md5sums and manual upgrade instructions at all. Apt can verify the checksum and gpg signature and handle the upgrade after all, and probably more securely than the average user following the manual instructions. It may have made sense before we had signed Release files, (or perhaps before we had apt :-), but it feels obsolete now. Note that DTSAs already only include apt upgrade instructions. -- see shy jo signature.asc Description: Digital signature
Re: Time to replace MD5?
On Wed, Jun 13, 2007 at 12:40:41AM +0200, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: I don't understand why DSAs for etch include md5sums and manual upgrade instructions at all. Apt can verify the checksum and gpg signature and handle the upgrade after all, and probably more securely than the average user following the manual instructions. Because open source is all about choice. There might be admins using dpkg -i or security officers who build their local mirrors manually. There may also be admins who prefer to use ar and run the maintainer scripts by hand, and of course they are free to do so. But, imo, Debian should document a single recommended procedure - and direct execution of dpkg isn't something I'd recommend. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to replace MD5?
Bernd Eckenfels wrote: Because open source is all about choice. So it's there because of a platitude? There might be admins using dpkg -i or security officers who build their local mirrors manually. Then why don't we include md5sums and wget commands for all packages in stable point release annoucements? Why not include them in major release announcements too? Or are these things somehow less all about choice? -- see shy jo signature.asc Description: Digital signature
