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

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 17 August 2002 08:01 am, Martin Uecker wrote:
> 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?)

Too bad that RBlocks are not signed (!). Besides, if you'd put in bogous 
content, why wouldn't you just make up a new pseudonym for each file that you 
insert into the network? IMO, the user can run md5sum/extract to check if 
wanted, but it's not really going to help a lot to do this in the client.

> 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!

No, it's more playing on the theme that birds of a feather may be able to 
agree on keys that the bad guys may not be able to find. And note that you 
can have as many keys for a file as you wish, and the bad guys have to find 
*all* of them (to censor) and the good guy only needs one. 

It's the same as with flaws in software. To break into the system, you need 
one vulnerability, to secure a system, you must find & fix all of them. Thus 
the numbers are on 'our' side.

> > | (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.

I don't see why they should have a lower or a higher probability of being 
censored. And if I have an externally provided keyword, well, I can make it a 
very obscure password. I don't see why external keywords are less likely to 
be censored then internal keywords (no matter if they are hashes, normal 
words or passwords) -- in fact, I would assume they are much more likely 
since they are exposed whereas internal keywords are not.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9Xq+A9tNtMeXQLkIRAruxAJsHKbOi3jPv51szMvhGsAVYRKkwBwCeNvVR
SAvzTlJwAJQKsPz210zPz6E=
=a5f8
-----END PGP SIGNATURE-----