On Thu, Oct 24, 2013 at 05:42:55PM -0400, Sandy Harris wrote:
... ifconfig > /dev/random ...
In general, building such operations into the device initialisation code in the kernel is preferable to leaving it to an external script....
And this is *already* in Linux's /dev/random code since July 2012. (There is another problem caused by proprietary binary drivers from !@#@! proprietary chips from a company whose name shall remain starting with the letter Q, forcing some home routers to still be using ancient, years-old 2.6 kernels, but that's not a problem under my control. Said 2.6 kernels probably have huge numbers of zero-day flaws, some of which might allow a remote adversary to be able to execute a buffer overflow attack in kernel space, making flaws in the random number generator somewhat irrelevant...)
It looks as though getting 64 bits or more is possible. One of the FreeBSD guys wrote on the other crypto list: http://lists.randombit.net/pipermail/cryptography/2013-October/005689.html
" We also added entropy based on device attach times. Measurements show this gives at least 4 bits of entropy per device (usually a lot more), and in the worst case we saw, 32 devices were measured.
Ted is aware of this and says looking at something similar for Linux is on his ToDo list. If something along those lines can be built and the claim of four bits per device (or even two) is correct for Linux, it appears that it would solve the problem.
There is no "solve". In all of these cases, it's going to be very dependent on the hardware involved. Many home routers might only have two or three devices, so even if you get four bits per device, that's only going to be 12 bits of extra entropy. In combination with the entropy that we get from sampling interrupts, and if the device holds off on generation of public/private keypairs until they are actually needed, hopefully it will be enough. In other cases, if there are almost no init scripts configured, and SSH keys generated as the very thing after a cold power up, even adding device attach times might not be sufficient to defeat an adversary who is doing deep analysis about your particular home router's hardware and software setup.
If not, there may be other options. Any volatile kernel table -- processes, open files, devices ... -- might provide some entropy and it would be possible to instrument some system processes (init?) or system calls so they did as well.
We are already adding the CPU time elapsed (userspace plus kernel time) for each process when it exits. The theory behind this is that we have this information anyway, and process exits are a place where adding a call to add_device_randomness() isn't going to hurt system performance. We don't credit the entropy counter with any additional randomness, but the theory is that it can't hurt, and it might help. It's hopeful that for a system that is running shell scripts as part of boot, there will be at least some entropy added by sampling these values, even if it is not a huge amount. In theory this could be done for other system timings, but we need to chose things that minimize overhead imposed on the system. - Ted _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography