gnunet-svn
[Top][All Lists]
Advanced

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

[GNUnet-SVN] r29195 - gnunet-java


From: gnunet
Subject: [GNUnet-SVN] r29195 - gnunet-java
Date: Wed, 11 Sep 2013 13:19:59 +0200

Author: dold
Date: 2013-09-11 13:19:59 +0200 (Wed, 11 Sep 2013)
New Revision: 29195

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-09-11 10:44:09 UTC (rev 29194)
+++ gnunet-java/ISSUES  2013-09-11 11:19:59 UTC (rev 29195)
@@ -1,97 +1,78 @@
-implementing the crypto stuff was more effort than I expected
- * turns out I actually had to read the DJB paper
+* I believe that your remark in our last meeting (Ed25519 secret keys must be 
mod 2^255-19)
+  is wrong, sk only must be a bitstring and is *not* directly used to generate 
the pubkey.
+* how is the libgrypt ecc going?
+* efficient ed25519 in java?
+ * seems a bit difficult due to the lack of 128-bit multiplication result
+   and no instruction level parallelism
 
-any 32-byte string is a valid key, right?
 
-should be implemented now (and has tests)
- * awefully slow! (5sec for key generation, signing and verification)
- * no optimizations from the paper implemented, should I look into this?
+* org.gnunet.util.Helper works now
+* the scheduler had to be updated:
+ * the scheduler now is (or at least should be) thread safe
+ * the simplest solution was to use selector.wakeup()
+ * before calling select, the lock is released. this would make it possible for
+   a deadlock to occur, but Java's semantics (wakeup causes next select to 
return
+   instantly) make this impossible
+* java selectors and threads are not trivial
+ * e.g. before registering a channel with a new selector in a thread,
+   one has to call wakeup on the selector
 
-Ed25519 implementation on github is somewhat bad
- * substibuted recursive expmod(b,e,m) with b.modPow(e,m)
- * Hint can be done with new BigInteger(1, h);
- * I've added some documentation, but still don't understand most 
cryptographic details
- * the comments used to say something about constant time comparison:
+=> in retrospect it might just have been easier to use a java.nio.channels.Pipe
 
-      if (!ra[0].equals(rb[0]) || !ra[1].equals(rb[1])) // Constant time 
comparison
-              return false;
-      return true;
+* java and exit values
+ * test runners don't seem to like System.exit(n)
+ * how should exit values be handled?
+  * either tests don't use org.gnunet.util.Program, and setExitValue remains
+  * or we don't care about the exit value
+  * or Program.start returns the exit values and the respective main() has to
+    call System.exit() with the exit value
 
-   but this code does not execute in constant time! Is this detail important?
+* java can now start/stop controller processes, and create peers
+ * start/stop etc. is next, should be trivial now ...
+* testbed now has messages and callbacks sub-package. is that ok?
 
-* the ecc crypto stuff is now implemented in java with the api similar to 
GNUNET_CRYPTO_ecc*, including
-  data structures (=org.gnunet.construct messages) etc.
+* key storage in GNUnet
+ * what is the best pratice w.r.t. storing private keys? what about encryption?
 
-* what's "our" encoding of curve points?
- * Bernstein et al. use point compression
- * even if GNUnet does not *store* points compressed, the algorithm 
-   hashes a compressed point
- * does GNUnet do this? do we use a different hash function?
-ok, my "best guess" / whats currently implemented:
- * no point compression for public keys
- * point compression for R and S in signatures
+* for specifying absolute time: how are timezones handled?
+* configuration: does GNUnet preserve the order or fields?
+ * important for signing, as sometimes the serialization of certain sections
+   is signed (does that make sense?)
 
-* what is the reasoning behind the purpose field for signatures?
- * i.e. why can't the user just add the field to messages if he wants to?
+* I think it's best to have most of the voting state centrally in the "ballot"
+ * as ballot means both "Wahlzettel" and "Wahlgang/Wahl/Abstimmung", the term 
is fitting,
+   and better than "election data" or "election specification"
+ * the ballot contains all PUBLIC state relevant to an issuer or voter.
+  * secret state is always passed per command line
+ * for voters, the ballot contains the encrypted "choice" for the election
+   including zero knowledge proofs, ...
+  * this is important, as we may want to send the ballot to different 
authorities,
+    but not in one session. nevertheless, the nonces must be the same 
(otherwise
+    the voter would be disqualified).
+ * ... as well as the authorities' submission voucher 
 
-why is the key material derived from an s-expr?
-from GNUNET_CRYPTO_ecc_dh
-  /* finally, get a string of the resulting S-expression and hash it
-     to generate the key material */
-  GNUNET_CRYPTO_hash (sdata_buf, slen, key_material);
+=> as all these tasks create, use or manipulate a ballot file, the voting call 
and
+   voting tool should be merged.
 
-ECDH neither works in my implementation, nor the python reference.
-what am I doing wrong with ECDH?
+=> I like the name 'gnunet-ballot' for the tool
 
-$ python
->>> import ed25519 as ecc
->>> import os
->>> sk1 = os.urandom(32)
->>> sk2 = os.urandom(32)
->>> pk1 = ecc.publickey(sk1)
->>> pk2 = ecc.publickey(sk2)
->>> ecc.scalarmult(ecc.decodepoint(pk1), ecc.decodeint(sk2))
-[17839698087218818508188271506040749529597055621135915409627286085172612074737L,
 1568236133114249143202350357927861645459149141660189072712053603778341056893L]
->>> ecc.scalarmult(ecc.decodepoint(pk2), ecc.decodeint(sk1))
-[49070523807924122052691980024493573448121871463721857488922928165668153903065L,
 11604814587173472450491572181106441638149561159961615227277125012932458010271L]
+create templace (copy it from the jar file):
+  gnunet-ballot -t my_ballot_file
+sign (as issuer) and register election with authorities:
+  gnunet-ballot -r my_ballot_file my_issuer_privkey_file
+get permission to vote with the given identity:
+  gnunet-ballot -p my_ballot_file my_voter_privkey_file
+select choice and store encrypted vote in ballot file:
+  gnunet-ballot -x pancakes my_ballot_file my_voter_priv_keyfile
+submit ballot to authorities and record vouchers (anyone can do that!):
+  gnunet-ballot -s my_ballot_file
+query election (anybody can do that)
+  gnunet-ballot -q my_ballot_file
+verify ballot (show what's the state, check signatures, ...)
+  gnunet-ballot -V my_ballot_file
 
-OK, got it: see org.gnunet.util.CryptoECC.computePublicCoefficient
-One has to do this due to the non-standard key derivation
 
+should we always send the whole (compressed) ballot,
+or only a hash and the relevant sections?
 
-GNUNET_CRYPTO_hash_distance_u32 documentation is unclear (inconsistent in 
.c/.h)
-and I don't know enough about it to fix it!
 
-org.gnunet.mesh.Mesh is now actually tested and works after fixing some bugs
-
-starting the testbed helper (any libexec program acually):
- * did I understand correctly, that if 'gnunet' is a substring of the binary 
name, we *only* look in libexec?
- * logic to locate the thing is a bit complicated
-
-test case for testbed helper still fails, working on it
-
-currently, my test case somehow makes the gradle test runner fail:
-
-Unexpected exception thrown.
-org.gradle.messaging.remote.internal.MessageIOException: Could not read 
message from '/0:0:0:0:0:0:0:1:45612'.
-       at 
org.gradle.messaging.remote.internal.inet.SocketConnection.receive(SocketConnection.java:88)
-       at 
org.gradle.messaging.remote.internal.hub.MessageHub$ConnectionReceive.run(MessageHub.java:230)
-       at 
org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
-       at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
-       at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
-       at java.lang.Thread.run(Thread.java:724)
-Caused by: com.esotericsoftware.kryo.KryoException: Buffer underflow.
-       at com.esotericsoftware.kryo.io.Input.require(Input.java:162)
-       at com.esotericsoftware.kryo.io.Input.readByte(Input.java:255)
-       at 
org.gradle.messaging.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:64)
-       at 
org.gradle.messaging.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:53)
-       at 
org.gradle.messaging.remote.internal.inet.SocketConnection.receive(SocketConnection.java:83)
-       ... 5 more
-
-
-
-is the election specification OK like this, or do you consider the authorities 
section abuse of syntax?
- * how should deadlines be specified? at the moment, GNUnet seems to only 
support relative time
-
-
-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]