gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-SVN] r30522 - gnunet-java


From: gnunet
Subject: [GNUnet-SVN] r30522 - gnunet-java
Date: Tue, 5 Nov 2013 13:53:46 +0100

Author: dold
Date: 2013-11-05 13:53:46 +0100 (Tue, 05 Nov 2013)
New Revision: 30522

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-11-05 12:32:20 UTC (rev 30521)
+++ gnunet-java/ISSUES  2013-11-05 12:53:46 UTC (rev 30522)
@@ -17,6 +17,7 @@
 
 
 secretsharing:
+ * if you want a shorter name: vss (verifyable secret sharing)
  * discuss api
  * how should shares be serialized
   * ... and should they contain the list of peers?
@@ -30,6 +31,12 @@
   * but: what if the encrypted value is wrong? there's no way to demonstrate 
this without revealing the
     private key => can we somehow use ecdh+key derivation for that, so that 
the key can still
     be revealed to blame somebody?
+  * round1: each peer puts a freshly generated, signed ecdh key in consensus
+  * in the share part exchange round: if a share part is wrong (signature 
verification or F_{i,j} verification fails),
+    the authority that finds out puts a complaint element in the consensus, 
revealing its private ecdh key
+  * the other authorities check the complaint for validity
+   * if the complaint is valid, the offending authority is excluded
+   * if the complaint is invalid, the complainer is excluded
  * what parameters should be the default?
   * q (where q divides (p-1)) determines the size of the group, so how large 
do we want it?
     (for practical purposes and security)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]