25ee8be2a132cb7129463f052f0b72c4786d47ea
[libgcrypt.git] / TODO
1 What's left to do                                 -*- outline -*-
2
3 * Updated the FSF's directory.
4
5 * udiv-qrnbd.o should get build as *.lo [HPUX]
6
7 * Allow operation using RSA keys consisting of the OpenSSL list of
8   parameters and allow for a third form where the private Exponent
9   is not given (saves space).
10
11 * Add a warning to the manual, to check that libgcrypt actually has
12   been compiled with thread support when used by a threaded
13   application.
14
15 * linker script test
16   Write an autoconf test to check whether the linker supports a
17   version script. 
18
19 * Make use of the forthcoming visibility attribute.
20
21 * Add attributes to the MPI functions.
22
23 * In case the ac interface will be more popular than the pk interface,
24   the asymmetric ciphers could be changed for convenient interaction
25   with the ac interface (i.e. by using ac's `data sets') and the pk
26   interface could be changed to be a wrapper for the ac interface.
27
28 * cipher/pubkey.c and pubkey implementaions.
29   Don't rely on the secure memory based wiping function but add an
30   extra wiping.
31   
32 * update/improve documentation
33 ** it's outdated for e.g. gcry_pk_algo_info.
34 ** document algorithm capabilities
35 ** Explain seed files and correlation
36   Multiple instances of the applications sharing the same random seed
37   file can be started in parallel, in which case they will read out
38   the same pool and then race for updating it (the last update
39   overwrites earlier updates).  They will differentiate only by the
40   weak entropy that is added in read_seed_file based on the PID and
41   clock, and up to 16 bytes of weak random non-blockingly.  The
42   consequence is that the output of these different instances is
43   correlated to some extent.  In the perfect scenario, the attacker
44   can control (or at least guess) the PID and clock of the
45   application, and drain the system's entropy pool to reduce the "up
46   to 16 bytes" above to 0.  Then the dependencies of the inital states
47   of the pools are completely known.
48 ** Init requirements for random
49    The documentation says in "Controlling the library" that some
50    functions can only be used at initialization time, but it does not
51    explain what that means.  Initialization is a multi-step procedure:
52    First the thread callbacks have to be set up (optional), then the
53    gcry_check_version() function must be called (mandatory), then
54    further functions can be used.
55
56    The manual also says that something happens when the seed file is
57    registered berfore the PRNG is initialized, but it does not say how
58    one can guarantee to call it early enough.
59
60    Suggested fix: Specify initialization time as the time after
61    gcry_check_version and before calling any other function except
62    gcry_control().
63
64    All functions which modify global state without a lock must be
65    documented as "can only be called during initialization time" (but
66    see item 1).  Then the extraneous calls to _gcry_random_initialize
67    in gcry_control() can be removed, and the comments "not thread
68    safe" in various initialization-time-only functions like
69    _gcry_use_random_daemon become superfluous.
70
71 * Use builtin bit functions of gcc 3.4
72
73 * Consider using a daemon to maintain he random pool
74   [Partly done] The down side of this is that we can't assume that the
75   random has has always been stored in "secure memory".  And we rely
76   on that sniffing of Unix domain sockets is not possible.  We can
77   implement this simply by detecting a special prefixed random seed
78   name and divert in this case to the daemon.  There are several
79   benefits with such an approach: We keep the state of the RNG over
80   invocations of libgcrypt based applications, don't need time
81   consuming initialization of the pool and in case the entropy
82   collectros need to run that bunch of Unix utilities we don't waste
83   their precious results.
84
85 * Out of memory handler for secure memory should do proper logging
86
87   There is no shortage of standard memory, so logging is most likely
88   possible.
89
90 * mpi_print does not use secure memory
91   for internal variables.
92
93 * gcry_mpi_lshift is missing
94
95 * Add internal versions of mpi functions
96   Or make use of the visibility attribute.
97
98 * Add OAEP
99
100 * Next API break:
101 ** gcry_ac_io_t
102   Remove use of anonymous union.
103
104 * ac.c
105   There are still some things fishy.  The fixes I did today
106   (2006-10-23) seem to cure just a symptom.  Needs a complete review.
107
108 * gcryptrnd.c
109   Requires a test for pth [done] as well as some other tests.
110
111 * random.c
112  If add_randomness is invoked before the pool is filled, but with a
113  weak source of entropy, for example the fast random poll, which
114  may happen from other parts of gcrypt, then the pool is filled
115  partially with weak random, defeating the purpose of pool_filled
116  and the "source > 1" check in add_randomness.
117
118  Suggestion: Count initial filling bytes with source > 1 in
119  add_randomness seperately from the pool_writepos cursor.  Only set
120  pool_filled if really POOLSIZE bytes with source > 1 have been
121  added.
122
123 * secmem.c
124   Check whether the memory block is valid before releasing it and
125   print a diagnosic, like glibc does.
126
127 * threads
128 ** We need to document fork problems
129   In particular that reinitialization is required in random.c
130   However, there is no code yet to do it.
131
132 * Tests
133   We need a lot more tests.  Lets keep an ever growing list here.
134 ** Write tests for the progress function
135 ** mpitests does no real checks yet.
136 ** pthreads
137   To catch simple errors like the one fixed on 2007-03-16.
138 ** C++ tests
139   We have some code to allow using libgcrypt from C++, so we also
140   should have a test case.