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

The ANSI/NIST standards already require seeding with entropy equal to the security level before generating any outputs: i.e. your setup state A (minus the high-cost hash functions).  Also, aren't some linux RNGs blocking, isn't that a similar idea.  Maybe I should read the blog.

Anyway, it may well be true that many RNG implementations do not operate this way.  That's a problem, and they wouldn't be compliant to the latest ANSI/NIST specs.

On the research side, Barak and Halevi describe an algorithm with good and bad states, if I recall correctly, in an effort to model malicious seeds (with adequate entropy).

> -----Original Message-----
> From: dsfjdssdfsd [mailto:dsfjdssdfsd-bounces@ietf.org] On Behalf Of Alyssa
> Rowan
> Sent: Tuesday, March 11, 2014 3:14 PM
> To: dsfjdssdfsd@ietf.org
> Subject: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets
> 
> -----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+bV12WiCIM447DKzu86
> mg
> O4n6DrQ7h8MMwSIt2qb90Cye48IncuXczJWIVJK3ZO6TMBR1JemwSM1WP35GU
> tH9
> QdOAKPr+zWEwAangT8ztx05XrPAq5cxzclX9ykrF43HQhizjicX9KgcsGSR3GAYe
> 1b3Y9IbLQc6xMWg0iOjs6Yoo3ngiF4Z8Z75n8lbl3/PoolywGRGj3unpyvSQ4qVM
> ByE6GO0YsjeIbrMo/tNs
> =PuzB
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> dsfjdssdfsd mailing list
> dsfjdssdfsd@ietf.org
> https://www.ietf.org/mailman/listinfo/dsfjdssdfsd