Hi, Thank you for your message.
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. 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. > > - 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. ------------------------------------------------------------------------------ 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 Retrosharefirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/retroshare-devel