Re: [Cryptography] Finding Entropy Isn't That Hard
On 09/12/2013 10:41 AM, Kent Borg wrote: routers and servers are not as bad off as people say. Not that more sources is bad. A new trustworthy HW entropy source would be good. Even a suspect rdrand is worth XORing in (as Linux does on the machine I am using right now). But if you thirst for more entropy keep looking in your current hardware, server boxes are particularly good hunting grounds for a few more dribs of entropy: - current RPM of all the fans (the proverbial entropy-starved server can have a lot of fans) - temperatures - voltages - disk (SMART) statistics (temperatures and error counts, multiplied by the number of disks) These are all things that could wear out or go wrong, which means they need monitoring because...you can't otherwise know what they are. Cool, that's a decent definition of entropy. Sample them regularly and hash them into your entropy pool. Not a lot of bandwidth there, but if your RNG does a good job of hiding its internal state, and you are mixing in a dozen more bits here and a dozen more bits there...pretty soon you have made the attacker's job a lot harder. Maybe not as sexy as a lavalamp or radioactive gizmos, but more practical and available now. -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Finding Entropy Isn't That Hard
[* Until Linux kernel 3.6 the person maintaining urandom was busily turning off interrupts as a source of entropy, I think because he didn't know how much entropy he was getting so better not to get it at all (huh?). In 3.6 this was changed to use all interrupts as entropy sources, which is good. This means earlier kernels aren't so good--though I notice that Ubuntu's kernel has the 3.6 improvement in their version of 3.2, so individual distributions will vary.]-kb I'll also observe that on new mobile platforms, there are typically a flotilla of physical-world sensors. The low-level drivers for these should be contributing entropy to the pool in the kernel. At the apps layer, typically, the "raw" sensor values have been filtered by application-specific algorithms, so that they're less useful as entropy sources at that level. For example, low-G accelerometers are quite noisy -- these are typically used as multi-axis rotation sensors (they use the gravity-field orientation to sense rotation). Any physical-world sensor driver, where the sensor inherently has a bit of noise, I think has a "moral obligation" to contribute bits to the kernel entopy pool. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Finding Entropy Isn't That Hard
On 09/13/2013 11:59 AM, Marcus Leech wrote: Any physical-world sensor driver, where the sensor inherently has a bit of noise, I think has a moral obligation to contribute bits to the kernel entopy pool. Within limits. Mixing the entropy pool on Linux takes work and battery power. Looking at some random Android kernel source code (git commit c73c9662) it looks like add_interrupt_randomness() is happening for every interrupt (your Android device's kernel may vary), so there is probably plenty of entropy. And add_interrupt_randomness() throttles to only feed the randomness once a second, not wasting our time or battery. Don't carry moral obligation beyond what is reasonable! -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
