Hi, Cyril, Thanks for the prompt response!
At Sun, 11 May 2014 17:45:48 +0200, Cyril Soler wrote: > Your concerns are absolutely funded. I'm giving detailed answers in the text > below. In summary: > the entropy collection system we're using is really not perfect, but it only > adds a bit more entropy > to the internal > PRNG of OpenSSL in case you cannot trust your own system. My understanding is that over-estimating the entropy of data mixed into the pool can decrease the entropy in the pool. From ORA's OpenSSL [1] (page 98): A common security pitfall is the incorrect seeding of the OpenSSL PRNG. There are functions that seed the generator easily enough, but the problems occur when a developer uses some predictable data for the seed. While the internal routines can quantify the amount of "seed" data, they can do nothing to determine the quality of that data (i.e., how much entropy the data contains). [1] http://shop.oreilly.com/product/9780596002701.do Network Security with OpenSSL Cryptography for Secure Communications By John Viega, Matt Messier, Pravir Chandra > On 05/11/2014 05:28 PM, Neal H. Walfield wrote: > > Hi, > > > > I took a look at how entropy is gathered when creating a new key > > (retroshare-gui/src/gui/GenCertDialog.cpp). As far as I can tell, the > > mouse position is sampled 2048 times every 20 ms, the coordinates are > > then transformed and the result is finally mixed into a PNRG managed > > by OpenSSL. I have a few concerns about this method: > > > > - Are the mouse coordinates really the only source of entropy? Is > > /dev/random never used? The only place in RS that > > RsInit::collectEntropy is called is in the callback. > No! They are mixed up with the built-in OpenSSL entropy collection system. > Depending on the host > system (windows, linux, etc) the actual methods may change. According to > OpenSSL documentation, > adding entropy should not be actually needed because OpenSSL already collects > entropy from > system/hardware events. Still, adding a bit more entropy does not hurt, > especially if you cannot > trust your system to do it. Reviewing the documentation for RAND_add [1], I see that you are indeed right: On systems that provide /dev/urandom, the randomness device is used to seed the PRNG transparently. However, on all other systems, the application is responsible for seeding the PRNG by calling RAND_add(), RAND_egd(3) or RAND_load_file(3). https://www.openssl.org/docs/crypto/RAND_add.html# Nevertheless, I find it a bit disconcerting that /dev/urandom and not /dev/random is used. The authors of ORA's OpenSSL book agree (page 101): One final point worth mentioning is that OpenSSL will try to seed the PRNG tranparently with /dev/urandom on systems that have it available. While this is better than nothing, it's a good idea to go ahead and read bettery entropy from /dev/random, unless there is a compelling reason not to. > > - A mathematical transformation will never increase entropy. In fact, > > it may decrease the amount of entropy. See for instance section 3.1 > > of Knuth's TAoCP for an amusing anecdote. Is the method you are > > using based on any solid foundations? Has it been reviewed by a > > cryptographer? > No it has not. This kind of hand-cooked code should really be reviewed by a > skilled cryptographer. > > > > - After transforming the sample, you use RsInit::collectEntropy, which > > uses RAND_seed(&n,4) to feed 4 bytes of entry to the PNRG. However, > > the coordinate space is only about 20-bits large (for a 1024x768 > > monitor, we have log_2(1024 * 768) = 19.6 bit; for FullHD+, > > log_2(1920 x 1080) = 21.0 bits). Moreover, the samples are not > > uniformly distributed: the previous sample contains a lot of > > information about the current sample (in my case, before reading the > > code, I created an identity and moved the mouse around the screen at > > an approximately constant speed thus the maximum entropy is actually > > just a small factor larger than the perimeter of a circle whose > > radius was my rate (in px/ms) * 20ms). > yes, indeed. > > > > If I were going to use the mouse position to gather entropy, then I > > would conservatively estimate about 2 bits per sample and I would > > only use the lower 3 bits of each coordinate (but I'm not a > > cryptographer). > > > > Relatedly: are there are Cryptographer's on the RS development team? > > Has the RS code base been audited? > Only amateur cryptographers ;-) The RS code hasn't been audited. Once we come > up with v0.6 official > release, > it's among our plans to have the code audited. If you have the skills to do > it, or if you want to > suggest some team/person to do that, you're welcome. Unfortunately, I'm not qualified. You may want to consider LI's 'core infrastructure initiative' one of whose goals is to fund security audits of open source projects. See [2]. [2] http://www.linuxfoundation.org/programs/core-infrastructure-initiative Thanks for the feed back! :) Neal ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Retroshare-devel mailing list Retroshare-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/retroshare-devel
