[dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

djb posted a blog <http://blog.cr.yp.to/20140205-entropy.html> last
month which presents some interesting viewpoints on RNG design,
examining a hypothetical¹ scenario in which a malicious entropy source
to an otherwise good RNG can cause the sorts of havoc an attacker
dreams of.

It advocates that instead of the common
continuous-entropy-pool-injection designs we see today, a better
approach might be to make RNGs with a sharp transition between two
states:-

A. An entropy-gathering 'setup' state, collecting enough entropy for
   one really good 256-bit key, reading more-trusted entropy sources
   after less-trusted ones and using a high-cost hash function (to
   really increase the work a malicious entropy source would have to
   do); and then,

B. A 'running' state, which uses that key, holds it securely, and runs
   a good deterministic random bit generator to generate as much
   randomness as we need [up to some limit].

Specifically, djb advocates running A -then- run B (presumably, up to
some defined limit, as no DRBG is sound _ad infinitum_, then we'd have
to block and go back to A to gather another key?).

This is the exact opposite of what we usually do today, which would be
to run A continuously in parallel (possibly in many pools) and using B
in limited quantities to extract randomness from the running pool/s if
and when we need it.

I think that's a fascinating concept: although it runs counter to
usual existing practice, it does so specifically to minimise the
opportunity an attacker has to manipulate the RNG state. (One wonders
about the effect that might have on the window for an attacker to
observe the RNG state, although this _might_ be more defensible as
once in state B, it doesn't seem to provide them with an in-band path
to then exfiltrating it? Out-of-band exfiltration could be a problem
no matter which way you sliced it, although if it occurred, it would
be a live problem for longer, until the next re-key.)

It relies entirely on the DRBG to be strong for our external
prediction resistance. While this has potential pitfalls, it also has
potential benefits. After all, the DRBG is the deterministic element
of an RNG: the testable, easily-verifiable part (at least, compared to
the entropy sources). We already know several approaches that'll
probably work well (e.g. HMAC_DRBG; CTR_DRBG; a strong stream cipher
like ChaCha20 with a monotonically-increasing counter, maybe?) as well
as, of course, ones which infamously won't work out so well (e.g.
Dual_EC_DRBG).

I'm not completely sure if this type of "discrete-setup" RNG is a good
balance, but it's certainly an interesting one about which others may
have some thoughts...?

___
1. *Currently* hypothetical, but alarmingly possible for a sufficiently-
   determined attacker with a penchant for malicious microcode - and we
   know sufficiently-determined and funded attackers exist, and like
   weak RNGs. Maybe we could even see a PoC someday?

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTH2BoAAoJEOyEjtkWi2t6hE4P/3SmC3EDQvLbIUHxahpWj7j7
hd94kNr4IfByMKqwk7zMw6pW1qFsdrKvbFp7ZwEC/ZglbUptZ1taQyVDMX/ii9ZD
z7lbGDwWJN6XtLR5hn6sU5m1wkUdCHJ6FeQKgMH7sLu9tRilG6XekuYVu7bcpluQ
FJpt5MbgPjRAz43uDCO9FQrEfI0IljIIlmdmJWIAREvvaJfXwV/RnBf2mrTMUTFm
I+tyvaJn7TLc3w3L0tU+7MbRghq8UP611qeeTjpsn3HUjY6xUvSaKzeGL4J6xV3U
tq8kVc6sWCe85W8OcV2yXi7fYYAuxbxSPops83mRb2YH0Ks8Pk68o3PCvty79YpS
NeSM/jiYe0GGr3mtEXsIeYirVSdLxJuEP0lUxqSHABgHS8MsxrHQOgcR//s0V/B5
GiBwvE3xE2tf55WgGomPhs2Kqmpa6nsagwrkY6YLk5W+bV12WiCIM447DKzu86mg
O4n6DrQ7h8MMwSIt2qb90Cye48IncuXczJWIVJK3ZO6TMBR1JemwSM1WP35GUtH9
QdOAKPr+zWEwAangT8ztx05XrPAq5cxzclX9ykrF43HQhizjicX9KgcsGSR3GAYe
1b3Y9IbLQc6xMWg0iOjs6Yoo3ngiF4Z8Z75n8lbl3/PoolywGRGj3unpyvSQ4qVM
ByE6GO0YsjeIbrMo/tNs
=PuzB
-----END PGP SIGNATURE-----