[GNUnet-developers] searching for SHA-1 and MD5

[Martin Uecker]

On Fri, Aug 16, 2002 at 01:24:35PM -0500, Christian Grothoff wrote:
 
> | We could insert them as additional keywords, but you would still rely on
> | the fact that you can only verify that you got the right file (keyword
> | to root-node correspondance) after you retrieved the entire file. Still,
> | there would definitely be some benefit in supporting those as keywords,
> | even if there is no guarantee that you get the right file at the end.
> |
> | Adding SHA-1/MD5 as a keyword would require writing an extractor
> | (http://www.ovmj.org/~samanta/libextractor/) and thus probably 20
> | lines of code each, definitely a good idea. 

Yes. But the download tool should check them too. It the check fail
the signer of the RBlock should automatically get inserted in a
black list. This should actually be done for all metadata which can
be checked automatically. (plugins for all kinds of metadata?)

[...]

> > Externally provided keys would just be a weakness.
> 
> Why? Because you could force people to censor certain keys? You could
> do this with existing GNUnet hashes too.
> 
> | Yes, you can force people to censor existing GNUnet hashes, but
> | since there is no keylist (like the keyservers in Freenet or your
> | MD5's on ftp sites) it's much harder to get the hashes in the
> | first place. You can censor 'porn', 'Porn', 'p0rn', etc, but how
> | many variations are there? At the end it's a question of who can
> | put in more effort in guessing keys. And there is a good chance
> | that the censor will eventually loose

But how do I know what keyword to use to get certain information?
This scheme is only then more censor resistant if the keywords are
secrets. But then you have censored yourself!

> | (not to mention that for each
> | guess, the censor has to force a significant majority of GNUnet node 
> | operators worldwide to ban the hash).

And for that reason externally provided hashes are not at high
risk for being censored too. I think.


Martin