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