Re: [dsfjdssdfsd] specifying an RNG

Yaron Sheffer <> Fri, 15 November 2013 17:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB3B811E80E0 for <>; Fri, 15 Nov 2013 09:21:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.423
X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bya8V9XagFcL for <>; Fri, 15 Nov 2013 09:21:22 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::229]) by (Postfix) with ESMTP id 373CA21F9D8E for <>; Fri, 15 Nov 2013 09:21:22 -0800 (PST)
Received: by with SMTP id n12so2318567wgh.0 for <>; Fri, 15 Nov 2013 09:21:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=B0HRUPfoe9sJdAmycNoAH9OrxglRIMbkNIsjcia3Ag4=; b=LKCRSa36KJ/1AaYF34H4lllveZ1CjCDd55wYe526nPzzPBwm4ZnEh9rRGS/V6pQAqk +jTIFi89tbJTDkFS6Evfrr68uThDLBbWUoYPJ0NLHbBkn5L+NwuUQ7avwM1OJS0zS4K+ feS9UGuWrdCU2Nhdqj9ZAnzvLPUT+UC5KZC0sAUJyWpsEkHkE5JBQkVyNlZ1E3288zTZ 2MMp+Y3h7pH9TigKZ6+H8K0p5PYWyORqM1ZouzkPNVEXinPUW1bLAgegwG1JGL8Civkj pz3oloXSlOjdPE+QyPoBlsfAJMWMkr9EK7JZbuDYpTRa4QIJ7Fx1GltXWSYfE90NQDVB lFAg==
X-Received: by with SMTP id h10mr181645wjx.86.1384536081319; Fri, 15 Nov 2013 09:21:21 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id x19sm6881868wia.5.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 09:21:20 -0800 (PST)
Message-ID: <>
Date: Fri, 15 Nov 2013 19:21:19 +0200
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Dan Harkins <>,
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [dsfjdssdfsd] specifying an RNG
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: Fri, 15 Nov 2013 17:21:22 -0000

Hi Dan,

While I'm fully supportive of what you're out to achieve, I'm not clear 
on what it is :-)

Option A: specify requirements for an RNG (must mix multiple sources of 
randomness, must survive state disclosure, the output must not reveal 
the internal state for a standard attacker model, etc.)

Option B1: specify the deterministic part of an RNG, i.e. the crypto 

Option B2: specify the deterministic part, as well as the randomness 
sources (I'm avoiding the E word...).

Option A is important but most of us don't like requirements documents...

Option B1 is certainly fun, but traditionally such work has not been 
done in the IETF. In most cases we have recommended or adopted work done 
by other standards bodies or even individual cryptographers.

Option B2 is IMHO too OS-specific to be useful.

So which is it?