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

Nick Mathewson <> Sun, 17 November 2013 03:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3A9411E8125 for <>; Sat, 16 Nov 2013 19:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.251
X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DaqrvsFRE4lJ for <>; Sat, 16 Nov 2013 19:04:43 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::235]) by (Postfix) with ESMTP id ED30511E80E9 for <>; Sat, 16 Nov 2013 19:04:42 -0800 (PST)
Received: by with SMTP id ea20so3939108lab.12 for <>; Sat, 16 Nov 2013 19:04:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=I9jRN9soYB13qfW3CyvuR+2bIo+8jTuV/5uRg4dYZ8M=; b=fQfnznCAwitmAVm5PLogblLyzHt6lcLAGvY0pYgRVjY3r5akWzuRqdBeb7daiWb5fS f7HI3Gk/QKA/eKOk1v2rh0F1rct3TpNC+s+OWIcZMrebHa1BM2zFow9N668L6PMQjlK8 MgagQ3Odr4oLFLfqQgqRgDGOOYL7SL5IZGz5IAWLx8iP38KR9hxFC7SZ4yqn6wCU6ab8 PnDvZKgdMsiTloHVmL0gPH6rn5JZp9SVk1Q9UaMHzv7d1+BSnfd28B65HMQybOuuQCDP zzWFMiHVFUE+VKM1T2DpR8Y7WBWdh5G6i27ph7dxKkIq1RZeWqOTsXhSJoHPKf/fz7Gp IB2g==
MIME-Version: 1.0
X-Received: by with SMTP id r3mr676445lag.50.1384657481511; Sat, 16 Nov 2013 19:04:41 -0800 (PST)
Received: by with HTTP; Sat, 16 Nov 2013 19:04:41 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Sat, 16 Nov 2013 22:04:41 -0500
X-Google-Sender-Auth: dO1YpzfOzsSSj07WHdPtRY1kFOk
Message-ID: <>
From: Nick Mathewson <>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: Re: [dsfjdssdfsd] What has gone wrong with RNGs in practice
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Nov 2013 03:04:43 -0000

On Fri, Nov 15, 2013 at 11:36 AM, Nick Mathewson <> wrote:
> Hi!
> G. Using the same RNG state to generate two bitstreams.
> Example: The SecureRandom structure in Android was initialized once,
> and then used as the initial SecureRandom for multiple processes. This
> led to a large compromise in Android bitcoin wallets. [7]
> Example: Python had the same problem [8]: the same RNG state was used
> after fork.

I have received a correction for this one. The original reporter of
the Python bug (Christian Heimes) informs me that the bug is not in
the main Python secure RNG (which just reads /dev/urandom or the local
equivalent), but in OpenSSL's RNG as used in Python, which ought to be
reseeded or invalidated on fork() when Python is using OpenSSL, but
which is difficult to reset from an at_fork() handler because of
issues as discussed in [14].

Additionally, Tanja Lange mentioned [12] another category of
real-world vulnerability as discussed in [13].  These might be called:

J. Using unreliable hardware entropy sources directly rather than as
inputs to a PRNG.

(The cautious behavior is to design your PRNG such that it produces
good outputs if its inputs have *ever* been random enough.)


K. Omitting run-time tests for hardware entropy sources

While some failures are undetectable, it's just tempting fate to omit
tests for detectable failures of hardware components.


best wishes,