Re: [GNUnet-developers] Playing with GNUnet

[Christian Grothoff]

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

On Thursday 11 July 2002 07:36 pm, you wrote:
> > Not deniability. Censorship resistance. You were successfully able to
> > force the defendant to whom the court order applies (which would be one
> > individual since you can't get such an order 'for the world') to
> > blacklist a couple of hashes. In a network with high connectivity, that
> > would neither efficienctly censor the material (since many other hosts
> > would still route and replicate the data) nor inhibit the defendant to
> > share the content if one character per 1k block is changed -- because
> > then the defendant can again claim not to know what it was. Thus this
> > would rather be a waste of your time.
>
> 1) Are you *sure* *nobody* can get such a court order?  I've seen some
>    impressive legal shenanigans lately, and laws can change.
>    There might also be some equivalent threat that could be used
>    (E.g. sending nasty letters to

The legal system can always go postal. See the requirement against 'outlawing 
anonymity' in our anonymity paper. 

> 2) I don't quite understand your first two sentences.  (No verb.)
>    The point is that I can put a large number of server operators on
>    notice that they may not carry certain material.  I.e. if I've
>    told them the forbidden hashes, they can't deny knowing they're
>    carrying it.

But you had to tell them those hashes, before, they can claim not to know.

> 3) You can likewise, given H(H(B)), threaten to sue people for forwarding
>    3QUERIES for H(H(H(B))).  That would hurt availability, no?

If you are albe to do that on a global scale with a reasonable threat-level, 
yes. But you could also sue people for running Linux (hurts commercial 
software development or something like that).

> Yes, there are defences at the publisher's end.  I just wanted to avoid
> the need to make them manual.  Tools that don't have security
> interactions with the payloads they carry are a Good Thing.
>
> (I'm still not clear on what prevents a malicious node from answering
> a query for H(H(B)) with a garbage block.  Only posession of H(B) lets
> one distinguish a valid response from an invalid one, and intermediate
> nodes don't have it.)

Read the encoding paper. It is possible to reply with garbage, but since you 
are provided with H(H(H(B))), you must at least invert the hash (produce 
H(H(B))) in order to do so. And this inversion will have the cost of looking 
up B, thus you can only answer with garbage if you did the effort required to 
find the answer. But since this forces you to obtain the answer, you have no 
incentive to send garbage (unless you just want to be destructive, in which 
case the initiator may get a bad result and has to ask again [presumably 
rare]).

> > This can be defended against by altering the quoted plaintext:
> > punctuation, spacing, line-wrapping, or the like, but why should the
> > system user have to go to the trouble?
> >
> > Having the option to remove content whenever you are seriously (legally)
> > threatened to do so -- without impacting availability (!) -- is something
> > I'd rather consider a good thing.
>
> It seems to me more of a Bad Thing, because it implies a failure of
> deniability.  If you have the possibility of telling "good" from "bad"
> (for some particular point of view), then you can (like Napster) be
> held responsible for enforcing the distinction.  It's important to be a
> "common carrier" without editorial control.

Your distinction of good from bad requires a blacklist. The provider of the 
blacklist is the entity that excercises editorial control, not the host of 
the node.

> > I would say that this depends a lot on the application. append-only
> > log-files, large headers (e.g. in doc or ps files, license texts at the
> > beginning of code) or very redundant data (all-zeros) come to mind.
> > Aborted downloads may be another example.
>
> Good points.  But that could be addressed by chaining in the hash of
> the previous block (which is stored in the index, so you could still do
> random-access output) into the hash of the current block.  That allows
> common prefixes to share, but prevents precomputing all possible hashes
> of excerpts.  (As for blocks of zeros, isn't that a bit wasteful of
> bandwidth?  Shouldn't such files be compressed first?  Although,
> admittedly, once it's been trasmitted once, it *is* cached...)

I am not saying that using previous blocks would prevent sharing in 
significantly more cases. But it would NOT improve your censorship scenario, 
since all the blacklisting would still be possible. It would just make the 
on-demand encoded lookup much worse (essentially impossible).

> > I was more thinking about the estimation on how long it could take for a
> > reply. The client and the nodes need an estimate on how long to wait
> > until either scheduling the query for a re-sent (client) or freeing the
> > slot in the routing table (node). If the TTL is 'randomized' like that,
> > this estimate could only be approximate (being wrong would not be a
> > disaster, just bad for efficiency). I'm not yet sure where to put my
> > money for this trade-off, especially since the initial TTLs are from a
> > 'potentially' infinite window.
>
> H'm... I'll have to look at the implementation in more detail.
> Aren't forwards subject to random time delays anyway?

Yes, but the random delay for a forward is bounded (otherwise it is considered 
noise since a reply after a couple of days is typcially useless). Thus you 
can estimate the round-trip-time using TTL * max-rand-delay. 

> > Better suggestions?
>
> Open a pipe, fork, have the child start the pthreads and send success
> back to the parent.  The parent hangs around until the child has sent
> the success code over the pipe, or has exited.  (Note that the latter
> can be detected by the EOF on the pipe.)
>
> Then the parent returns the appropriate error code to whatever invoked it.

Sounds like a good way to do it.

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

iD8DBQE9LwpW9tNtMeXQLkIRAq7+AJ98Y+l50YAsn1Gw8IMe9bHNhrV4qQCeK9Ra
dy2XCnL+RvEFNWEHbMiRrck=
=z63E
-----END PGP SIGNATURE-----