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

Arnold Reinhold <agr@me.com> Sun, 16 March 2014 15:18 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 81F7E1A01E9 for <dsfjdssdfsd@ietfa.amsl.com>; Sun, 16 Mar 2014 08:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level:
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, 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 Gquj9cvRKb2A for <dsfjdssdfsd@ietfa.amsl.com>; Sun, 16 Mar 2014 08:18:50 -0700 (PDT)
Received: from st11p01mm-asmtp002.mac.com (st11p01mm-asmtp002.mac.com [17.172.204.237]) by ietfa.amsl.com (Postfix) with ESMTP id 79B481A02F4 for <dsfjdssdfsd@ietf.org>; Sun, 16 Mar 2014 08:18:49 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Received: from arnoldsacbook15.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 <0N2J00BJCBUV0X40@st11p01mm-asmtp002.mac.com> for dsfjdssdfsd@ietf.org; Sun, 16 Mar 2014 15:18:32 +0000 (GMT)
From: Arnold Reinhold <agr@me.com>
X-Priority: 3 (Normal)
In-reply-to: <56491888.20140315165037@gmail.com>
Date: Sun, 16 Mar 2014 11:18:29 -0400
Content-transfer-encoding: quoted-printable
Message-id: <DF42CACF-3AC7-4FA9-934C-18D4A0504FB9@me.com>
References: <531F6068.4080907@akr.io> <20140311195443.GD2190@thunk.org> <F3B65184-1544-48FA-8C20-52FEAC208D8A@me.com> <56491888.20140315165037@gmail.com>
To: =?iso-8859-1?Q?Kriszti=E1n_Pint=E9r?= <pinterkr@gmail.com>
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: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaGBEKTEMXGx0EGx0YBBIZBBsdEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsYGmJCH2luHGYcGXhzB xhtGx8bEn0bEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGx0QGx4aHxsRCl5ZF2F9GHx AEQpMRhdia2sRCkNaFxsaEgQdBBgYGgQSExEKRFgXGBEKREkXGxEKQkYXbH1MRH59ZRNpXhMRC kJFF3p/fXhabExeQ2JAEQpCThdscGB5QB1iUmkaYhEKQkwXbWh7YE5jRQUFYWgRCkJsF2d+cEV EWXpIQX0cEQpCQBdkZl1mbkt+SxxZXhEKcGgXegFlW09bQRoTQXwRCnBoF2EFXlh5ElpLZVJJE QpwaBdhbkl4X2hwHltvQhEKcGgXbEgZWXpmZGgfEwERCnBoF2R6Y0JwT2AaWh1ZEQpwbBduf2R DbXN+RB5uExEKcEwXbhodWnIeY2YbfkER
X-CLX-Spam: false
X-CLX-Score: 1011
Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/H9nC2pSMKZ29MvdZtAQTqQy8NvM
Cc: dsfjdssdfsd@ietf.org
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: Sun, 16 Mar 2014 15:18:52 -0000

On Mar 15, 2014, at 11:50 AM, Krisztián Pintér <pinterkr@gmail.com>; wrote:

> 
> Arnold Reinhold (at Friday, March 14, 2014, 5:20:56 PM):
>> 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
> [...]
> 
> and these are the attacks about which djb says: your system is broken.
> don't patch it, fix it. if such attacks could be carried out, session
> keys or long term keys might have been compromised. recovering your
> prng won't help that, the damage has been done.
> 
> it is not the way to reduce the chance of any attack by a small
> factor, let the factor be a 100, or even a million, it is still small.
> what we want is systems that are reliable and safe. and if our system
> is safe, we don't need reseeding.

I am not aware of anyone who even claims to have a system that is "safe", as in free from any security bugs, much less one that remains safe from bugs being added as new software is developed and other bugs are fixed. 

And note that not all the issues I raised are software related. Tempest, for example, is a very tricky business. The NSA specs for Tempest protection are not publicly available, but I have been told they require tight physical configuration control, as even a single wire change can destroy Tempest protection.  Perhaps the best that can be achieved is to keep any attacker a safe distance from critical systems. A determined attacker might be willing to absorb the effort and risk to covertly penetrate physical security barriers if doing so will lead to a permanent compromise of a one-time-seeded PRNG, less so if the benefits will last only briefly as the PRNG reseeds after they leave.

We now have something we never had before, an apparently thorough rigorous analysis of the reseeding issue. Of course, time should be allowed for responses and critiques to the Dodis paper to emerge, but planning new security guidelines that ignore this work seems foolhardy.

Arnold Reinhold