From: Mark Murray <mark@grondar.za>
Date: Wed, 1 Nov 1995 02:48:07 +0800
To: "Theodore Ts'o" <tytso@MIT.EDU>
Subject: Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
Message-ID: <199510311715.TAA05821@grumble.grondar.za>
MIME-Version: 1.0
Content-Type: text/plain


>    How about SetGID? We were going for 660 root.kmem.
> 
> Bad idea; anyone who can run PGP could then get instant access to kmem

Fooey. Of course. Scratch that plan.

> 	cd /tmp
> 	ln -s /dev/kmem foo
> 	pgp -e tytso foo
> 	rm foo
> 	pgp foo.pgp

Eeeeek!

>    ? "Gut feel" suggests to me that large ammounts of "predicted" input might
>    be worse than the normal sort of system noise you have been using.
> 
> But keep in mind that what we're doing is XOR'ing the input data into
> the pool.  (Actually, it's a bit more complicated than that.  The input
> is XOR'ed in with a CRC-like function, generated by taking an
> irreducible polynomial in GF(2**128).  But for the purposes of this
> argument, you can think of it as XOR.)  So since you don't know what the
> input state of the pool is, you won't know what the output state of the
> pool.

I chatted with a colleague at work, and he helped bend my mind right.
I had the mistaken notion that adding lots of data would "overflow"
and "dilute" the entropy to an attackable state.

>    Is this millisecond accuracy quantifiable in terms of bits of entropy?
>    if so, the ethernet is surely safe?
> 
> Well, no.  If you're only using as your timing the 100Hz clock, the
> adversary will have a better timebase than you do.  So you may be adding
> zero or even no bits of entropy which can't be deduced by the adversary.

In a 386 or a 486 (under FreeBSD at least) there is a 1Mhz clock available.
How would _this_ be? On the Pentium there is the <whatsit?> register
which will give the board's oscillator (or 90 MHz) I believe.

> This is even worse in the PGP keyboard timing case, since the adversary
> almost certainly can find a better time resolution to measure your
> incoming packets when compared to the timing resolution that most
> programs have.  Far too many Unix systems only make a 100Hz clock
> available to the user mode, even if you have a better quality high
> resolution timing device in the kernel (for example, the Pentium cycle
> counting register).

Ah yes - _that_ register. :-)

What then is a body to do? Preserve all _verifiable_ randomness like gold?
Dish it out under some quota? A denial of service attack would be

forever {
	cat /dev/random > /dev/null
}

Severely limiting most decent folk's chance at getting PGP to work.

Right now I am considering making a piece of cheap hardware to deliver
noise to a digital input. (Electronics is a stagnant hobby of mine)
Interested? I may knock up a prototype in a month or so...

> The problem is that in order to do this requires making assumptions
> about what the capabilities of your adversary are.  Not only does this
> change over time, but certain adversaries (like the NSA) make it their
> business to conceal their capabilities, for precisely this reason.

Can they predict thermal noise in a cheap transistor? ]:->

> So I like to be conservative and use limits which are imposed by the
> laws of physics, as opposed to the current level of technology.  Hence,
> if the packet arrival time can be observed by an outsider, you are at
> real risk in using the network interrupts as a source of entropy.
> Perhaps it requires buidling a very complicated model of how your Unix
> scheduler works, and how much time it takes to process network packets,
> etc.  ---- but I have to assume that an adversary can very precisely
> model that, if they were to work hard enough at it.

This is a strong argument for some form of specialised noise source.
I have read of methods of getting this from turbulent air flow in a hard
drive (an RFC, I believe).

> People may disagree as to whether or not this is possible, but it's not
> prevented by the laws of physics; merely by how much effort someone
> might need to put in to be able to model a particular operating system's
> networking code.  In any case, that's why I don't like depending on
> network interrupts.  Your paranoia level may vary.

If I was running Fort Knox, I'd probably use Radioactive decay...

(From my experience working at a cyclotron facility - these SOB's are
_*RANDOM*_)

M
--
Mark Murray
46 Harvey Rd, Claremont, Cape Town 7700, South Africa
+27 21 61-3768 GMT+0200
Finger mark@grumble.grondar.za for PGP key