tests: Add test to verify GOST 28147-89 against known results.
[libgcrypt.git] / TODO
diff --git a/TODO b/TODO
index 25ee8be..ffadc06 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,76 +1,30 @@
-What's left to do                                 -*- outline -*-
+# What's left to do                                 -*- org -*-
 
-* Updated the FSF's directory.
+* Next API break:
+** gcry_ac_io_t
+  Remove use of anonymous union.
+** gcry_ac
+  Consider to remove it.
 
 * udiv-qrnbd.o should get build as *.lo [HPUX]
 
-* Allow operation using RSA keys consisting of the OpenSSL list of
-  parameters and allow for a third form where the private Exponent
-  is not given (saves space).
-
-* Add a warning to the manual, to check that libgcrypt actually has
-  been compiled with thread support when used by a threaded
-  application.
+* Allow operation using RSA keys consisting of the OpenSSL keys.
+  This requires the introduction of a parameter names (say) U which
+  is calculated according to OpenSSL/PKCS#1 rules.
 
 * linker script test
   Write an autoconf test to check whether the linker supports a
   version script. 
 
-* Make use of the forthcoming visibility attribute.
-
 * Add attributes to the MPI functions.
 
-* In case the ac interface will be more popular than the pk interface,
-  the asymmetric ciphers could be changed for convenient interaction
-  with the ac interface (i.e. by using ac's `data sets') and the pk
-  interface could be changed to be a wrapper for the ac interface.
-
 * cipher/pubkey.c and pubkey implementaions.
   Don't rely on the secure memory based wiping function but add an
   extra wiping.
   
-* update/improve documentation
-** 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
+* Consider using a daemon to maintain the 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
@@ -82,44 +36,9 @@ What's left to do                                 -*- outline -*-
   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
-
-  There is no shortage of standard memory, so logging is most likely
-  possible.
-
-* mpi_print does not use secure memory
-  for internal variables.
-
-* gcry_mpi_lshift is missing
-
-* Add internal versions of mpi functions
-  Or make use of the visibility attribute.
-
-* Add OAEP
-
-* Next API break:
-** gcry_ac_io_t
-  Remove use of anonymous union.
-
-* ac.c
-  There are still some things fishy.  The fixes I did today
-  (2006-10-23) seem to cure just a symptom.  Needs a complete review.
-
 * 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.