Re: [dsfjdssdfsd] Should secure RNGs be a MUST?

Sandy Harris <> Tue, 11 March 2014 23:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F08621A087B for <>; Tue, 11 Mar 2014 16:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ii_tcwF-9VVy for <>; Tue, 11 Mar 2014 16:46:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c01::22c]) by (Postfix) with ESMTP id A739A1A0857 for <>; Tue, 11 Mar 2014 16:46:14 -0700 (PDT)
Received: by with SMTP id jx11so9309306veb.17 for <>; Tue, 11 Mar 2014 16:46:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dN2F7zG3/2WysLafEENOW52HVyCsCcjhhF/gF8gdRyo=; b=RAvvjcVpOmp71P3gNkdP5HS3GKJqHJ78BFwL2csmQ4upeqvCVA/7/vIg11X+3VdNEP nouWn052pfskC7hJsAgiEgpR9jXNgXKmWwvwoVCfw88gu/K4kR0GMV17FE+y7VL4T7IH y+bhPQ9vACp/FFwrhRYgRuS4CP1SIREDx7g8rBKA7Q42TUHw98v2QPuNHCcn5OLx4Vjx SqnR3/hD89DQMQgt/Vb5QpNEumMsS0ZzI+6cUvkt1vJi8YnHCU5grX6u/q5XAyrvt60i z0EoOg5BQtcSMEXyKK8FNB55zhd7qmyfJpncTApglamjGyDYmGgRsu7CykA50R7hLh0L IRSw==
MIME-Version: 1.0
X-Received: by with SMTP id yv1mr32360vcb.31.1394581568502; Tue, 11 Mar 2014 16:46:08 -0700 (PDT)
Received: by with HTTP; Tue, 11 Mar 2014 16:46:08 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 11 Mar 2014 19:46:08 -0400
Message-ID: <>
From: Sandy Harris <>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: Re: [dsfjdssdfsd] Should secure RNGs be a MUST?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Mar 2014 23:46:17 -0000

On Tue, Mar 11, 2014 at 2:26 PM, Alyssa Rowan <> wrote:

> On 11/03/2014 17:08, Dan Brown wrote:
>> So, I am not totally sure about the question of whether secure
>> RNGs should be a MUST.  I wonder what others think.
> Given this list exists, I'd say yes: going forward, they MUST be. <g>
> Regarding your counterargument: I think security considerations
> warrant MUST.

Absolutely, at least in any protocols whose security properties matter,
and often elsewhere as well.

> I think secure RNGs really need to be considered a vital component to
> analyse. ...
> We should consider how robust protocols may be if those requirements
> are not met, and generally prefer (as a "safety net") protocols which
> do not fail catastrophically if the RNG is weak, ...

I cannot think offhand of a protocol that uses random numbers and
does not fail with bad ones. Sometimes, as in choosing TCP sequence
numbers, it may not matter a lot, but I am not even certain of that.

There are many examples of important security protocols that fail
disastrously -- as in do not achieve any of their design goals -- if a
weak RNG is used. Here are some:

The Diffie-Hellman key negotiation protocol -- used by at least IPsec,
SSL/TLS and SSH, and for all I know others -- can be straightforwardly
broken if either party uses a weak RNG. The break gives the enemy
the shared key, which lets him break both the encryption and the
packet-level authentication.

PGP generates a random key and uses it to encrypt the message
with an efficient block cipher. Then it uses public key methods to
safely deliver that key to recipients. A sufficiently bad RNG could
therefore break PGP.

RNGs are also required for most types of key generation for any
public key algorithm. The recent findings of massive duplication
of TLS keys (a fatal flaw) on the net was attributed mainly to
linux-based routers that failed to initialise their RNGs correctly.

The DSA algorithm may be a standard, but it is horrendously
flawed. A single use with a bad RNG or multiple uses if each
leaks a bit of random material, completely break it, letting an
attacker get the private key.

Some people, including me, suspect that such a flawed method
could only have been standardised as a deliberate attempt to
facilitate monitoring.