From 96422a1a5059b9352f55488f2b47dfd6dfa0b423 Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Thu, 22 Mar 2007 13:55:05 +0000 Subject: Experimental support for ECDSA. This is not ready but the key generation and the self-test works. --- TODO | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 73 insertions(+), 15 deletions(-) (limited to 'TODO') 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. -- cgit v1.2.1