Re: [dsfjdssdfsd] evaluating stuff (was: Re: Any plans for drafts or discussions on here?)

Paul Hoffman <> Thu, 23 January 2014 18:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AAD321A0096 for <>; Thu, 23 Jan 2014 10:01:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zd7uebg3ZUWb for <>; Thu, 23 Jan 2014 10:01:20 -0800 (PST)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id E0AA81A0091 for <>; Thu, 23 Jan 2014 10:01:17 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.7/8.14.7) with ESMTP id s0NHeabU031422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Jan 2014 10:40:37 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Thu, 23 Jan 2014 10:00:45 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <03f201cf17ee$e34ccbf0$a9e663d0$> <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.1827)
Subject: Re: [dsfjdssdfsd] evaluating stuff (was: Re: Any plans for drafts or discussions on here?)
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: Thu, 23 Jan 2014 18:01:24 -0000

On Jan 23, 2014, at 1:57 AM, Stephen Farrell <> wrote:

> But I do wonder to what extent we're finding such evaluations
> really useful.


> I know they are formal form-filling requirements
> in various contexts, but I'm not so sure I'm that comfortable
> treating them as a first order requirement when it comes to
> things we do in the IETF.

Quite right. The base requirement boils down to "prove that input X gave the DBRG N bits of entropy that could not be known by any external system". That proof is always hand-waving for nearly any typical computer or network device. If the inputs are chosen conservatively enough, you can be confident that you got N unguessable bits, but you cannot prove it.

> I have seen a number of credible arguments that such schemes,
> as applied to crypto implementations, are actually counter-
> productive.

Exactly. Vendors tend to copy the claims of other systems that have earlier passed the evaluations, even when the claims do not fully apply to the new system. After a few rounds of this, the claims are meaningless and the vendor is not trying hard enough to get truly random bits.

> So - how important is it that any new work in the IETF on
> this topic be consistent with a requirement for implementations
> to be evaluated via such schemes?
> My take would be that that's not hugely important and should
> lose out to "doing the right thing," but given that some folks
> do need to suffer such evaluations, we should think about 'em
> but treat any evaluation-scheme-specific requirements only as
> nice-to-have level requirements.

Advice on where you might find the bits in typical computers and network boxes is probably useful. Advice about the value of N for input X is actively dangerous.

--Paul Hoffman