[GNUnet-SVN] r31007 - gnunet-java

[gnunet]

Author: dold
Date: 2013-12-03 13:03:55 +0100 (Tue, 03 Dec 2013)
New Revision: 31007

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-12-03 11:38:14 UTC (rev 31006)
+++ gnunet-java/ISSUES  2013-12-03 12:03:55 UTC (rev 31007)
@@ -1,37 +1,45 @@
-general crypto implementation:
- * key generation problem (setting/clearing bits) has been fixed in libgcrypt, 
but what about NaCl incompatibility?
-   (NaCl uses Curve25519/montgomery coordinates for ECDH, Ed25519/twisted 
edwards coordinates for EdDSA;
-    GNUnet with libgcrypt uses Ed25519 coordinates for everything; also in 
NaCl ecdhe pubkeys are just the x-coordinate)
- * libgcrypt does not use montgomery x-addition (=> slower)
-  * MPI_EC_MONTGOMERY exists, but is not implemented yet
- * reasons for not using NaCl and its optimized crypto-code?
-  * I guess (unclear) licensing?
- * I _think_ the 
+crypto:
+ * I've started to implement montgomery addition in gnunet-java based on
+   the somewhat well hidden paper by dbj I sent to Werner
+  * but I don't really understand how it works yet ...
+ * GNUnet crypto does not verify against ECDHE with ed25519.py
+  * see the script
+  * gnunet-java verifies
+  * problem already starts at key generation
+  * equivalent for other EC cryptosystems in GNUnet (I just happened to test 
ECDHE first)
+ * what about montgomery vs. twisted edwards performance now?
 
-java crypto implementation:
- implementing crypto is INCREDIBLY frustrating
+set: any issues?
 
- * original ed25519 java implementation had a pretty nice bug that occured 
with p=1/256 ...
+consensus / deadlines:
+ * I'm not sure anymore if the deadline should be relative or absolute time.
+   What do you think?
+  * absolute time makes it clear that doing consensus must be somewhat
+    in sync (modulo clock skew)
+  * relative time makes computation of subrounds that do consensus easier
 
- * 'gnunet-ecc -E' generates some random reference values
+scalarproduct:
+ * both scalarproduct and secretsharing use paillier crypto, might make sense 
to share implementation
+ * I think scalarproduct uses relatively complicated key generation
+  * see Wikipedia or Introduction to Modern Cryptography: Principles and 
Protocols for easier way
+ * what does this do (in encrypt_element):
+     while (0 >= gcry_mpi_cmp_ui (tmp, 1)) {
+       gcry_mpi_randomize (tmp, KEYBITS / 3, GCRY_WEAK_RANDOM);
+       // r must be 1 < r < n
+     }
+  * why the division by 3?
+  
 
- * gnunet-java now "implements" all three pk cryptosystems in pure java
-  * all but ECDSA pass sanity checks
-  * I'm relatively confident in Ed25519, it gives the same results as the 
python ref implementation
-  * aB key generation does not give the same results as GNUnet?
-
-set documentation:
-https://gnunet.org/content/gnunets-set-subsystem
-
-
-embeding curve points / using ECC for secret sharing:
- * problem: with the usual message-embeding injections we lose homomorphic 
properties
- * I found (=read somewhere ;) a scheme for elgamal with ecc, but i'm not 100%
-   sure all the ZKPs will still work ...
-
-
 secretsharing:
- * see document I mailed you ...
+ * DKG now two simple consensus rounds
+  * pre-secret commitment and ephemeral key exchange
+   * constant-size element
+  * encrypted pre-secret publishing
+   * variable-size element, may be a problem with large groups
+ * cooperative decryption is one consensus round
+ * Paillier and ElGamal interaction: Paillier key size must be large enough so 
that
+   shares can be encrypted
+ * decryption: consensus timeout vs client timeout:
+  * not all clients might have the same timeout
+  * but consensus timeout should match
 
-
-