Re: Initial entropy with no HWRNG

[Taylor R Campbell <campbell+netbsd-tech-crypto%mumble.net@localhost>]

[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?

Without a physically justifiable model -- one that generally works on
_all_ hardware of any type that a driver supports -- or a claim from a
vendor about what's going on in the device, that's not something we
should be fabricating from whole cloth and foisting on users.

> 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.)