Re: [dsfjdssdfsd] What has gone wrong with RNGs in practice

Theodore Ts'o <tytso@mit.edu> Sat, 16 November 2013 02:42 UTC

Return-Path: <tytso@thunk.org>
X-Original-To: dsfjdssdfsd@ietfa.amsl.com
Delivered-To: dsfjdssdfsd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50EC11E8146 for <dsfjdssdfsd@ietfa.amsl.com>; Fri, 15 Nov 2013 18:42:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level:
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_11CONS_WORD=0.352]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z89uyRyRwpt6 for <dsfjdssdfsd@ietfa.amsl.com>; Fri, 15 Nov 2013 18:42:54 -0800 (PST)
Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id 455A811E8223 for <dsfjdssdfsd@ietf.org>; Fri, 15 Nov 2013 18:42:53 -0800 (PST)
Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from <tytso@thunk.org>) id 1VhVqQ-0005AF-Uv; Sat, 16 Nov 2013 02:42:47 +0000
Received: by closure.thunk.org (Postfix, from userid 15806) id 4754858087B; Fri, 15 Nov 2013 21:42:42 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1384569762; bh=ira7EZrPESjCrS8YSX+YGCiJdhUy2v10AhSd+ZWPb4U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vIExOYhkKpi1ClUYxG21EMlOr0VEg8y58DuHaOhhT2V7C7nznlXriCxfvHRvSBbvq idC9FD1w0258xFAcs01JP3+0GmQtRD5fI/iHSy5OPrguHIzcDUyRSYgtqBiaJfTsfB K5tfwYlVHqzmQpps9H79gOixrZZ8QkpxjTZ+vle0=
Date: Fri, 15 Nov 2013 21:42:42 -0500
From: Theodore Ts'o <tytso@mit.edu>
To: Nick Mathewson <nickm@torproject.org>
Message-ID: <20131116024242.GE16722@thunk.org>
References: <CAKDKvuw6EovCf6sv5SsY=NBqYKWxc1K9yV4TZjNFbHXBrt6rDQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAKDKvuw6EovCf6sv5SsY=NBqYKWxc1K9yV4TZjNFbHXBrt6rDQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Cc: dsfjdssdfsd@ietf.org
Subject: Re: [dsfjdssdfsd] What has gone wrong with RNGs in practice
X-BeenThere: dsfjdssdfsd@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Nov 2013 02:42:54 -0000

On Fri, Nov 15, 2013 at 11:36:14AM -0500, Nick Mathewson wrote:
> CC. Theoretically unsound pool constructions
> 
> See for example the recent paper on the Linux /dev/*random devices'
> constructions [10].

CC is a bit vague, and is redundant with AA, BB, and EE in your list.

The assertion made in [10] is that an attacker who can control all of
the entropy inputs in such a way that defeats the entropy estimator
(which is EE), could result in a failure of guarantees such as BB
(recovery after compromised state).

Whether or not an attacker could control all entropy inputs in such as
way that it could defeat the entropy estimator was not actually shown
in [10], and I'm not entirely sure that insisting on a theoretical
model which requires that a design should be robust against by
arbitrary control of the entropy sources (as opposed to auditing the
entropy sources actually *used* by the RNG) is a all that useful ---
but that's aside from the point I'm trying to make here, which is if
you're going to have a list of potential RNG failures, they should be
a specific set of things that you can look for, and not something
vague and overarching such as "bad design of the RNG pools".

Cheers,

							- Ted