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

"Dan Harkins" <> Wed, 22 January 2014 20:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 25D8D1A0490 for <>; Wed, 22 Jan 2014 12:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pwl6r7gSbcfp for <>; Wed, 22 Jan 2014 12:29:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A18751A0493 for <>; Wed, 22 Jan 2014 12:29:04 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id D0C8810224008; Wed, 22 Jan 2014 12:29:03 -0800 (PST)
Received: from (SquirrelMail authenticated user by with HTTP; Wed, 22 Jan 2014 12:29:04 -0800 (PST)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 22 Jan 2014 12:29:04 -0800
From: Dan Harkins <>
To: Paul Hoffman <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
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 20:29:08 -0000

On Wed, January 22, 2014 11:16 am, Paul Hoffman wrote:
> 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.

  That seems like an absurdly high bar-- that there is no way someone
could so something demonstrably stupid. We use test vectors when
specifying things like HKDF or AES-<pick your mode> and no one
seems to generate a function that only accepts those inputs and only
produces the specified outputs. I really don't think people will suddenly
start  hard-coding test vectors into code now.

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

  I'm still hoping that an Informational RFC on a good DRBG will be

>>  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.

  The single source is "your OS". While there are 3 large server OSs, there
is no single application that can obtain randomness from all three since
there is no application that runs on all of them (and my experience is
that a single linux application won't necessarily work from version X of
the OS to version Y-- hell, sometimes the source won't even compile).

  And you know, the "if we could be sure there was no way…" thing works
both ways, especially regarding a large (monopoly) OS whose track
record on security and code quality is not perfect.