Re: [dsfjdssdfsd] Discussion: Malicious Entropy Attacks: Eggs, and Baskets
ianG <iang@iang.org> Sat, 15 March 2014 14:16 UTC
Return-Path: <iang@iang.org>
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 CA6F91A01DD for <dsfjdssdfsd@ietfa.amsl.com>; Sat, 15 Mar 2014 07:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6] autolearn=no
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 uOs2Y7euwmQw for <dsfjdssdfsd@ietfa.amsl.com>; Sat, 15 Mar 2014 07:16:38 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFEC1A01D2 for <dsfjdssdfsd@ietf.org>; Sat, 15 Mar 2014 07:16:38 -0700 (PDT)
Received: from tormenta.local (www2.futureware.at [78.41.115.142]) by virulha.pair.com (Postfix) with ESMTPSA id A0A526D46D; Sat, 15 Mar 2014 10:16:29 -0400 (EDT)
Message-ID: <532460BB.2080808@iang.org>
Date: Sat, 15 Mar 2014 14:16:27 +0000
From: ianG <iang@iang.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dsfjdssdfsd@ietf.org
References: <mailman.64.1394650814.4986.dsfjdssdfsd@ietf.org>
In-Reply-To: <mailman.64.1394650814.4986.dsfjdssdfsd@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/h7JQNYwPuNm92wjwzr0vtbeUmVk
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: Sat, 15 Mar 2014 14:16:41 -0000
> Theodore Ts'o <tytso@mit.edu> > 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. Responding to Ted to highlight the opposing view, ... Schneier in a sense responds in today's Cryptogram: ** *** ***** ******* *********** ************* The Security of the Fortuna PRNG Providing random numbers on computers can be very difficult. Back in 2003, Niels Ferguson and I designed Fortuna as a secure PRNG. Particularly important is how it collects entropy from various processes on the computer and mixes them all together. While Fortuna is widely used, there hadn't been any real analysis of the system. This has now changed. A new paper by Yevgeniy Dodis, Adi Shamir, Noah Stephens-Davidowitz, and Daniel Wichs provides some theoretical modeling for entropy collection and PRNG. They analyze Fortuna and find it good but not optimal, and then provide their own optimal system. Excellent, and long-needed, research. http://eprint.iacr.org/2014/167 Fortuna: https://www.schneier.com/fortuna.html ** *** ***** ******* *********** ************* Which abstract aptly describes the approach of the threat model, and the challenges that it inspires, as well as promising a solution: ** *** ***** ******* *********** ************* How to Eat Your Entropy and Have it Too -- Optimal Recovery Strategies for Compromised RNGs Yevgeniy Dodis and Adi Shamir and Noah Stephens-Davidowitz and Daniel Wichs Abstract: Random number generators (RNGs) play a crucial role in many cryptographic schemes and protocols, but their security proof usually assumes that their internal state is initialized with truly random seeds and remains secret at all times. However, in many practical situations these are unrealistic assumptions: The seed is often gathered after a reset/reboot from low entropy external events such as the timing of manual key presses, and the state can be compromised at unknown points in time via side channels or penetration attacks. The usual remedy (used by all the major operating systems, including Windows, Linux, FreeBSD, MacOS, iOS, etc.) is to periodically replenish the internal state through an auxiliary input with additional randomness harvested from the environment. However, recovering from such attacks in a provably correct and computationally optimal way had remained an unsolved challenge so far. In this paper we formalize the problem of designing an efficient recovery mechanism from state compromise, by considering it as an online optimization problem. If we knew the timing of the last compromise and the amount of entropy gathered since then, we could stop producing any outputs until the state becomes truly random again. However, our challenge is to recover within a time proportional to this optimal solution even in the hardest (and most realistic) case in which (a) we know nothing about the timing of the last state compromise, and the amount of new entropy injected since then into the state, and (b) any premature production of outputs leads to the total loss of all the added entropy {\em used by the RNG}, since the attacker can use brute force to enumerate all the possible low-entropy states. In other words, the challenge is to develop recovery mechanisms which are guaranteed to save the day as quickly as possible after a compromise we are not even aware of. The dilemma that we face is that any entropy used prematurely will be lost, and any entropy which is kept unused will delay the recovery. After developing our formal definitional framework for RNGs with inputs, we show how to construct a nearly optimal RNG which is secure in our model. Our technique is inspired by the design of the Fortuna RNG (which is a heuristic RNG construction that is currently used by Windows and comes without any formal analysis), but we non-trivially adapt it to our much stronger adversarial setting. Along the way, our formal treatment of Fortuna enables us to improve its entropy efficiency by almost a factor of two, and to show that our improved construction is essentially tight, by proving a rigorous lower bound on the possible efficiency of any recovery mechanism in our very general model of the problem. ** *** ***** ******* *********** ************* (caveat, I haven't read the paper, so have no idea if the holy grail is delivered) iang
- [dsfjdssdfsd] Discussion: Malicious Entropy Attac… Alyssa Rowan
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… Dan Brown
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… Theodore Ts'o
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… =JeffH
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… Dan Brown
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… Arnold Reinhold
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… ianG
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… Krisztián Pintér
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… Arnold Reinhold
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… tytso
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… Arnold Reinhold
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… tytso
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… Arnold Reinhold
- Re: [dsfjdssdfsd] Discussion: Malicious Entropy A… Arnold Reinhold