data integrity on p2p networks - an approach

[indiana_jones]

with this thread i want to start some discussion about data integrity on sharing networks.
data integrity in principle concerns all data but especially data, which can damage anything like sw, scripts, codecs etc.
i only want ro consider the bad cases, the cases data are infected or damaged somehow, willingly or unwillingly and how to detect this or avoid this.
(for short i call bad data simply infected i.e. they may contain an unknown new virus or piece of added malicious code).

where or when are the sources of infection?[list=1][*]the originator infects the data and puts them on p2p[*]a downloader and sharer infects the data and reshares them[*]data get somehow infected or damaged on their way over different p2p networks[/list=1]all these things can happen without change of the main characterics like name, filesize or other details used by p2p networks to identify data. even the hashes are no real integrity criteria, because the not consequently used in p2p nets (i.e. gnutella), are not exhaustive calculated (i.e. fasttrack only uses sample blocks of a file) and mainly differ from net to net so they cannot consequently be used on all networks.

from all this i would say it is not possible for any user on any net to determine if just downloaded data are infected or not.

the only way in order to 100% prove if data are infected or not would be to compare them to the original, but this is not how p2p works.

a second way is to have a characteristic which proves with a very high probability that data are identical to the original.

one way i know to do this is a signature which must be of a certain length and exhaustive calculated - which means it must be sure that every bit has its correct value and is on its correct position.

this signature has to be calculated from a p2p network client independent open source tool and placed in public places so it could be proved and commented by users - this is the only way to cover case 1 (the bad originator).

all other cases are covered by this tool just using it after download on the data, recalculating the signature and comparing it to the published one.

i thought of a 32 byte 2*md5 hash, one in forward one in backward direction (block by block) which gives a 44 character uuencoded has string.

remarks, comments or anything else would be very welcome.
indy