[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
> 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
> ? "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
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
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
46 Harvey Rd, Claremont, Cape Town 7700, South Africa
+27 21 61-3768 GMT+0200
Finger [email protected] for PGP key