Subject: [dsfjdssdfsd] specifying an RNG

From: "Dan Harkins" <[email-masked]>
Date: Thu, 14 Nov 2013 21:55:28 -0800 (PST)

Hello, and welcome to the dsfjdssdfsd list!

  At the last IETF the question was asked, "what can we do to harden
the Internet?" Given the recent news about Dual_EC_DBRG and the
dopant attack against hardware RNGs one of the things that can be
done is to have an open specification of a secure RNG. This would
allow developers to have an alternative to relying solely on
/dev/[u]random, a hardware RNG, an RNG specified by a large
government-affiliated group to mix the uncorrelated sources of
entropy they gather, or an RNG designed in an ad hoc manner by
someone who thinks he knows what he's doing but probably
doesn't.

  One of the things that would be nice to get out of this list is a
specification on a strong RNG, in the form of a BCP or Informational
RFC. This doesn't necessarily mean lets "roll our own" but perhaps
there is best practice that can be specified.

  So, is there a model that defines what a "robust RNG" would look
like? Is there a suitable candidate that exists already for such a thing?

  regards,

  Dan.

---

From: Eric Burger <[email-masked]>
Date: Fri, 15 Nov 2013 05:55:39 -0500

On Nov 15, 2013, at 12:55 AM, Dan Harkins <[email-masked]> wrote:
> done is to have an open specification of a secure RNG.

I like this idea.

> This would
> doesn’t.

History is nice, but if we produce a *standard*, one would hope the developer goes to /dev/IETFrandom. I.e., none of the issues listed above are relevant.

> there is best practice that can be specified.

How is this any different than today’s practice? Today we point to NIST, FIPS, NSA, RSA, ISO, Government Committee of the Russia for Standards, etc.

> like? Is there a suitable candidate that exists already for such a thing?

I am still having trouble understanding what would be different than what we do today. If you are proposing something akin to the open source codec work, then I am only just a bit skeptical, but I was proven wrong by that effort (it seems to be succeeding). However, if all we are doing is looking for a RNG to put into IETF standards, then are we not doing that already?

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 15 Nov 2013 10:11:01 -0500

Hi,

On Fri, Nov 15, 2013 at 5:55 AM, Eric Burger <[email-masked]>
wrote:
> History is nice, but if we produce a *standard*, one would hope the
developer goes to /dev/IETFrandom. I.e., none of the issues listed above
are relevant.
>> there is best practice that can be specified.

RFC 4086, which is on this topic, is a BCP but is out of date and doesn't
recommend a specific random number generator.
https://datatracker.ietf.org/doc/draft-eastlake-randomness3/
is the start of an effort towards a replacement but needs a lot of work.

By the way, not that I am arguing for or against it for this case, but it
is quite possible for a BCP or IETF standard to consist of a set of RFCs…

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> How is this any different than today’s practice? Today we point to NIST,
FIPS, NSA, RSA, ISO, Government Committee of the Russia for Standards, etc.
> I am still having trouble understanding what would be different than what
we do today. If you are proposing something akin to the open source codec
work, then I am only just a bit skeptical, but I was proven wrong by that
effort (it seems to be succeeding). However, if all we are doing is looking
for a RNG to put into IETF standards, then are we not doing that already?

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 15 Nov 2013 19:21:19 +0200

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

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?

Thanks,
      Yaron

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 15 Nov 2013 17:34:44 +0000

On Nov 15, 2013, at 9:21 AM, Yaron Sheffer <[email-masked]>
 wrote:

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

[Joe] Yes

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

[Joe] Yes, except choose an exiting RNG and describe how to use it to meet requirements in A

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

[Joe] While this is somewhat out of scope we ought to provide whatever guidance we can so folks can avoid common implementation errors.  I think there are useful recommendations we can make based on the list of issues posted on a different thread. 

> 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.
> 
> _______________________________________________
> dsfjdssdfsd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dsfjdssdfsd

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 15 Nov 2013 19:46:47 +0200

Works for me, including the caveat on adopting an already vetted RNG.

	Yaron

---

From: Michael Hammer <[email-masked]>
Date: Fri, 15 Nov 2013 18:40:59 +0000

I was wondering if the output would be a combination of a 
Ten Commandments and Roadmap.  (Note, ten is not a magic number)

The first part identifying the most common mistakes to avoid and what
approaches help to avoid that.
The second part pointing to organizations or bodies of work that can be
referenced to dive deeper.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Yaron Sheffer
Sent: Friday, November 15, 2013 12:47 PM
To: Joseph Salowey (jsalowey)
Cc: <[email-masked]>; Dan Harkins
Subject: Re: [dsfjdssdfsd] specifying an RNG

	Yaron

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.)
algorithm.
>>
>
> [Joe] While this is somewhat out of scope we ought to provide whatever
guidance we can so folks can avoid common implementation errors.  I think
there are useful recommendations we can make based on the list of issues
posted on a different thread.
>> 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.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 15 Nov 2013 15:14:06 -0800 (PST)

Hello,

>> the internal state for a standard attacker model, etc.)

  Actually I think should this be draft-eastlake-randomness3.
RFC 4086 (which this will update) is a good but, as Donal noted,
dated set of requirements for a good random number generator.

> [Joe] Yes, except choose an exiting RNG and describe how to use it to meet

  Yes, this is what I'm talking about. Something that someone can
implement straightforwardly. I think the potential for subtle mistakes
by someone who thinks he knows what he's doing after reading RFC
4086 (someone like me) is real and a specification that has been vetted
by some people who do know what they're doing would be valuable.

> posted on a different thread.

  I agree with Joe on this.

>> by other standards bodies or even individual cryptographers.

  Which is fine! I'm not recommending we roll our own. We have RFCs
on secure hash algorithms, on key derivation functions, we even have
one on how to do the Diffie-Hellman key exchange. None of these are
original IETF work. What we don't have, though, is one on a good RNG
and that's something that should be rectified.

  regards,

  Dan.

---

From: Russ Housley <[email-masked]>
Date: Sat, 16 Nov 2013 19:18:16 -0500

Dan:

Random or pseudorandom?  Do you care?

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 16 Nov 2013 19:20:45 -0500

Donald:

> RFC 4086, which is on this topic, is a BCP but is out of date and doesn't recommend a specific random number generator.
> By the way, not that I am arguing for or against it for this case, but it is quite possible for a BCP or IETF standard to consist of a set of RFCs…

In my mind, we should update the BCP and provide an informational document that specifies a mechanism.  I do not think that there is going to be the one true mechanism that applies to every case.

Russ

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 17 Nov 2013 00:35:45 -0800 (PST)

Hi Russ,

> Random or pseudorandom?  Do you care?

  The output has to be suitable for doing a digital signature or
a Diffie-Hellman key exchange.

  Dan.