Messages in this thread | | | Date | Fri, 21 Dec 2007 11:10:36 -0500 | From | "Andrew Lutomirski" <> | Subject | Re: /dev/urandom uses uninit bytes, leaks user data |
| |
On Dec 20, 2007 3:17 PM, Phillip Susi <psusi@cfl.rr.com> wrote: > Andrew Lutomirski wrote: > > I understand that there's no way that /dev/random can provide good > > output if there's insufficient entropy. But it still shouldn't leak > > arbitrary bits of user data that were never meant to be put into the > > pool at all. > > It doesn't leak it though, it consumes it, and it then vanishes into the > entropy pool, never to be seen again.
No, it's there, and if there's little enough entropy around it can be recovered by brute force.
> > > Step 1: Boot a system without a usable entropy source. > > Step 2: add some (predictable) "entropy" from userspace which isn't a > > multiple of 4, so up to three extra bytes get added. > > Step 3: Read a few bytes of /dev/random and send them over the network. > > Only root can do 1 and 2, at which point, it's already game over.
Again, no. Root could do this accidentally. Step 1 happens all the time (see the comments on non-unique UUIDs). Step 2 just requires a program to put data which it things is OK to go into the pool next to data that shouldn't be there in memory. I'm OK with the entropy pool being insecure in cases where it cannot possibly be secure. But it should not leak information that never belonged in it in the first place.
(Remember, the entire justification for Linux's model of the entropy pool seems to be that it should be as secure as possible even against computationally unbounded attackers or attackers who can find SHA preimages. A brute force attack that works sometimes and only requires 2^24 brute force iterations certainly fits into this threat model.)
--Andy
| |