3 ms·
The annoying thing is that the Linux RNG is really limiting without something like RdRand. It used to be that most drivers contributed to the randomness pool,
by nullc 13y ago
The annoying thing is that the Linux RNG is really limiting without something like RdRand.
It used to be that most drivers contributed to the randomness pool, so it seldom ran short. It used to be that you could configure the size of the pool, so if you were running short you could make it larger. But then it was discovered that the pool resizing had a locally exploitable vulnerability so it was removed, leaving it always at the smallest value; and it was realized that many driver sources weren't very random and/or were externally controllable so most were removed.
The end effect is that much server hardware only gets about 50-100 bits per second added only to a pool of 4096, and /dev/random is constantly running out leading to weird performance problems (like ssh connections taking a long time). This results in a desperate need to replace /dev/random with something like RdRand when it could just otherwise be another untrusted contributor if the rest of the system around /dev/random were sane.
- raverbashing 13y agoApparently, for some "security experts" it's damned if you do, damned if you don't If you don't use RdRand then you have few sources of "true" randomness, hence, your RNG is predictable, manipulable and you're an idiot and a 5 year old can break your crypto If you use RdRand then "blah blah blah this is opaque", hence, your RNG is predictable, manipulable and you're an idiot and a 5 year old can break your crypto Perfect solutions exist only in labs and my impression is that most of these "experts" make things less secure.
- voltagex_ 13y agoWhat happens if I tune my DVB card in, sample /dev/video0 or whatever it is now and use that to add entropy? Is that even possible?
- caf 13y agoSure, you can mix more data into the entropy pool just by writing to /dev/urandom. This won't update the entropy estimate though - to do that, you can use the the RNDADDENTROPY ioctl to add data along with the number of bits of entropy you want credited for that data (for this you need to be root, though).
- nullc 13y agoMeh. Simply making the default pool larger would go a long way towards moving systems out of a desperate situation. With that done there would be a lot less reason to short circuit it and go RdRand only. No one is concerned about RdRand as a contributing source— with other genuine source of randomness RdRand isn't likely a back door once mixed in.
- tytso 13y agoMaking the pool larger isn't sufficient for embedded systems that don't have a lot of sources of entropy in the first place. Especially since very often the most critical secrets (such as the RSA keys for the certificates used by network printers, for example) are generated when the embedded system is first installed, where even if you have a larger pool, there isn't any opportunity to fill with the extremely limited amount of entropy available to said device.
- raverbashing 13y agoYes, this is very bad in embedded systems As in your example, the only source of entropy a network printer has: network data, easy to manipulate or even no activity. So no way to generate keys for example. In some cases hardware sources are a must. Yes, in the end you'll need to trust them