gnumed-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]