Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Sep 2012 14:27:42 +0100
From:      RW <rwmaillists@googlemail.com>
To:        Arthur Mesh <arthurmesh@gmail.com>
Cc:        freebsd-rc@freebsd.org, freebsd-security@freebsd.org, Doug Barton <dougb@freebsd.org>
Subject:   Re: svn commit: r239569 - head/etc/rc.d
Message-ID:  <20120907142742.5436e72a@gumby.homeunix.com>
In-Reply-To: <20120906224703.GD89120@x96.org>
References:  <5043DBAF.40506@FreeBSD.org> <20120903171538.GM1464@x96.org> <50450F2A.10708@FreeBSD.org> <20120903203505.GN1464@x96.org> <50451D6E.30401@FreeBSD.org> <20120903214638.GO1464@x96.org> <50453686.9090100@FreeBSD.org> <20120904220754.GA3643@server.rulingia.com> <20120906174247.GB13179@dragon.NUXI.org> <20120906230157.5307a21f@gumby.homeunix.com> <20120906224703.GD89120@x96.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 6 Sep 2012 15:47:03 -0700
Arthur Mesh wrote:


> > Once something changes you get a completely
> > different sequence of yarrow cipher-keys; a counter or writing out
> > a new entropy file will both do this, but OTOH so will any
> > difference in harvested entropy such a sub-nanosecond difference in
> > timing.
> 
> You're correct. Are you arguing that we shouldn't recycle /entropy
> after it's used? 

No, I was pointing out that a counter does make a difference because
it *unconditionally* allows yarrow to continue working as a secure PRNG
across reboots with the same secure entropy file. 


Replacing the entropy file is desirable if you are concerned that an
attacker might gain access to it and try to reconstruct the early state
of yarrow. I don't regard that as a particularly serious threat, anyone
that gains root or physical access will have better things to do. 


I'm not averse to rewriting /entropy provided that you can guarantee
that that the entropy has made it into the yarrow entropy pools and
the subsequent slow reseed has completed before the new file is
written out. Overwriting an entropy file that secures yarrow against
remote attacks with one that might not would be a retrograde step.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120907142742.5436e72a>