Am Sonntag, 3. November 2013, 07:41:35 schrieb Theodore Ts'o: Hi Theodore, >On Sun, Nov 03, 2013 at 08:20:34AM +0100, Stephan Mueller wrote: > >Sandy Harris pointed out a very good paper that I would definitely >recommend that people read: > >http://lwn.net/images/conf/rtlws11/random-hardware.pdf > >It basically describes some efforts made in 2009 by folks to do >exactly the sort of experiments I was advocating. What I actually I am wondering whether you have seen my last measurements where I effectively performed the tests you were asking for: disabling all possible CPU features and selectively enabling them. The tests described in the above mentioned documents and much more are all already in the test suite and test results I present here. >think is more important, though, is not the doing of the experiments, >but the development the tools to do these experiments. If people can >create kernel modules (and they have to be done in the kernel, since >you need to be able to disable interrupts, L1 caches, etc., while you >run these tests), then it will be possible to do these experiments >each time a new CPU comes out from Intel, or each time an ARM hardware >vendor comes out with a new ARM SOC. The test code is available and it is executed in kernel space. > >It's important that these tests are done all time, and not, "OK, we Again, the code is there for the taking, including the analysis part. Yes, it can be easily converted into a fully automated test such that at the end a result of "CPU shows sufficient variations for the RNG" or not. Therefore, I am asking again: - Which other CPU mechanisms can I disable that I did not so far? - The execution time measurements when disabling CPU features show that there is still significant variations available. Given the fact that an adversary is not able to disable the features as I did, he will not be able to reduce the variations induced by the features. He may alter them potentially, but there are still variations which he cannot affect, let alone predict. Therefore, how shall an adversary make predictions of the variations to weaken the RNG? I heard a nice statement from the developer who implemented the /dev/random device of a different, respected operating system: the last step to accept the underlying root cause of uncertainty for an RNG always requires a leap of faith. Looking at typical noise sources that sounds about right. For example: - how can we be sure that nobody who measures the key stroke interrupts can do that with a precision that is higher than the estimated entropy the key stroke is awarded (note, an adversary has the means to observe key strokes)? Same applies to mouse movements. Note that X11 allows you to measure these events precisely (the xev application should give a glimpse). - how can we be sure that fast_pool exhibits no correlation with the other noise sources? - how can we be sure that the HDD fluctuations are random? We simply accept that these issues do not allow predicting sequences to the extent that weakens the RNG. My goal is to give another seed source to add even more uncertainty into the Linux RNG in addition to the existing seed sources. This would also support environments that were typically left in the rain so far, such as virtual machines, early boot sequences, Live CDs, or headless systems without a spinning disk. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
