Re: Persisting /dev/random state across reboots
Am Donnerstag 29 Juli 2010, 21:47:01 schrieb Richard Salz: At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. Is this a good, bad, or shrug, whatever idea? I suppose the idea is that all startup procs look the same ? Indeed. The boot process of a machine is very deterministic and if you do not have any Hardware RNG you need to seed /dev/random. At least old Linux kernels (2.4) also overestimate the entropy in the pool by about 30% which is especially a problem when you generate ssh host keys during system installation. Bye Thomas -- Thomas Biege tho...@suse.de, SUSE LINUX, Security Support Auditing SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- Wer aufhoert besser werden zu wollen, hoert auf gut zu sein. -- Marie von Ebner-Eschenbach - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Persisting /dev/random state across reboots
At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. Is this a good, bad, or shrug, whatever idea? I suppose the idea is that all startup procs look the same ? tnx. -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Persisting /dev/random state across reboots
Richard Salz wrote: At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. Is this a good, bad, or shrug, whatever idea? I suppose the idea is that all startup procs look the same ? tnx. First look at http://en.wikipedia.org/wiki/Urandom There is a tremendous value in the Linux kernel technology, including extensive peer review from an IT security perspective. If you think there are security requirements not met (e.g. assurance of entropy characteristics, assurance of implementation configuration sanity), then you should state your design goals. Only thereafter we get an understanding of good, bad, or more relevant: improved. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Persisting /dev/random state across reboots
On Thu, Jul 29, 2010 at 03:47:01PM -0400, Richard Salz wrote: At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. Is this a good, bad, or shrug, whatever idea? If the entropy pool has other, reasonable/fast sources of entropy at boot time, then seeding the entropy pool at boot time with a seed generated at shutdown time is harmless (assuming a good enough entropy pool design). Else, then this approach can be a good idea (see below). I suppose the idea is that all startup procs look the same ? The idea is to get enough entropy into the entropy pool as fast as possible at boot time, faster than the system's entropy sources might otherwise allow. The security of a system that works this way depends critically on several things: a) no one reads the seed between the time it's generated and the time it's used to seed the entropy pool, b) the seed cannot be used twice accidentally, c) the system can cope with crashes (i.e., no seed at boot) such as by blocking reads of /dev/random and even /dev/urandom until enough entropy is acquired, d) the entropy pool treats the seed as entropy from any other source and applies the normal mixing procedure to it, e) there is a way to turn off this chaining of entropy across boots. (Have I missed anything?) (a) can't really be ensured. But one could be sufficiently confident that (a) is true that one would want to enable this. (d) means that every additional bit of entropy obtained from other sources at boot time will make it harder for an attacker that managed to read this seed to successfully mount any attacks on you. (e) would be for the paranoid; for most users, most of the time, chaining entropy across reboots is probably a very good idea. But most importantly, on-CPU RNGs should make this totally pointless (see previous RNG-on-CPU threads). Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Persisting /dev/random state across reboots
On Thu, 29 Jul 2010, Richard Salz wrote: At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. Is this a good, bad, or shrug, whatever idea? I suppose the idea is that all startup procs look the same ? better then not. A lot of (pseudo)random comes from disk or network interrupts. These are often similar during stock system startup. It is even more important if there is no harddisk but flashdisk, which is not contribting to entropy of the system. This was a big issue for openwrt (a Linux on Linksys routers) which booted so similarly every time that there was not enough random left at all. By saving the entropy from a longer run system at shutdown, you increase the entropy of the next boot by adding randomness from the previous state(s) Paul - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Persisting /dev/random state across reboots
On 07/29/2010 12:47 PM, Richard Salz wrote: At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. [1] Actually it typically copies from /dev/urandom not /dev/random, but we agree, the basic idea is to save a seed for use at the next boot-up. Is this a good, bad, or shrug, whatever idea? Before we can answer that, we must have a brief what's your threat model discussion. As always, I define random to mean random enough for the application. The demands vary wildly from application to application. Interesting use cases include: a) low-grade randomness: For non-adversarial applications such as Monte Carlo integration of a physics problem, almost any RNG will do. b) high-grade randomness: For high-stakes adversarial applications, including crypto and gaming, I wouldn't trust /dev/urandom at all, and details of how it gets seeded are just re-arranging the deck chairs on the Titanic. Discussion: A) For low-grade applications, procedure [1] is well suited. It is clearly better than nothing, although it could be improved. A conspicuous weakness of procedure [1] is that gets skipped if the machine goes down due to a software fault, or power failure, or really anything other than an orderly shutdown. Rather than writing the file at the last possible opportunity, it would make at least as much sense to write it much earlier, perhaps immediately after boot-up. B) At the other extreme, for high-grade applications, /dev/random is not (by itself) good enough, and asking how it gets seeded is just re-arranging deck chairs on the Titanic. Tangential remark: It would be nice if the random-seed file could be written in a way that did not deplete the amount of entropy stored in /dev/random ... but given the existing linkage between /dev/random and /dev/urandom it cannot. On the other hand, if you have reason to worry about this issue, you shouldn't be using /dev/urandom at all anyway. Remember what von Neuman said about living in sin. Tangential remark: You could worry about how carefully we need to read-protect the random-seed file (and all backups thereof). But again, if you are worried at that level of detail, you shouldn't be using a PRNG anyway. If it needs a seed, you are living in sin. Constructive suggestion: Use something like Turbid: http://www.av8n.com/turbid/ i.e. something that generates a steady stream of honest-to- goodness entropy. If you are not sure whether you need Turbid, you ought to use it. It's cheap insurance. The cost of implementing Turbid is very small compared to the cost of proving you don't need it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
