Re: [GNUnet-developers] Playing with GNUnet

[Christian Grothoff]

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

On Thursday 11 July 2002 04:28 pm, address@hidden wrote:
> > Where is that one mentioned? We're now using gdbm, so this entry was
> > removed. Must be a dead reference, but where did you find it?
>
> At least two places, as I recall.  Let's see...
> $CVSROOT/gnunet/doc/man/gnunet.conf.5
> $CVSROOT/gnunet/contrib/gnunet.conf

Fixed, thanks.

> A little bit of thinking reveals the following "attack":
> - Suppose I wish to suppress some specific samizdat of length >1K,
>   e.g. I'm a Scientologist and I want to stop people quoting the NOTs.
> - I generate all possible 1K windows of the material in question,
>   encrypt them and hash them.  This produces output 20 times as large as
>   the document I want to suppress.
> - I get a court order forbidding people to serve blocks with the given
>   hashes.  I haven't revealed the plaintext, but I've (partially) defeated
>   deniability.

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.

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

> I agree that the value of having multiple insertions of the same
> plaintext "collide" and merge is significant.  Is accidental
> sharing of matching *blocks* in different plaintext sufficiently
> likely to be worthwhile?

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. 

> (I should check the source, but...) are the TTLs chosen from an infinite
> (e.g. normal) or finite (e.g. uniform window) distribution?  The latter
> allows definite statements about the locaiton of the source of query to
> be made, particularly any time a value near the limit of the possible is
> seen.  An infinite distribution just makes is less likely.

TTLs are chosen from a window that grows exponentially over time and is thus 
potentially infinite, but typically small.

> The sometimes-decrement is basically a cheap way of generating an
> infinite TTL range, with the added bonus of obscuring cycle lengths
> as well.
>
> I'm not sure how it can make cycle detection a problem.  If *all* nodes
> on a cycle fail by *never* decrementing the TTL, a packet will loop
> forever, but that's true no matter whan the decrementing rule.
>
> It does make it harder to *measure* the number of hops in a cycle, but
> I'm not sure why you'd want to do that anyway.  Maybe there's some
> specific operation done in the source that I should look into.

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.

> >> gnunetd really should fork into the background once it's completed
> >> initialization, like a good daemon.  While I can just run it in the
> >> background in the first place, that makes it impossible to check for
> >> errors.
> >
> > Sounds like a good idea, but since I never wrote a good deamon (mine are
> > always evil :-), I am not certain where exactly to do it and how to
> > ensure that everything is fine. Care to provide a patch?
>
> Okay, I get the hint. :-).  Have a look at Stevens "Advanced Programming
> in the UNIX Environment", section 13.3 (Daemon Processes: Coding Rules).
> The basic technique is:
>
>       /* Open all files, network connections, etc. */
>       /* Don't hold the wrong FS mounted */
>       if (chdir(some_suitable_directory) < 0) {
>               perror(some_suitable_directory);
>               return 1;
>       }
>       if (umask(0) < 0) {
>               perror("umask");
>               return 1;
>       }
>       logfd = open("/path/to/log/file", O_WRONLY | O_CREAT | O_APPEND);
>       if (logfd < 0) {
>               perror("/path/to/log/file");
>               return 1;
>       }
>       nullfd = open("/dev/null", O_RDWR);
>       if (logfd < 0) {
>               perror("/dev/null");
>               return 1;
>       }
>       fflush(stdout);
>         if (!debug_flag) {
>                 pid_t pid = fork();
>                 if (pid < 0) {
>                         perror("fork");
>                         return 1;
>                 }
>                 if (pid) {
>                         /* Parent */
>                       /* print pid of child for /var/run/gnunetd.pid */
>                         printf("%u\n", (unsigned)pid);
>                       fflush(stdout);
>                       _exit(0);       /* Avoid atexit() problems */
>                 }
>                 /* child - close fds linking to invoking terminal, but
>                * close usual incoming fds, but redirect them somewhere
>                * useful so the fds don't get reallocated elsewhere.
>                */
>                 if (dup2(nullfd,0) < 0 || dup2(logfd,1) < 0 || dup2(1,2) <
> 0) { perror("dup2");  /* Should never happen */
>                         return 1;
>                 }
>               pid = setsid(); /* Detach from controlling terminal */
>                 log_entry("Child backgrounded, pid = %u", (unsigned)pid);
>         }
>       /* Main loop goes here */

Well, I have that book. Anyway, I doubt this will this work if during the 
initialization (and checking, etc) the main method has already created a 
couple of pthreads? If you then fork off the main method, could that not 
result in having the threads run in a different process than the rest of the 
main method and thus without sharing of global state?
So we may need to re-factor the entire initialization to ensure that threads 
are only created after we fork (which would be a bit more work than it is 
worth at this point imo); or we could just fork at the beginning and do 
error-checking after already being detached from the console (which would be 
ugly). 
Better suggestions?

> > Sounds like a bug. Added to the pile...
> > http://www.ovmj.org/~mantis/view_bug_page.php?f_id=324
>
> Thanks.  Looking at it is tricky:
> > Mantis - OVM Bugtracking
> >
> > ERROR: your account may be disabled or the username/password you entered
> > is incorrect.
> >
> > [ Click here to proceed ]
>
> Does Mantis require cookies enabled or some such?

Yes. Use konqueror - there you can specify which sites are allowed to use 
cookies and which are not.

> >> I notice that gnunet forks children which spend a lot of time in
> >> loops like:
> >>
> >> getppid()                               = 17459
> >> poll([{fd=8, events=POLLIN}], 1, 2000)  = 0
> >> getppid()                               = 17459
> >> poll([{fd=8, events=POLLIN}], 1, 2000)  = 0
> >> getppid()                               = 17459
> >> poll([{fd=8, events=POLLIN}], 1, 2000)  = 0
> >> getppid()                               = 17459
> >>
> >> There is an easy way to block on the parent exiting, using a pipe.
> >> Create a pipe which only the parent can write to (children close the fd
> >> after forking), and it will poll ready-to-read (EOF) when the parent
> >> exits (and closes the write end).
> >
> > This must have something to do with our use of pthreads. What is odd
> > that on my machine(s), gnunetd takes only a couple of minutes of total
> > CPU time over weeks. What system are you using? Is it really an issue?
> > Since we're not explicitly calling getppid(), the above is definitely a
> > very low-level remark, so I'm also not sure where to even start to fix it
> > (if it is really an issue).
>
> strace() is my general "What is this thing doing?" probe.
> Yes, it might easily be a pthreads thing.
>
> The system is an x86 running Debian GNU/Linux (unstable), with kernel
> 2.4.18 (+ nanokernel patches).
>
> The reason this is an issue is that the constant activity increases
> the memory footprint of an idle daemon.  Of course, sending noise
> packets does that too, and that's necessary...
>
> > That must be the cron-job. It checks every second if there is "more
> > work". Why it should call time that often is a mystery to me, though.
>
> I'm going to have to look into that, I suppose.  Perhaps I can create
> a version that doesn't busy-loop, but computes when it wants to wake up
> and sleeps until then.

If you consider the case that cron may have the next job in 1h and then 
suddenly a job gets added for 'in 30s' (and you'd have to cancel the previous
wait), I'll be very happy about a patch :-)

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

iD8DBQE9LgOt9tNtMeXQLkIRArfwAKCSAgv+w9eGxMJQxI4Z70+d9H5ntQCfeCdl
SlOOmWzUIt7iJ6jFrUawuLo=
=SoOq
-----END PGP SIGNATURE-----