1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
What's left to do -*- outline -*-
* 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.
* 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 maintaint 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.
* 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.
* 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.
|
