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

"Dan Harkins" <> Wed, 22 January 2014 18:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E83381A0158 for <>; Wed, 22 Jan 2014 10:40:36 -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 wBgCXpTZM8CI for <>; Wed, 22 Jan 2014 10:40:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 922CC1A011C for <>; Wed, 22 Jan 2014 10:40:35 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 1D9E41022404A; Wed, 22 Jan 2014 10:40:34 -0800 (PST)
Received: from (SquirrelMail authenticated user by with HTTP; Wed, 22 Jan 2014 10:40:34 -0800 (PST)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 22 Jan 2014 10:40:34 -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
Cc:, Dan Harkins <>
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 18:40:37 -0000

On Wed, January 22, 2014 8:28 am, Paul Hoffman wrote:
> On Jan 22, 2014, at 8:13 AM, Dan Harkins <> wrote:
>>  I see value in draft-eastlake-randomness3 and I also see value in an
>> Informational RFC on a good DRBG for those who feel the need to have
>> a belt as well as suspenders.
> We disagree here; the chance that the person writing the belt will get it
> wrong and make their crypto trivial to break for an attacker who knows the
> weakness seems much higher to me than the change that the OS got it wrong.
> Yes, we could put some warning at the front of the new document about
> this, but that warning will be ignored by programmers who are sure they
> know this stuff.
> I could see writing something that forces them to mix in randomness from
> the OS to their possibly-borked DRBG in the hopes that at least that step
> will fix their problems. However, if we do that, nearly all the
> interesting technical stuff in the current document is just confusing
> fluff. The new document reduces to "use an HMAC with the randomness from
> your OS as the key and whatever stuff you think is random as the data;
> done".

  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.

  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.