| Author |
Message |
Jochen Voss
*nix forums beginner
Joined: 03 Jul 2005
Posts: 25
|
 Posted: Tue Nov 29, 2005 5:50 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Hi Florian,
On Tue, Nov 29, 2005 at 03:24:54PM +0100, Florian Weimer wrote:
| Quote: | None, many of these examples were created before the collision
generation tools were generally available. The "exploit" uses some
properties of Postscript files which make them not very desirable for
storing electronic documents which cannot be altered.
Do you mean the ability to embed comments into the file? |
Several other formats allow this, too.
| Quote: | For example, it is possible to create a Postscript file whose
output, when printed, varies from printer to printer.
How is this related to their examples? |
| Quote: | (Note the "rub.de" part of the URL. A clear warning sign.)
This is the university of Bochum, Germany, isn't it? |
Should I be afraid of them?
All the best,
Jochen
--
http://seehuhn.de/ |
|
| Back to top |
|
 |
Peter Samuelson
*nix forums Guru Wannabe
Joined: 21 Feb 2005
Posts: 212
|
| Posted: Tue Nov 29, 2005 8:50 pm Post subject:
Re: Checksumming tool
|
|
|
[Adam Heath]
| Quote: | File: foo%20bar/hellurei.txt
Size: 12345
MD5: 012345667
SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a
Mode: 0644
Checksum:
md5: 0123456789[B
sha-256: 0a0a0a0a0a0a0a0a0a0a0a0a
|
Checksum: md5: 01230123012301230123012301230123
Checksum: rmd160: 4567456745674567456745674567456745674567
Checksum: sha256: iuHFIDSuhUHDiuhfidsuhf73w6fHSu3h2837f7FHJsg
I mean, if you're going to put a checksum on its own line, there's
plenty of room to give the hash name. (And yes I favor an extra space
there, it's ever so much more awkable.)
I still think rfc822 style is overkill, but at least this doesn't use
*yet another* line. |
|
| Back to top |
|
|
Colin Watson
*nix forums Guru Wannabe
Joined: 05 Apr 2005
Posts: 109
|
| Posted: Wed Nov 30, 2005 5:40 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Mon, Nov 28, 2005 at 07:07:22PM +1000, Anthony Towns wrote:
| Quote: | (Note that "dsum" would probably need to become Priority:required,
and possibly Essential:yes, with the complications that entails)
|
Stick it in dpkg.deb. There's plenty of precedent for that (some
not-so-good, but I think mostly good).
--
Colin Watson [cjwatson@debian.org]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Florian Weimer
*nix forums Guru
Joined: 19 Feb 2005
Posts: 418
|
| Posted: Wed Nov 30, 2005 5:41 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
* Henning Makholm:
| Quote: | Scripsit Florian Weimer <fw@deneb.enyo.de
* Jochen Voss:
I found the example at http://www.cits.rub.de/MD5Collisions/ quite
impressive. They have two different valid PostScript files with
identical MD5 sums. I don't know how much computing time they used,
though.
They claim a few hours:
| Based on [WY05] and the analysis described in [Da], we implemented
| an attack to find random collisions for the MD5 compression
| function. It took just a few hours on a customary PC.
|
I can no longer recall if this paragraph was present in the original
version of the page; I didn't notice it when I read it for the first
time.
| Quote: | None, many of these examples were created before the collision
generation tools were generally available.
They did create or use a collision, as anyone can verify simply by
downloading the files.
|
One collision was published by Wang et al. as a zero-knowledge proof
of their discovery. I thought they had reused this one, like many
others did.
| Quote: | The "exploit" uses some properties of Postscript files which make
them not very desirable for storing electronic documents which
cannot be altered.
There is absolutely no reason to put the word exploit in scare quotes
here.
|
Strictly speaking, you cannot exploit MD5 itself, you can only exploit
security systems that rely on some property of the MD5 function.
Let's look what happens in the attack published by the RUB
researchers:
1. The attacker creates two Postscript files with the same MD5 hash.
2. The attacker submits one of the file to the victim.
3. The victim views the file in his Postscript viewer, doesn't notice
anything strange, and signs it.
4. The attacker obtains the signature, and uses it together with the
second file he has created.
A successful attack is possible if the following conditions are met:
(a) the attacker can create a suitable collision, (b) the victim uses
the document supplied by the attacker, (c) the victim only checks one
presentation form of the document, and (d) the document is used in a
way which does not lead to the victim disputing the signature, and
into investigation (which would immediately reveal the attack).
It turns out that we can actually do without (a). Have a look at the
attached Postscript with your favorite Postscript viewer, and sign it
if you agree with its message. 8-)
In my opinion, this modified attack strongly suggest that the process
described above is already substantially broken. MD5 is just a weak
part among others. As a result, the attack doesn't show what people
claim.
Just be clear: I don't claim everything is alright with MD5. For most
applications, you should definitely migrate to something else (what is
a different question). But most organization's resources are limited,
you can't afford to migrate too often, and you deal with many issues
at once. Correctly analyzing the relevance of security issues is very
important. Misleading claims about the impact of new attacks are not
helpful, may lead to wrong allocation of resources, and prevent more
important vulnerabilities from being addressed.
| Quote: | You might want to notice that the "properties" you apparently think
invalidate the example are also shared by many common formats for
software. An ELF binary can easily be crafted to contain a blob of
initialized data whose contents are only used for checking whether to
enable some malicious machine code that is always present - and this
would not be easily detectable at all.
|
In general, any form of malicious code is not easy to detect. But the
malicious code must be present in the first place. You can use a MD5
collision to make it dormant, but it has to be there.
This means that it's dangerous to commit yourself to the contents of a
document, using a digital signature, unless you fully understand the
meaning of each byte in the document.
| Quote: | (Note the "rub.de" part of the URL. A clear warning sign.)
The nice thing about ad hominem arguments is that you can make them
without ever having to argue the merits of your case.
|
*shrug* The computer security folks at that university started
spreading FUD about various security systems, mainly rehashing the
work of others. They seem to be in it mostly for the publicity. |
|
| Back to top |
|
|
Colin Watson
*nix forums Guru Wannabe
Joined: 05 Apr 2005
Posts: 109
|
| Posted: Wed Nov 30, 2005 5:42 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Tue, Nov 29, 2005 at 02:20:55PM +0100, Florian Weimer wrote:
| Quote: | * Anthony Towns:
On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote:
In terms of security, there are some better hash functions.
My understanding was that there aren't other hash functions that've had
remotely similar levels of cryptographic analysis to md5 and sha.
Neither MD5 nor SHA1 have received much public scrutiny. Dobertin's
work on MD5 has never been fully published. I've already joked that
the difference between Wang et al. and European or U.S. cryptographers
is that the Chinese government doesn't tell their researchers not to
publish their results. 8-P
IIRC, the elliptic curve cryptography stuff was supposed to be
similarly neat, until people started analysing it seriously, at
which point it broke.
The NSA has recently licensed ECC patents from Certicom.
There are weak elliptic curves as far as cryptography is concerned,
but there are also others: inefficient ones and those which have been
patented by Certicom.
|
A cryptographer friend of mine recently attended the NIST Hallowe'en
Hash Bash (http://www.csrc.nist.gov/pki/HashWorkshop/index.html), and
made a few notes in his blog:
http://www.livejournal.com/users/sevenstring/7326.html
His suggestion there was "stick to SHA2 (or maybe Whirlpool) for now".
Did anyone else here attend this workshop?
That said, I suspect that any "my favourite algorithm" argument is going
to get horribly bogged down in bikeshedding. As long as we don't fall
into the multicollisions trap of spending more and more CPU time
generating and checking more and more iterative hash functions that
don't actually add significant collision-resistance when you check them
all together, a generalised checksumming tool as proposed seems an
obviously sensible and desirable thing to have.
--
Colin Watson [cjwatson@debian.org]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Anthony Towns
*nix forums Guru Wannabe
Joined: 06 Mar 2005
Posts: 274
|
| Posted: Thu Dec 01, 2005 2:00 am Post subject:
Re: dpkg-sig support wanted?
|
|
|
On Tue, Nov 29, 2005 at 02:20:55PM +0100, Florian Weimer wrote:
| Quote: | not even be out of the question to find someone who'll sponsor an upload
without rebuilding the .deb. I think it's safe to imagine that there are
developers right now who've done some shady things in the past; is it
that far fetched to imagine it's worth protecting against developers
who try to abuse their priveleges?
No, but they can directly upload a bad package. No need to create an
MD5 collision and sneak the "evil twin" package into some mirror
archive.
|
Sure; someday, maybe some of the test suite stuff will allow us to avoid
that, but at the moment we can't. What we can do now is limit the chances
that people will get away with that.
| Quote: | Have we already done that? Have we expelled people becaue they put
vulnerable code into Debian?
|
We've expelled people for violating the DMUP in other ways; and we've
stopped distributing micq because it included upstream code that could
reasonably be called an exploit.
| Quote: | You can embed code that checks for characteristics of the victim
system and activate the attack only if there's a match.
|
Sure, these things aren't perfect; but they're a help.
Anyway, I'm not going to waste my time further arguing why we shouldn't
continue using a hash that's had a practical exploit published on
slashdot.
Cheers,
aj |
|
| Back to top |
|
|
Henning Makholm
*nix forums Guru
Joined: 21 Feb 2005
Posts: 310
|
| Posted: Thu Dec 01, 2005 5:12 pm Post subject:
Re: dpkg-sig support wanted?
|
|
|
Scripsit Florian Weimer <fw@deneb.enyo.de>
| Quote: | This means that it's dangerous to commit yourself to the contents of a
document, using a digital signature, unless you fully understand the
meaning of each byte in the document.
|
So how do the MD5 sums of .debs end up in a Packages file signed with
the archive key? Do the ftpmasters go over each file with a
disassembler, fully understanding the meaning of each byte in the .deb?
| Quote: | (Note the "rub.de" part of the URL. A clear warning sign.)
The nice thing about ad hominem arguments is that you can make them
without ever having to argue the merits of your case.
*shrug* The computer security folks at that university started
spreading FUD about various security systems, mainly rehashing the
work of others. They seem to be in it mostly for the publicity.
|
More ad hominem arguing.
--
Henning Makholm "Jeg mener, at der eksisterer et hemmeligt
selskab med forgreninger i hele verden, som
arbejder i det skjulte for at udsprede det rygte at
der eksisterer en verdensomspændende sammensværgelse."
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Mike Paul
*nix forums beginner
Joined: 02 Dec 2005
Posts: 1
|
| Posted: Fri Dec 02, 2005 12:00 am Post subject:
Re: Re: dpkg-sig support wanted?
|
|
|
| Quote: | A cryptographer friend of mine recently attended the NIST Hallowe'en
Hash Bash (http://www.csrc.nist.gov/pki/HashWorkshop/index.html), and
made a few notes in his blog:
http://www.livejournal.com/users/sevenstring/7326.html
His suggestion there was "stick to SHA2 (or maybe Whirlpool) for now".
Did anyone else here attend this workshop?
|
I attended, and the message I got was: use SHA-256 (or SHA-512 if you
want to be cautious) for new applications, but consider it to be an
interim solution for the 5-10 year timeframe until something better is
devised, and have the agility to switch to that "something better" when
it comes; most importantly, stop using MD5 ASAP.
Regarding your friend's suggestion to "stick with SHA2 (or maybe
Whirlpool) for now", what I wrote in my notes was:
* Asked about which two functions would be best to use in
parallel, suggestions were SHA-256+(Whirlpool/Tiger).
One of the panelists explained, though, that using two different hash
functions and concatenating the output yields a result which is not
significantly more secure than either of the functions by itself. And
the SHA family of functions were the predominant topic of the workshop;
others, such as Whirlpool, were mentioned only occasionally.
Some choice quotes from Niels Ferguson:
"SHA-1 is a wounded fish in shark-infested waters."
"Switch away from SHA-1 as soon as you can, but switch away from
MD5 first."
It's true that MD5 and SHA-1 are still acceptable for certain uses where
the current attacks aren't a threat, but Ferguson argued that it's much
easier and safer to replace them entirely than to try to analyze which
uses are still OK.
Also from my notes: SHA-1 is OK for ephemeral uses, but not for
non-repudiation and certification -- essentially, if it matters that the
signature be verified by a third party, not just the recipient, avoid
SHA-1.
Some people wanted NIST to specify an approximate target year for a hash
standard to be issued, like they did for AES. Bruce Schneier said we
don't know hashing well enough, like we knew about block ciphers for
AES, and recommended that we "wait ten years".
Several people requested that NIST publish the design criteria with
which SHA-1 was designed, but I don't remember hearing a definitive
answer to that.
(Note that I'm not a cryptographer; I attended simply as an interested
individual.)
--
Mike Paul <w5ydkaz02@sneakemail.com> |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Linux
»
Distributions
»
Debian
»
devel
