[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)
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r30522 - gnunet-java,
gnunet <=