Re: Initial entropy with no HWRNG

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Tue, May 12, 2020 at 04:39:50PM +0000, Taylor R Campbell wrote:
> [trimming cc list to tech-crypto]
> 
> > Date: Tue, 12 May 2020 11:45:58 -0400
> > From: Thor Lancelot Simon <tls%panix.com@localhost>
> > 
> > 1) It's hard to understand how many bits of entropy to assign to a
> >    sample from one of these sources.  [...]
> > 
> >    The delta estimator _was_ good for these things, particularly for
> >    things like fans or thermistors (where the macroscopic,
> >    non-random physical processes _are_ expected to have continuous
> >    behavior), because it could tell you when to very conservatively
> >    add 1 bit.
> 
> What is the model you're using to justify this claim that actually
> bears some connection to the physical devices involved?

The fan's the easy example, right?  I mean, it is quite literally a physical
object in rotational motion, driven by an electric motor which should
produce smooth changes in speed and little change in acceleration.  Taking
higher-order derivatives of its position is a reasonable way to extract
the changes that are in fact due to turbulence, or so it seems to me.

There's also the fact that the ADCs on these devices produce quantization
noise.  We ought to have some extremely conservative way to characterize
_that_, at least.

But none of these give us enough data to get the system to "full entropy"
in a reasonable timeframe anyhow, so this discussion seems largely moot.
Audio sources would be different, but we'd have to characterize them
empirically just like any other amplifier noise source - including those
sold as commercial HWRNGs.

> > B) One thing we *could* do to help out such systems would be to actually run
> >    a service to bootstrap them with entropy ourselves, from the installer,
> >    across the network.  Should a user trust such a service?  I will argue
> >    "yes".  Why?
> > 
> > B1) Because they already got the binaries or the sources from us; we could
> >     simply tamper those to do the wrong thing instead.
> 
> Tampering is loud, but eavesdropping is quiet.  There is no way to do
> this that is resistant to eavesdropping without a secret on the client
> side.
> 
> (This would also make TNF's infrastructure a much juicier target,
> because it would grant access to the keys on anything running a new
> NetBSD installation without requiring tampering.)

You snipped the entire discussion of mitigations for this which was in my
original message, with no indication that you'd done so...

-- 
 Thor Lancelot Simon	                                     tls%panix.com@localhost
  "Whether or not there's hope for change is not the question.  If you
   want to be a free person, you don't stand up for human rights because
   it will work, but because it is right."	--Andrei Sakharov