Re: Initial entropy with no HWRNG

Taylor R Campbell <[email protected]> Tue, 12 May 2020 16:39:50 +0000
Newsgroups gmane.os.netbsd.devel.crypto
Message-ID <[email protected]>
[trimming cc list to tech-crypto]

> Date: Tue, 12 May 2020 11:45:58 -0400
> From: Thor Lancelot Simon <[email protected]>
>=20
> 1) It's hard to understand how many bits of entropy to assign to a
>    sample from one of these sources.  [...]
>=20
>    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?
>=20
> 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.)