[GNUnet-SVN] r873 - GNUnet GNUnet/src/server GNUnet-docs/papers/ecrs gnunet-gtk/src

[grothoff]

Author: grothoff
Date: 2005-06-06 11:11:36 -0700 (Mon, 06 Jun 2005)
New Revision: 873

Modified:
   GNUnet-docs/papers/ecrs/main.tex
   GNUnet/src/server/tcpserver.c
   GNUnet/todo
   gnunet-gtk/src/fs.c
Log:
coding

Modified: GNUnet/src/server/tcpserver.c
===================================================================
--- GNUnet/src/server/tcpserver.c       2005-06-06 18:09:34 UTC (rev 872)
+++ GNUnet/src/server/tcpserver.c       2005-06-06 18:11:36 UTC (rev 873)
@@ -745,7 +745,8 @@
     SEMAPHORE_DOWN(serverSignal);
     SEMAPHORE_FREE(serverSignal);
     serverSignal = NULL;
-    PTHREAD_JOIN(&TCPLISTENER_listener_, &unused);
+    PTHREAD_JOIN(&TCPLISTENER_listener_,
+                &unused);
     return OK;
   } else {
     if (testConfigurationString("TCPSERVER",

Modified: GNUnet/todo
===================================================================
--- GNUnet/todo 2005-06-06 18:09:34 UTC (rev 872)
+++ GNUnet/todo 2005-06-06 18:11:36 UTC (rev 873)
@@ -1,8 +1,5 @@
 0.7.0pre3:
-- FSUI: 
-  * do NOT use libextractor with
-    FSUI_upload (full control should be with client!)
-- gnunet-gtk (debug a bit, add preview encoding for upload)
+- gnunet-gtk (debug)
 - gnunet-setup:
    curses wizard?  [ Nils ];
    template path adjustment for non gconf setup [ Nils ]

Modified: GNUnet-docs/papers/ecrs/main.tex
===================================================================
--- GNUnet-docs/papers/ecrs/main.tex    2005-06-06 18:09:34 UTC (rev 872)
+++ GNUnet-docs/papers/ecrs/main.tex    2005-06-06 18:11:36 UTC (rev 873)
@@ -24,6 +24,39 @@
 % Todo:
 % - Look into/cite MIT FARSITE system (convergent encryption)
 % - fix xy-pic (dotted arrows, multicols)
+%
+% Notes by JTL (06.jun.05): 
+% - word 'convergent' is used in the end of the doc 'out of the blue'
+%   (we should use it earlier when the idea is introduced)
+%   [CG: yes, that's why I have the MIT FARSITE system in Todo above ]
+% - while I tried to simulate a 'first time reader' the big picture
+%   of ECRS appeared a little muddled. A diagram of the relation of
+%   the encoding and the extensions might be helpful. Now we have 
+%   just one figure and it lacks SBlocks. Also the directories, 
+%   bloomfilters and whatnots are left dangling unconnected in some limbo.
+%   [ CG: A good figure would be more than welcome. ]
+% - (!) now more of the paper rests on the 'unprincipled' k-blocks
+%   approach (that is, we present it as novel and offer no analysis, proof,
+%   or other formal handling). i.e. this could be good basis for adversarial 
+%   paper rejection. for a naive example, could collisions be a problem?
+%   Since this can't be the case with usual pubkey crypto (I assume), 
+%   its not a problem here, but maybe should add a mention of this anyway. 
+%   [ CG: Collisions are obviously as much as a problem as they are for 
+%     RSA key generation; I'm not sure what the problem is. ]
+% - Are there other ways the k-blocks can leak? Could we make the
+%   concept appear more solid by adding citations to some pubkey papers 
+%   that analyze them w.r.t. the currently trendy security concerns? 
+%   [ CG: actually, yes.  There is a paper to refer to.  
+%     Dan Boneh and others, Searchable public key encryption; need to
+%     find and read ]
+% - Whats the style of the intended journal? Is it ok to be on this 
high-handed 
+%   level as we are? For example, is it ok to take the noninvertibility 
+%   of a hash-function for granted and not provide a cite?
+%   [ CG: Yes, it is for an audience that is intimately familiar with 
cryptographic
+%     primitives.  Besides, lacking such references for the intended audience
+%     would be something reviewers should point out without seeing it as a 
+%     reason for rejection (assuming we wrong wrt target audience/terminology)]
+%
 
 \title{An Encoding for Censorship-Resistant Sharing}
 \author{Christian Grothoff\inst{1}, Krista Grothoff\inst{2}, Tzvetan 
Horozov\inst{3}, Jussi T. Lindgren\inst{4}}
@@ -51,7 +84,7 @@
 censor\-ship-resistant peer-to-peer networking.  The proposed encoding
 mechanism supports both efficient dissemination of encrypted data as
 well as encrypted queries over this data.  Intermediaries can verify
-that an encrypted response matches an encrypted reply without being
+that an encrypted response matches an encrypted query without being
 able to decrypt either.  Furthermore, ECRS allows users to share files
 encrypted under descriptive keys which are the basis for querying the
 network for content.  With the proposed scheme, effective load
@@ -342,13 +375,14 @@
 trees for integrity checks on fixed-size blocks of data.  A difference
 with ECRS is that the Tangler encoding uses Shamir's secret
 sharing~\cite{shamir} to entangle the block with other, pre-existing
-blocks, preferably from other documents.  similarity between Tangler,
+blocks, preferably from other documents. A similarity between Tangler,
 Freenet and ECRS is the existence of cryptographically signed data,
 which Tangler calls collections.  Tangler's collections are analogous
 to directories and namespaces in ECRS.  The major difference is that
 in Tangler a collection has a versioned root which explicitly lists
 all of the contents in the collection, resulting in one of Tangler's
-global synchronization problems.  Placing a document in a Freenet
+global synchronization problems. %  [FIXME: better w/ CITE].  
+Placing a document in a Freenet
 subspace or ECRS namespace only requires that it be adequately signed.
 
 
@@ -421,6 +455,9 @@
 
 \section{ECRS encoding} \label{content}
 
+% so we have another introduction here w/ clear redundancy -jtl
+% the first paragraph sucks too
+
 The primary requirements for the ECRS encoding are {\it plausible
 deniability} and {\it robustness}.  Plausible deniability describes
 the ability of the participants to claim ignorance of the nature of
@@ -578,7 +615,7 @@
 cannot be applied to the search problem.  Instead, ECRS must trust the
 user who is uploading the content.  That user must specify appropriate
 keywords and metadata that properly describes the content.  Clearly
-this trust maybe misplaced.  Namespaces can help solve this problem
+this trust may be misplaced.  Namespaces can help solve this problem
 since they enable users to learn which other users are trustworthy.
 
 
@@ -646,7 +683,7 @@
 importantly, users would still have to find the namespaces themselves,
 and while it can be assumed that users can guess keywords, they are
 unlikely to be able to guess public keys for a namespace search.  ECRS
-solves this problem by also offering a pure keyword-based search in a
+alleviates this problem by also offering a pure keyword-based search in a
 {\em global} keyword space where any user can advertise content.
 Here, the disadvantage is clearly that it is possible for malicious
 users to pollute the global keyword space with advertisements and
@@ -680,8 +717,9 @@
 keyword used for a search is not exposed to intermediaries in a way
 that would allow them to easily exercise editorial control (i.e. to
 censor queries).  Again a guessing attack, where the intermediary
-guesses the keyword and can then compute the query for this keyword,
-is acceptable.  Plausible deniability for the intermediaries is
+guesses a keyword, computes the respective query, and attempts to match 
+the query to the incoming query, is acceptable.  Plausible deniability 
+for the intermediaries is
 unaffected by this attack.  Second, only peers that have content
 available under the given keyword should be able to produce a valid
 response.  In other words, the ultimate responder must have succeeded
@@ -791,7 +829,7 @@
 that should be addressed to facilitate real-life usability.  For
 example, the manual effort of assigning or guessing keywords should be
 minimized. Also, the overall system should be efficient in practice.
-In particular, this requires peers to frequently handle small,
+In particular, the system requires peers to frequently handle small,
 per-block queries, many of which may not have a answer that is locally
 available.  The following subsections present some ideas on how these
 issues can be addressed.
@@ -855,9 +893,9 @@
 a peer may only be able to respond to a fraction of the
 received queries.  Assuming that queries dominate the traffic, over 50
 queries per second could be transmitted over a slow modem line.  Many
-peers could not perform disk-based database lookups at such rates.
-Worse, if peers are sharing gigabytes of content, simply keeping the
-index information in memory is also often no longer feasible.
+peers might not be able to perform disk-based database lookups at such 
+rates. Worse, if peers are sharing gigabytes of content, simply 
+keeping the index information in memory is also often no longer feasible.
 
 In order to dramatically reduce the necessary number of database
 accesses, ECRS can be supplemented with a bloom filter~\cite{bloom},
@@ -1060,7 +1098,7 @@
 form of transmission and caching of invalid data.
 
 Replacing the triple-hash with {\em KBlock}s for ECRS comes at a
-relatively high price.  Where the tripe-hash only requires a simple
+relatively high price.  Where the triple-hash only requires a simple
 hash operation to verify replies, {\em KBlock}s need to perform a
 public key operation.  Worse, when publishing content or searching,
 the triple-hash scheme again only requires a few quick hash operations

Modified: gnunet-gtk/src/fs.c
===================================================================
--- gnunet-gtk/src/fs.c 2005-06-06 18:09:34 UTC (rev 872)
+++ gnunet-gtk/src/fs.c 2005-06-06 18:11:36 UTC (rev 873)
@@ -137,6 +137,7 @@
 void gtk_fs_done() {
   PTHREAD_T doneThread;
   Semaphore * sig;
+  void * unused;
 
   sig = SEMAPHORE_NEW(0);
   if (0 != PTHREAD_CREATE(&doneThread,
@@ -146,6 +147,8 @@
     DIE_STRERROR("pthread_create");
   while (OK != SEMAPHORE_DOWN_NONBLOCKING(sig))
     gtkRunSomeSaveCalls();
+  PTHREAD_JOIN(&doneThread,
+              &unused);
   SEMAPHORE_FREE(sig);
 }