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

Dan Brown <> Tue, 11 March 2014 19:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 172541A07D4 for <>; Tue, 11 Mar 2014 12:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jhKsm7oRovKy for <>; Tue, 11 Mar 2014 12:48:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7D4BF1A07D8 for <>; Tue, 11 Mar 2014 12:48:32 -0700 (PDT)
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 11 Mar 2014 15:48:25 -0400
Received: from ([fe80::45d:f4fe:6277:5d1b]) by ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 15:48:24 -0400
From: Dan Brown <>
To: "''" <>, "''" <>
Thread-Topic: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets
Thread-Index: AQHPPV5IJGLa+MVjDkCv/yPQoN7tTZrcSQPg
Date: Tue, 11 Mar 2014 19:48:24 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Mar 2014 19:48:40 -0000

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 [] On Behalf Of Alyssa
> Rowan
> Sent: Tuesday, March 11, 2014 3:14 PM
> To:
> Subject: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets
> Hash: SHA512
> djb posted a blog <> 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
> 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
> _______________________________________________
> dsfjdssdfsd mailing list