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