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

Arnold Reinhold <agr@me.com> Fri, 14 March 2014 16:21 UTC

Return-Path: <agr@me.com>
X-Original-To: dsfjdssdfsd@ietfa.amsl.com
Delivered-To: dsfjdssdfsd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB4B1A017E for <dsfjdssdfsd@ietfa.amsl.com>; Fri, 14 Mar 2014 09:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Level:
X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB90LbhNafA1 for <dsfjdssdfsd@ietfa.amsl.com>; Fri, 14 Mar 2014 09:21:13 -0700 (PDT)
Received: from st11p01mm-asmtp002.mac.com (st11p01mm-asmtpout002.mac.com [17.172.204.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA2E1A0184 for <dsfjdssdfsd@ietf.org>; Fri, 14 Mar 2014 09:21:11 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_2JgkYjlJYKX7uiXMT2WPuw)"
Received: from new-host.home (pool-108-7-220-89.bstnma.fios.verizon.net [108.7.220.89]) by st11p01mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N2F0077RPF0DS70@st11p01mm-asmtp002.mac.com> for dsfjdssdfsd@ietf.org; Fri, 14 Mar 2014 16:21:01 +0000 (GMT)
From: Arnold Reinhold <agr@me.com>
In-reply-to: <20140311195443.GD2190@thunk.org>
Date: Fri, 14 Mar 2014 12:20:56 -0400
Message-id: <F3B65184-1544-48FA-8C20-52FEAC208D8A@me.com>
References: <531F6068.4080907@akr.io> <20140311195443.GD2190@thunk.org>
To: dsfjdssdfsd@ietf.org
X-Mailer: Apple Mail (2.1874)
x-icloud-spam-score: 34444444 f=me.com; e=me.com; is=no; ir=yes; pp=ham; spf=n/a; dkim=n/a; dmarc=n/a; wl=n/a; pwl=n/a; clxs=n/a; clxl=n/a
X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaEhEKTEMXGx0EGx0YBBIZBBsSEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsZGmJCH2lmG2RYGXhzB xhvGxwYGxsfEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGxIQGx4aHxsRCl5ZF2F9ZG9 jEQpMRhdsa2sRCkNaFxsaEgQdBBgYGgQSExEKRFgXGREKREkXGBEKQkYXbH1MRH59ZRNpXhMRC kJFF3p/fXhabExeQ2JAEQpCThdscGB5QB1iUmkaYhEKQkwXbWh7YE5jRQUFYWgRCkJsF2d+cEV EWXpIQX0cEQpCQBdgWk1uTGdtXEFDTREKcGgXb0hQR0Nbf216E18RCnBoF2MeUEd8aGt5fkl4E QpwaBdsHGVNfhITZW1hUxEKcGgXbgFlYU95b19+eVkRCnBoF2tTcHNQHRxhaRh6EQpwfxdrQB5 hWHhyWk1QWxEKcF8Xb31BQUBoYGVbaWYRCnB/F2hTbAVGXBl6HmMcEQpwXxdoWRJZc0xIbhsST hEKcGwXbn9kQ21zfkQebhMR
Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/av8N3Nf4irRRLrXaUhla4bEO5Iw
Cc: Alyssa Rowan <akr@akr.io>, Theodore Ts'o <tytso@mit.edu>
Subject: Re: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets
X-BeenThere: dsfjdssdfsd@ietf.org
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." <dsfjdssdfsd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dsfjdssdfsd/>
List-Post: <mailto:dsfjdssdfsd@ietf.org>
List-Help: <mailto:dsfjdssdfsd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Mar 2014 16:21:16 -0000

Here are some scenarios where recovery from a state compromise would be important:

o A bug in system software that exposes PRNG state only rarely
o An attack that that exposes PRNG state in a system that is well guarded against covert channels, limiting undetected outbound messages to very low bit rate
o An attack that exposes PRNG state which requires physical access to a computer in a well guarded location, for example a Tempest attack where receiving equipment must be placed close to the system under attack
o A flaw in the hash algorithm used to protect the PRNG state that takes massive processing power to exploit
o Any attack that reveals only part of the PRNG state, forcing an expensive search to recover the unknown portion 

My response to the expected question "How likely are any of these situations, really?" is "How difficult is it to implement a PRNG that safely and rapidly recovers from a state compromise?"  If you believe the Dodis paper (http://www.cs.nyu.edu/~dodis/ps/rng.pdf), not very.

We know that both criminal organizations and state actors devote great effort to find any weaknesses. In particular, the expected rapid advance of the "Internet of Things" will produce many black-box diskless devices, some in critical functions, that have minimal entropy sources and software that is updated infrequently or never. I suggest that the Internet of Things should be a primary test case for any new RNG standards activity.

Arnold Reinhold

On Mar 11, 2014, at 3:54 PM, Theodore Ts'o <tytso@mit.edu>; wrote:

> On Tue, Mar 11, 2014 at 07:13:44PM +0000, Alyssa Rowan wrote:
>> 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?).
> 
> I'll note that an criteria for judging RNG's which is very popular
> with academics who love to write papers poking (theoretical) holes
> into random number generators is how quickly a RNG can recover from
> state compromise.
> 
> One of the reasons why some people love RNG's such as Fortuna and
> Yarrow is that it is specifically designed to recover from state
> compromises --- and the scheme which djb has suggested would do poorly
> on that particular metric.
> 
> Does it matter?  Well, entire virtual forests of electronic trees have
> been felled by people speculating on whether fast/reliable recovery
> from state recovery is critically important compared to other design
> considerations.
> 
> Personally, my take is that if you can compromise the state of the
> RNG, you can probably far more damage, so I'm not convinced state
> compromise is a very high priority threat to defend against.  But
> there are tons and tons of academic papers which are convinced that
> any RNG which doesn't worry about this attack is Fatally Flawed.
> 
>    	      	      	    	       	      - Ted
> _______________________________________________
> dsfjdssdfsd mailing list
> dsfjdssdfsd@ietf.org
> https://www.ietf.org/mailman/listinfo/dsfjdssdfsd