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