Timeline for Feeding /dev/random entropy pool?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 15, 2013 at 20:40 | comment | added | Buktop | We may mix those bits by hashing (as example) and relatively secure produce 2^48 blocks of 512 bits length. However, I would like to recommend to use 128 bits of entropy to produce only one RSA key (3072 bits) and refresh the entropy to generate the next key. Of course it costs and does make sense to implement if you hide something that costs at least the same. | |
| Aug 13, 2013 at 21:21 | comment | added | Gilles 'SO- stop being evil' | Now work out how long it takes to deplete 160 bits of entropy. | |
| Aug 13, 2013 at 21:20 | comment | added | Buktop | Keep in mind, that /dev/random and /dev/urandom provide only 160 bits of entropy for one request. | |
| Aug 13, 2013 at 21:17 | comment | added | Gilles 'SO- stop being evil' | In practice, yes. Once you've filled in the entropy pool once, it would take more than the lifetime of the hardware to deplete it. | |
| Aug 13, 2013 at 21:15 | comment | added | Buktop | "A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver." | |
| Aug 13, 2013 at 21:14 | comment | added | Buktop | "When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered." | |
| Aug 13, 2013 at 21:13 | comment | added | Buktop | "Generating true entropy in a computer is fairly difficult because nothing, outside of quantum physics, is random. The Linux kernel uses keyboard, mouse, network, and disc activities, with a cryptographic algorithm (SHA1), to generate data for the /dev/random device. One of the problems with this is that the input is not constant, so the kernel entropy pool can easily become empty. The /dev/random device is called a "blocking device". This means if the entropy pool is empty applications trying to use /dev/random will have to wait, indefinitely, until something refills the pool." | |
| Aug 13, 2013 at 21:12 | comment | added | Buktop | Do you real think that the entropy an operating system may obtain is inexhaustible? | |
| S Aug 13, 2013 at 20:52 | review | Late answers | |||
| Aug 13, 2013 at 21:01 | |||||
| S Aug 13, 2013 at 20:52 | review | First posts | |||
| Aug 13, 2013 at 21:09 | |||||
| Aug 13, 2013 at 20:40 | comment | added | Gilles 'SO- stop being evil' |
You should read these recommendations! Especially Thomas Pornin's. You're misunderstanding entropy. Reading from /dev/random or /dev/urandom doesn't deplete entropy (at least not on a scale that would matter: reading 2^n bits depletes at most n bits of entropy).
|
|
| Aug 13, 2013 at 20:35 | history | answered | Buktop | CC BY-SA 3.0 |