gnunet-svn
[Top][All Lists]
Advanced

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

[GNUnet-SVN] r30516 - gnunet-java


From: gnunet
Subject: [GNUnet-SVN] r30516 - gnunet-java
Date: Tue, 5 Nov 2013 11:24:08 +0100

Author: dold
Date: 2013-11-05 11:24:08 +0100 (Tue, 05 Nov 2013)
New Revision: 30516

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-11-05 10:19:43 UTC (rev 30515)
+++ gnunet-java/ISSUES  2013-11-05 10:24:08 UTC (rev 30516)
@@ -21,19 +21,17 @@
  * how should shares be serialized
   * ... and should they contain the list of peers?
   * => maybe a configuration file / string?
+ * Should broadcast steps in the secret sharing protocol
+  be replaced by a consensus on signed commitments?
+  * this way all peers will have the same result
  * what if one of the authorities does not send some of the signed share parts 
s_{i,j}? who / how to blame?
   * one idea is to use consensus with encrypted signeds{i,j}, so only the 
receiver can open it and
     it can be known who sent their share parts 
   * but: what if the encrypted value is wrong? there's no way to demonstrate 
this without revealing the
-    private key
- * Should broadcast steps in the secret sharing protocol
-  be replaced by a consensus on signed commitments?
-  * this way all peers will have the same result
+    private key => can we somehow use ecdh+key derivation for that, so that 
the key can still
+    be revealed to blame somebody?
  * 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]