| |||||||||||||
LCE: Don't play dice with random numbersLCE: Don't play dice with random numbersPosted Nov 21, 2012 1:00 UTC (Wed) by geofft (subscriber, #59789)Parent article: LCE: Don't play dice with random numbers
Where possible, defer the extraction of randomness as late as possible in an application. For example, in a network server that needs randomness, it is preferable to defer extraction of that randomness until (say) the first client connect, rather extracting the randomness when the server starts. That advice worries my secure-coding instinct, but I can't quite place why. One concern is about timing attacks -- that you might be able to tell if you're triggering an operation that requires crypto vs. one that doesn't by how long it waits to get randomness. Another is about DoSing the source of random data. What's the reasonable compromise here? Fetch all the randomness you need at once, but do all that fetching as late as possible?
(Log in to post comments)
LCE: Don't play dice with random numbers Posted Nov 21, 2012 1:20 UTC (Wed) by hpa (subscriber, #48575) [Link]
I think this is something where the application author is going to have to consider all the possible failure modes and decide what makes sense in their case. What it ultimately comes down to is the following: "if I can't have what I really want [unlimited entropy, instantly] what do I want to happen instead?" You have a few different options: potentially poor entropy, denial of service, etc., and you have to balance between them. The answer will frequently vary even between different usages in the same application.
However, the dearth of entropy on startup is a real problem unless you have a working HWRNG and applications really should take that into consideration.
LCE: Don't play dice with random numbers Posted Nov 21, 2012 1:38 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> However, the dearth of entropy on startup is a real problem unless you have a working HWRNG and applications really should take that into consideration.
For most applications, I think this is less of an issue than most people think. If it's just session encryption keys (SSL, etc) then the timing of the network traffic that initiates the connections will start to provide some randomness (enough that using urandom is not predictable from a practical point of view, even if the more conservative random would block)
The real issue is things like generating server encryption keys on first boot. The answer to this may be something along the lines of not starting the full system on first boot, delaying a known time period (10 seconds or so) to get a bit of entropy (potentially doing other things to try and add entropy), then generating keys and rebooting.
I think that in many cases, people are overthinking the need for 'perfect' randomness, and in the process loosing the 'good enough' security.
LCE: Don't play dice with random numbers Posted Nov 21, 2012 4:03 UTC (Wed) by vomlehn (subscriber, #45588) [Link]
I think the essence of the article is really that you should be very aware of how random things really are. Not too long ago, I needed to generate 10-bit values so that I could compute, at boot time, close-to-unique MAC addresses for the primary network interface. I let this algorithm run for a while, capturing the output. Good idea, because the first cut, just using the kernel equivalent of /dev/random, had nowhere near enough entropy and would have failed dismally. I ended up reading serial numbers and such in the hardware to help get me something useful.
LCE: Don't play dice with random numbers Posted Nov 21, 2012 5:20 UTC (Wed) by hpa (subscriber, #48575) [Link]
This is a good example, too, of where a particular *kind* of randomness properties matters for the application - in your case, you genuinely don't care if you get the same MAC on multiple boots (in fact, it probably would be a good thing.) The important thing is to avoid collisions across multiple *systems*.
The timing of network traffic that someone mentioned is not very random, and worse, it is potentially observable, which limits its utility.
LCE: Don't play dice with random numbers Posted Nov 23, 2012 21:23 UTC (Fri) by cesarb (subscriber, #6266) [Link]
> Good idea, because the first cut, just using the kernel equivalent of /dev/random, had nowhere near enough entropy and would have failed dismally. I ended up reading serial numbers and such in the hardware to help get me something useful.
Recent kernels have fixed that problem by reading serial numbers and such in the hardware and adding them to the pool on bot.
LCE: Don't play dice with random numbers Posted Nov 23, 2012 21:37 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]
the latent entropy plugin in PaX was designed for this purpose ;).
|
|||||||||||||