Re: [dsfjdssdfsd] Any plans for drafts or discussions on here?

Paul Hoffman <> Wed, 22 January 2014 19:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4B71A1A01AF for <>; Wed, 22 Jan 2014 11:16:22 -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 UBrpfv_Sb0wZ for <>; Wed, 22 Jan 2014 11:16:21 -0800 (PST)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id 6BDAA1A0141 for <>; Wed, 22 Jan 2014 11:16:21 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.7/8.14.7) with ESMTP id s0MIuABZ001585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 11:56:11 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Content-Type: text/plain; charset="us-ascii"
From: Paul Hoffman <>
X-Priority: 3 (Normal)
In-Reply-To: <>
Date: Wed, 22 Jan 2014 11:16:18 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Dan Harkins <>
X-Mailer: Apple Mail (2.1827)
Subject: Re: [dsfjdssdfsd] 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: Wed, 22 Jan 2014 19:16:22 -0000

On Jan 22, 2014, at 10:40 AM, Dan Harkins <> wrote:

>  To minimize the possibility of someone borking their DRBG implementation
> we can include some test vectors-- instantiating with A produces state of
> B; reseeding of state B with C produces state D; generating with state D
> produces E, etc.

If we could be sure that there was no way for the mechanisms needed to test those vectors could possibly appear in an implementation, that would be great. If we can't be sure of that, we are proposing an implementer include something that could cause a catastrophic failure if those inputs are accidentally left in.

Regardless, that's not what Don's draft does.

>  The more people that implement anything will increase the probability of
> a broken implementation somewhere, I definitely agree. But it is an accepted
> economic truth that relying on a single source for anything is a bad idea.

That seems like a strawman: who says that there is a "single source" of ideas for how to implement randomness? Three large server OSs (Linux, FreeBSD, Windows) all do it differently.

--Paul Hoffman