Experimental support for ECDSA.

This is not ready but the key generation and the self-test works.

1 files changed, 73 insertions, 15 deletions

diff --git a/TODO b/TODO
index f2bfe62b..25ee8be2 100644
--- a/TODO
+++ b/TODO
@@ -30,23 +30,57 @@ What's left to do                                 -*- outline -*-
   extra wiping.
   
 * update/improve documentation
-  - it's outdated for e.g. gcry_pk_algo_info.
-  - document algorithm capabilities
+** it's outdated for e.g. gcry_pk_algo_info.
+** document algorithm capabilities
+** Explain seed files and correlation
+  Multiple instances of the applications sharing the same random seed
+  file can be started in parallel, in which case they will read out
+  the same pool and then race for updating it (the last update
+  overwrites earlier updates).  They will differentiate only by the
+  weak entropy that is added in read_seed_file based on the PID and
+  clock, and up to 16 bytes of weak random non-blockingly.  The
+  consequence is that the output of these different instances is
+  correlated to some extent.  In the perfect scenario, the attacker
+  can control (or at least guess) the PID and clock of the
+  application, and drain the system's entropy pool to reduce the "up
+  to 16 bytes" above to 0.  Then the dependencies of the inital states
+  of the pools are completely known.
+** Init requirements for random
+   The documentation says in "Controlling the library" that some
+   functions can only be used at initialization time, but it does not
+   explain what that means.  Initialization is a multi-step procedure:
+   First the thread callbacks have to be set up (optional), then the
+   gcry_check_version() function must be called (mandatory), then
+   further functions can be used.
+
+   The manual also says that something happens when the seed file is
+   registered berfore the PRNG is initialized, but it does not say how
+   one can guarantee to call it early enough.
+
+   Suggested fix: Specify initialization time as the time after
+   gcry_check_version and before calling any other function except
+   gcry_control().
+
+   All functions which modify global state without a lock must be
+   documented as "can only be called during initialization time" (but
+   see item 1).  Then the extraneous calls to _gcry_random_initialize
+   in gcry_control() can be removed, and the comments "not thread
+   safe" in various initialization-time-only functions like
+   _gcry_use_random_daemon become superfluous.
 
 * Use builtin bit functions of gcc 3.4
 
 * Consider using a daemon to maintain he random pool
-  [Partly done]
-  The down side of this is that we can't assume that the random has
-  has always been stored in "secure memory".  And we rely on that
-  sniffing of Unix domain sockets is not possible.  We can implement
-  this simply by detecting a special prefixed random seed name and
-  divert in this case to the daemon.  There are several benefits with
-  such an approach: We keep the state of the RNG over invocations of
-  libgcrypt based applications, don't need time consuming
-  initialization of the pool and in case the entropy collectros need
-  to run that bunch of Unix utilities we don't waste their precious
-  results.
+  [Partly done] The down side of this is that we can't assume that the
+  random has has always been stored in "secure memory".  And we rely
+  on that sniffing of Unix domain sockets is not possible.  We can
+  implement this simply by detecting a special prefixed random seed
+  name and divert in this case to the daemon.  There are several
+  benefits with such an approach: We keep the state of the RNG over
+  invocations of libgcrypt based applications, don't need time
+  consuming initialization of the pool and in case the entropy
+  collectros need to run that bunch of Unix utilities we don't waste
+  their precious results.
 
 * Out of memory handler for secure memory should do proper logging
 
@@ -56,7 +90,10 @@ What's left to do                                 -*- outline -*-
 * mpi_print does not use secure memory
   for internal variables.
 
-* gry_mpi_lshift is missing
+* gcry_mpi_lshift is missing
+
+* Add internal versions of mpi functions
+  Or make use of the visibility attribute.
 
 * Add OAEP
 
@@ -71,12 +108,33 @@ What's left to do                                 -*- outline -*-
 * gcryptrnd.c
   Requires a test for pth [done] as well as some other tests.
 
+* random.c
+ If add_randomness is invoked before the pool is filled, but with a
+ weak source of entropy, for example the fast random poll, which
+ may happen from other parts of gcrypt, then the pool is filled
+ partially with weak random, defeating the purpose of pool_filled
+ and the "source > 1" check in add_randomness.
+
+ Suggestion: Count initial filling bytes with source > 1 in
+ add_randomness seperately from the pool_writepos cursor.  Only set
+ pool_filled if really POOLSIZE bytes with source > 1 have been
+ added.
+
 * secmem.c
   Check whether the memory block is valid before releasing it and
   print a diagnosic, like glibc does.
 
+* threads
+** We need to document fork problems
+  In particular that reinitialization is required in random.c
+  However, there is no code yet to do it.
+
 * Tests
   We need a lot more tests.  Lets keep an ever growing list here.
 ** Write tests for the progress function
 ** mpitests does no real checks yet.
-
+** pthreads
+  To catch simple errors like the one fixed on 2007-03-16.
+** C++ tests
+  We have some code to allow using libgcrypt from C++, so we also
+  should have a test case.