Subject: [dsfjdssdfsd] what not to do...

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Apr 2014 18:10:47 +0100

Hiya,

Looking at the traffic on this list I wondered if it'd
be an idea to try document the things implementers should
not do with (P)RNGs or to generate random (sets of:-)
numbers.

It seems like there's a lot of knowledge on that spread
about and if there was someone was willing and able maybe
an informational RFC about mistakes that have been made
and how implementers can avoid 'em might be useful.

Whatcha think?

Or maybe that'd just generate endless debate and offer
no useful guidance?

Or maybe there's a survey paper out there somewhere
or thesis that already has a load of that material?

Ta,
S.

---

From: Sandy Harris <[email-masked]>
Date: Wed, 2 Apr 2014 10:24:14 -0400

> and how implementers can avoid 'em might be useful.

I think the old RFC 1750 and current 4086 pretty much cover that.
https://tools.ietf.org/html/rfc4086

There has been mailing list discussion of an update to 4086, but
I do not know how that is progressing.

> or thesis that already has a load of that material?

At least two reference pages have been mentioned on
various lists. I have looked at two and found both quite
good. Unfortunately, I only recall one URL:
http://www.av8n.com/computer/htm/secure-random.htm

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 2 Apr 2014 10:57:34 -0400

Hi,

Yes, the "bad ideas" section of RFC 4086bis
(draft-eastlake-randomness3-00) seems like a good place to collect
additional things not to do.

I am planning to update that draft soon...

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

On Wed, Apr 2, 2014 at 10:24 AM, Sandy Harris <[email-masked]> wrote:
> _______________________________________________
> dsfjdssdfsd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dsfjdssdfsd

---

From: Watson Ladd <[email-masked]>
Date: Wed, 2 Apr 2014 08:18:07 -0700

> additional things not to do.

No. Do not enumerate badness. Instead model correct behavior. You will
not be able to list all the ways someone can make a mistake, but you
can explain a way to do things right. The current draft is also
missing a discussion of the impact of fork and threading on random
number generators, which can turn a perfectly working one into
something utterly broken.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Alexandre Anzala-Yamajako <[email-masked]>
Date: Wed, 2 Apr 2014 17:48:57 +0200

Watson,
In a world where everybody would only do what they qualified for and know
when to call for help I would agree with you but I think you underestimate
how many well meaning people would consider that sampling the system clock
is "unpredicatble enough".
Listing all the ways you could mess things up is obviously a lost cause but
naming a few bad ideas serves as a good cautionary tale IMO

Sincerely

-- 
Alexandre Anzala-Yamajako

---

From: [email-masked]
Date: Wed, 2 Apr 2014 08:51:04 -0700

Sent-To: 
On Wed, Apr 02, 2014 at 08:18:07AM -0700, Watson Ladd wrote:
> No. Do not enumerate badness.

Actually the PERL documentation claims that there are psychological
studies that show that prohibitions stick better than instruction on
correct behavior.

> Instead model correct behavior.

The problem with this approach is that we do not know what those are,
only what has been broken.  Our new designs will change based on what
we learn, but what has been broken will not.

Whether such instruction is appropriate for RFC or not is a valid
question.

> You will
> can explain a way to do things right.

For current assumptions, yes.
-- 
http://www.subspacefield.org/~travis/
Remediating... LIKE A BOSS

---

From: [email-masked]
Date: Wed, 2 Apr 2014 09:19:28 -0700

> naming a few bad ideas serves as a good cautionary tale IMO

I always thought that many proscriptive and prohibitive lists lack
rationale, and so a few words as to why you should not do X and Y are
worthy of inclusion.  The risk with this is that the developer thinks,
"ah, but these do not apply in my case!".  Therefore, you should
include a few examples that are so obscure that the developer would
not have thought of them (so as to humble them intellectually), and
indicate that your lists are not exhaustive, to avoid making them feel
so smart that they can ignore your warnings. IMHO.

When it comes to security, ignorance and hubris combined seem to be
the top risk, and so it helps to demonstrate to the dev that things
are not as simple as they seem right off the bat.  That is best done
by way of seemingly reasonable examples of previous attempts and how
they failed.  Lead them down a "safe" path and spring the trap on them
once, and you have a much better chance of being listened to.
-- 
http://www.subspacefield.org/~travis/
Remediating... LIKE A BOSS

---

From: Theodore Ts'o <[email-masked]>
Date: Wed, 2 Apr 2014 12:33:54 -0400

> I am planning to update that draft soon...

Is this list the best list of have discussions about that draft?  Or
are you planning on using some other wg list?

Some things that I might add as caveats is that the recommendations
about using disk timing is based on research done decades ago, and
disk drives have changed quite a bit since then.  I believe there
probably is *some* entropy in spinning disks, but it may not be as
much as possible.

In the section about clocks, it might be worthy to note that on modern
CPU's, very often many clocks are derived from a single master
oscillator.  If there are subsystems where you have two clocks that
are _not_ derived from the same oscillator, there may be an
opportunity to pick up a few bits of entropy.  (And I suspect that's
probably one of the remaining sources of entropy from disk drives
these days.)

Cheers,

						- Ted

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Apr 2014 10:02:24 -0700

On Apr 2, 2014, at 9:33 AM, Theodore Ts'o <[email-masked]> wrote:

> Is this list the best list of have discussions about that draft?

This list was created partially for the discussion of the draft.

>  Or

Let's hope not.

> probably is *some* entropy in spinning disks, but it may not be as

There are many places in the draft where it uses antiquated ideas of where to get randomness, and does not quantify them. That's why I'm generally against updating the old RFCs at all; instead, we should start fresh with just what are really the Best Current Practices.

> probably one of the remaining sources of entropy from disk drives

Personally, I have a strong hesitation of a BCP using phrases like "a few bits of entropy" if we can't measure them and if we don't even know if they exist.

--Paul Hoffman

---

From: Theodore Ts'o <[email-masked]>
Date: Wed, 2 Apr 2014 13:34:26 -0400

On Wed, Apr 02, 2014 at 10:02:24AM -0700, Paul Hoffman wrote:
> 
> Personally, I have a strong hesitation of a BCP using phrases like
> "a few bits of entropy" if we can't measure them and if we don't
> even know if they exist.

One of the problems is that there is a lot of nuance which is
required.  For example, if you can't change the hardware, on a mobile
device, one of the few sources of unpredictability might be the radio
strength --- if you grab this in early boot and if you know that the
values aren't being fed via centralized logging scheme.  It's not
really _entropy_ per se, but if you are assuming that someone sitting
in Fort Meade won't know whether your cell phone is in your knapsack
under the steel desk, or on top of the desk, it probably does add a
certain amount of protection.

Ditto grabbing touch screen information; sure, if someone has a camera
surveilling you, it might not have much unpredictabiliy, but it's
still probably a good thing to mix into your entropy pool.

And if we try to tell people that if you can't do anything at all
which is True Entropy (tm), you might as well go home, then people
might just do that.

					- Ted

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Apr 2014 11:06:50 -0700

> still probably a good thing to mix into your entropy pool.

Fully agree. We should talk about possible sources, but we should be careful to say that we are not suggesting how many bits (or fractions of a bit) those sources produce. The implementer of the RNG is fully responsible for making the source-to-bit-count assumptions.

> which is True Entropy (tm), you might as well go home, then people

That leads into the question of who the target audience for such a document should be. The committers for Linux and *BSD /dev/random don't need us to create a BCP for them; the writers of a new OS or distro might need it. An application writer should either (a) only be pulling from their OS or (b) be as smart about random sources as the OS dev so they can create their own pool. The eventual document needs to be very clear which person should be reading which part. The current document is completely unclear on this, and an application developer might think they need to understand things that we would be horrified if they tried to implement.

--Paul Hoffman

---

From: [email-masked]
Date: Wed, 2 Apr 2014 11:18:53 -0700

> probably is *some* entropy in spinning disks, but it may not be as

And then there's SSDs.

> probably one of the remaining sources of entropy from disk drives

You have to be careful in many cases things look random but are not to
someone with the right insight (c.f. whitening); measurement is not
enough.

Quoting Clive Robinson on a common HWRNG design in chips:

Faux entropy consists of many things including the outputs of complex
processes and chaotic processes inherant as side effects of the design
process. One example of which is to have two free running oscillators
one running at high speed into the D input of a D-type latch and the
slower one going into the clock input of the D-type. Close in
observation of the Q output of the latch shows both metastability and
what appeares as random behaviour. However observation at a slower
time base shows "bunching" patterns that corespond on the timebase to
the lowest frequency difference of the two oscilators. And in fact if
driven into a suitable counter circuit will produce a sinusoudal
output count... Taking what is in effect an FFT of the random source
output will show up this determanistic wave, only if it is within the
FFT Window range...
-- 
http://www.subspacefield.org/~travis/
Remediating... LIKE A BOSS

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 2 Apr 2014 14:18:40 -0400

> No. Do not enumerate badness. Instead model correct behavior. You will

No, yourself.

We had this same discussion before RFC 1750 and before RFC 4086. I
would agree that it should emphasize the right thing to do more than
it emphasizes the wrong thing to do. And I'd be fine with relegating
what not to do to an appendix or something. But I'm not willing to
dump the information from the draft about what not to do.

> something utterly broken.

Yes, there are things missing that should be added.

Thanks,
Donald

---

From: [email-masked]
Date: Wed, 2 Apr 2014 11:32:16 -0700

> which is True Entropy (tm), you might as well go home, then people

In the movie "The Sting", horse race results are delayed to allow
betting-after-the-fact; this demonstrates that with the knowledge you
have after its disclosure, unpredictability no longer exists.

So philosophically, all unpredictability is measured relative to some
knowledge set.

As a pragmatic exercise we can measure an upper bound on entropy
(using min-entropy) based on what we assume are standard assumptions,
but we don't know what we don't know.

Which is an interesting parallel to computational security assurances.

http://www.subspacefield.org/security/security_concepts/index.html#toc-Section-29

BTW, hello Paul, nice list :-)
-- 
http://www.subspacefield.org/~travis/
Remediating... LIKE A BOSS

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 2 Apr 2014 11:32:37 -0700 (PDT)

Hi Paul,

> On Apr 2, 2014, at 10:34 AM, Theodore Ts'o <[email-masked]> wrote:
[snip]
> That leads into the question of who the target audience for such a
> document should be. The committers for Linux and *BSD /dev/random don't
> need us to create a BCP for them; the writers of a new OS or distro might
> need it. An application writer should either (a) only be pulling from
> their OS or (b) be as smart about random sources as the OS dev so they can
> create their own pool. The eventual document needs to be very clear which
> person should be reading which part. The current document is completely
> unclear on this, and an application developer might think they need to
> understand things that we would be horrified if they tried to implement.

  The idea that linux and BSD developers know what they're doing and
application writers should just use their OS is an appeal to authority that
I think is increasingly falling on deaf ears these days. If you listened to
the experts at Intel you'd have just used their RNG because they know what
they're doing. But it turns out a hardware trojan can reduce the entropy
from their RNG to whatever the attacker wants it to be. Oops.

  Which is not to say that I think the people writing the RNGs for linux and
BSD do not know what they're doing, or that I know better (I certainly do
not).

  Donald is updating an existing RFC and I think the target audience for his
update is the same as that of the existing RFC.

  My hope is that another draft will be written that specifies a strong RNG
and the target audience for that would be people writing security code,
especially for embedded OSs that have a more blurred line between kernel
and application.

  regards,

  Dan.

---

From: Alexandre Carmel-Veilleux <[email-masked]>
Date: Wed, 2 Apr 2014 14:30:49 -0400

Hi,

> dump the information from the draft about what not to do.

I totally agree.

A list of known bad practices can provide ammunition to the poor software
engineers out there to convince management that fixing the RNG in $PRODUCT
is warranted. Deviance from current best practices is often not enough to
sell software development with no revenue potential to MBA types.

My 2 cents from working for an enterprise software vendor.

Alex

---

From: Theodore Ts'o <[email-masked]>
Date: Wed, 2 Apr 2014 15:10:28 -0400

> update is the same as that of the existing RFC.

Well, the current language doesn't say who is the intended audience,
and the there may be people who will be reading this that aren't who
we think should be the intended audience.  So being explicit about
this might be good.  (BTW, what do *you* think the target audience of
the current text is?)

It might also be good to have some explicit advice for different
audiences.  For example, "If you are a SOC designer, you should
include a hardware RNG, and please see FOO_REFERENCE for details about
how to create a competent hwrng."

Or, "If you are an application programmer, and your system has a
random number facility, then unless there is a really good reason not
to, you should probably use the OS's rng instead of trying to roll
your own (since you probably will get it wrong).  Alternatively, if
your crypto library has a RNG, you should use that, so long as it is
documented to be for cryptographic purposes and you have initialized
it properly per its instructions."

> especially for embedded OSs that have a more blurred line between kernel

There's an awful lot in Donald's current text which covers this
particular area already.  In fact, I'd be really worried if other
audiences (i.e., application programmers) were going to try to measure
disk timing in their application code per the instructions in RFC
4086.

So I'm not sure it makes sense to have two different drafts.  I'd
suggest being explicit about which pieces of its advice is more
suitable for different audiences.

Cheers,

					- Ted