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

Dan Brown <> Tue, 11 March 2014 19:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DD0DE1A07C3 for <>; Tue, 11 Mar 2014 12:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTYPE_001C_B=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hBVWnSOfPqYq for <>; Tue, 11 Mar 2014 12:33:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 061541A04AB for <>; Tue, 11 Mar 2014 12:33:14 -0700 (PDT)
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 11 Mar 2014 15:32:40 -0400
Received: from ([fe80::45d:f4fe:6277:5d1b]) by ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 15:32:39 -0400
From: Dan Brown <>
To: "''" <>, "''" <>
Thread-Topic: [dsfjdssdfsd] Should secure RNGs be a MUST?
Thread-Index: Ac89SpfZIQJem8b1RUqwinkMRXNkhwALmx6AAAbunCA=
Date: Tue, 11 Mar 2014 19:32:39 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0000_01CF3D3F.226879E0"
MIME-Version: 1.0
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 19:33:20 -0000

Hi Alyssa,

Thanks for your input.

By the way, I believe current specs from ANSI X9F1 and NIST (in SP 800-56A
...) have taken the view that keys MUST be generated with a secure RNG, and
have gone further to specify various details of the RNG such as a DRBG
(PRNG) mechanism that MUST be one of three or four mechanisms, and further
the seeds for the DRBG must adhere to various requirements. 

I do not disagree with these requirements, from a security perspective, but
I guess I was asking whether they are in scope, or priorities, of IETF.
Maybe, IETF places such a high priority on connectivity that security is
just a close second.  

Some IETF docs refer to ECDSA, often via X9.62-2005, which, as already
noted, requires secure RNGs, namely one of the ANSI X9.82 RNGs, or any
future ANSI-approved RNGs.  So, in that regard, the IETF docs would already
inherit a MUST for secure RNGs, including the DRBG mechanisms and so on.
(Other crypto algorithms, including IETF re-specified algorithms, may not
have these ANSI/NIST requirements, I have not checked yet.)

If so, then maybe this list should discuss whether these ANSI/NIST
requirements are necessary and/or sufficient for IETF, at least in the case
of ECDSA. 

Best regards,


> -----Original Message-----
> From: dsfjdssdfsd [] On Behalf Of
> Rowan
> Sent: Tuesday, March 11, 2014 2:27 PM
> To:
> Subject: Re: [dsfjdssdfsd] Should secure RNGs be a MUST?
> Hash: SHA512
> 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
> I think secure RNGs really need to be considered a vital component to
> They have clearly been considered a vital component to
> attack: and no wonder. Insecure RNGs introduce major unexpected problems,
> including predictable keys and key leakage, in protocols which rely on
> RNGs to satisfy their security requirements. But they can be subtle, and
hard to
> verify.
> We should consider how robust protocols may be if those requirements are
> met, and generally prefer (as a "safety net") protocols which do not fail
> catastrophically if the RNG is weak, if a practical alternative exists.
But it's
> perfectly reasonable I think to also specify at the same time that the RNG
> be strong and if it isn't, you're doing it wrong.
> We know really vital problems have existed in implementations. Someone
> should figure out what any further problems may be; look for them; find
> fix them; disclose them. (Not necessarily in that order.) It seems that in
> cases, this hasn't happened. (Maybe everyone thought it was someone else's
> problem.) It needs to.
> It doesn't matter so much whose problems they are: as you correctly say,
> insecure implementation would not be securely interoperable even with a
> one. While a bad RNG is in the wild, it could be everyone's problem: I
think we
> need to do what we can to avoid that.
> - --
> /akr
> 8Uh7Nkoc7Kiy6VBadGEb7irR4+gfLhxJboAbJO3cUfqJDuEHczkTZLhiM2PV1FFS
> zHycQv8JwGs1EM2OUEX607jQgnV+3Jy/c+LTTGZJLCSEGXnvgD+BwQ7wlOfqvQq
> 4
> kWGsAe54VhvKGCb944H+pqTSeTZbCEUpTOQBaQoNl2JUAKwXY0QVk10o5dRV1
> bJt
> xXirhmV+sNVpCkcg7ExL8GkOcxQ9RLWIVAMzaAqwqH/FHK4FmLLGNWjuwePThp
> G/
> AbngohDsei7YOecMkwkcB1+14XdgAnGxfnNMXq6eslQi9XhGrF24gEQBI8JJzJ6d
> EqwrJGCRP7PVkJdAvufwgAiiP3hUURGFHjMuNZmFb7XGLO/Yeu2xKmT6Z4CsIk6j
> W1bOP7MPJsztprFQC2qtOgzV5qbsEia0/6LiXnpQRn8Zz8LkJNjpLlgzr3xsDwLj
> pLkglDVZf3HIKzIk6DuY1dAN6zcgpCS2xMa1PDyZJAS6QNXPg1Tuq2IkMSgwPt3F
> 165pALuohuWk5AL+UQsu4KgSTmHYFUl9EX5nRNgMiaNwM0NNJF37VexFIyHzc0
> 4i
> NlTHe4pW1vo4ngeIss07fN8/cS5X4ymYpmiobbi1KBjrDkUestZpFCOR1MjdGfs9
> RyY8FgwLznkNiBYuLYLc
> =sHBQ
> _______________________________________________
> dsfjdssdfsd mailing list