[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] looking for Horst
From: |
Horst Herb |
Subject: |
Re: [Gnumed-devel] looking for Horst |
Date: |
Sat, 13 Aug 2005 07:35:31 +0000 |
User-agent: |
KMail/1.7.2 |
On Sat, 13 Aug 2005 06:08, Syan Tan wrote:
> Could you explain what first pre-image and second pre-image attack
> is again ? It sounds like you're saying that because a hash functions
> are one-way functions, that there is no feasible way to get X efficiently
> if X is the message and you have Y, the hash , because there's no
> efficient inverse F. Also , the collision algorithms seem pretty trendy
> and incomprehensible.
Pre-image attack means that you have a hash and you try to find a message that
will compute to the same hash (meaning if by coincidence you find the
original message, a password for example, you have cracked it)
Second pre-image attack means you have to find a hash collision for a given
message which you don't get to chose, but you get to see the original
message. Like, I give you a photo you never saw before, and ask you to
manipulate it with the requirement that both hashes of original and
manipulated image will be identical, namely the hash of the original
It was an assumption that second pre-image attacks are harder to do because
there is one message less (the original) in the set of possible solutions.
However, I still have to write the details of my reply to Tim's last argument,
the weakness is in the one pass block-sequential nature of MD5
> How does this affect using a notary ? Apparently, the complaint was
> that MD5 is insecure, and the court disallowed a photograph's MD5 signature
> because MD5 was theoretically flawed, but also because the original MD5
signature
> did not take in all the bits of the photograph for signature generation, but
> just the timestamp and text attached to the photo, and that gnumed should
> always include the entirety of data for hashing. Also, there was an
If I can create with comparable ease two differing messages with the same hash
(like, one health record stating that I did get notified of a certain even,
and one stating the opposite), and both compute to the same hash because of
my deliberate manipulation, a notary just timestamping a MD5 hash becomes
pointless.
Since the RTA used photographs nobody else had witnessed previously as sole
evidence, and the only evidence that photographs were not tampered with were
the MD5 sums, one could allege that these MD5 sums have little value as
evidence.
Horst