[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] r31007 - gnunet-java
From: |
gnunet |
Subject: |
[GNUnet-SVN] r31007 - gnunet-java |
Date: |
Tue, 3 Dec 2013 13:03:55 +0100 |
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
-
-
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r31007 - gnunet-java,
gnunet <=