Date: Wed, 5 Sep 2012 13:32:22 -0700 From: David O'Brien <obrien@FreeBSD.org> To: Doug Barton <dougb@FreeBSD.org> Cc: Arthur Mesh <arthurmesh@gmail.com>, freebsd-security@FreeBSD.org, freebsd-rc@FreeBSD.org, Mark Murray <markm@FreeBSD.org> Subject: Re: svn commit: r239569 - head/etc/rc.d Message-ID: <20120905203222.GA2920@dragon.NUXI.org> In-Reply-To: <5043DBAF.40506@FreeBSD.org> References: <201208221843.q7MIhLU4077951@svn.freebsd.org> <5043DBAF.40506@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 02, 2012 at 03:20:31PM -0700, Doug Barton wrote: > On 08/22/2012 11:43, David E. O'Brien wrote: > > Author: obrien > > Date: Wed Aug 22 18:43:21 2012 > > New Revision: 239569 > > URL: http://svn.freebsd.org/changeset/base/239569 > > > > Log: > > Remove old entropy seeding after consumption initializing /dev/random PRNG. > > Not doing so opens us up to replay attacks. > > I object to this change, and would like to see it discussed more. > > When I did the original implementation of the entropy seeding scripts > this issue was discussed, and the decision not to remove the entropy > after seeding was deliberate. Hi Doug, I would like to refresh my memory of this discussion. Can you help me narrow down the date and mailing list such that I can go find it archives? It may help me understand your POV in this thread. I've read what I could find from Bruce Schneier on entropy seeding. It is my read that to not delete the seed input goes squarely against the yarrow inventor's recommendations. I tried to document this in the commit. Do you have access to Practical Cryptography, ISBN: 0-471-22357-3 by Niels Ferguson and Bruce Schneier that you could read 10.5 and 10.6 and give your thoughts? > There are 3 possibilities. First, the > system boots normally, gets seeded, and runs for a period of time longer > than ($entropy_save_cum x cron interval), which by default is 88 > minutes. In this case all of the entropy files will be replaced, so the > "postrandom" change will be spurious. I almost agree, but not quite. My read of /usr/libexec/save-entropy is that it does not overwrite ${entropy_file}. Only that /usr/libexec/save-entropy saves additional seeding material. Thus there is still a chance of replaying (reseeding with) ${entropy_file}. I'm curious, where did the default value of ${entropy_save_num} of "8" come from? Given we're talking about real machines and thus finite constraints in space, why stuff in 8 * 2k worth of seed all at the same time? What is the improvement in the pseudo randomness in /dev/random output after that much seeding? Why not 1/2 that value (4)? Or why not 9, to maximize the amount of seeding within a single digit extension? > In the second case, the system boots successfully, gets seeded, but runs > for less than the default 88 minutes. In that case there will be at > least (uptime / cron interval) new files, and the same number of old > files removed. So while some of the entropy will be "stale" at next > reboot, it won't all be the same, so even the stale entropy is better > than nothing in helping to reseed. It seems this is a point of contention. Arthur and I disagree. I believe you do not feel seeding with (uptime / cron interval) new [/dev/random generated] files is sufficient for a good pseudo random /dev/random. Is that correct? I believe you are questioning what is enough entropy seeding for obtaining a secure key? And that it entropy_save_num(=8) is required or strongly recommended. This is such a key question that Schneier even states this is probably the hardest problem to solve in PRNG design. The yarrow design has mechanisms it uses to answer this. It tracks the number of bits of entropy fed into it to decide for itself. > In the third case, the system boots, but is then rebooted again before > the cron interval has had a chance to replace even 1 file. This is the > case where removing the old entropy is particularly pathological. It > reduces the available seeding material without adding anything new. From > a security perspective, that's worse than the possibility of a replay > attack. How is it worse? /etc/rc.d/postrandom does add something new by generating a new ${entropy_file} during this time -- providing for 4k of good entropy seed. Less assume only a 10% entropy rate. That's still 409 bits of entropy -- which I claim is good enough to prime yarrow to operate securely. > For all 3 cases, it's important to keep in mind a few things. Primarily, > yarrow is designed to avoid exactly the kind of "replay" problem that > this change was intended to fix, so it's almost certainly at best > unnecessary. I am not sure what section of http://www.schneier.com/paper-yarrow.ps.gz are you referring to. I do not see "replay" explicitly stated. Please note that section 3.1 "How PRNGs are Compromised" in the paragraph titled "Mishandling of Keys and Seed Files" Schneier states: seed files are easy to mishandle in various ways, ..., or by opening a seed file, but failing to update it every time it is used. That statement is in agreement with everything else I've seen from Schneier on this subject. Also section 5.2 "Entropy Accumulator" in the "Security Arguments" paragraph: Consider the situation of an attacker trying to predict the whole sequence of inputs to be fed into the user's entropy accumulator. ... Ultimately, an attacker in this position cannot be resisted effectively by the design of the algorithm, ... > Of nearly equal importance it should be kept in mind that > we add a non-zero amount of unique material at every boot, so a true > replay attack isn't possible, even without this change. What is the non-zero amount of unique material we seed at every boot? Most of the 'better_than_nothing' output is guessable by a local non-root account. The best thing saving us when the seed inputs are known, is the stirring in of the CPU cycle counter. > In short, this change is at best unnecessary, and possibly detrimental. I do not see how it is either of those. Please explain further. -- -- David (obrien@FreeBSD.org) Obligatory amusement: http://www.chmil.org/bruce-facts-all.txt It was based on the Schneier Axiom, which reads: "Bruce Schneier said so."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120905203222.GA2920>