On Thu, Jul 10, 2008 at 06:28:43PM -0400, Paul Wouters wrote: > On Thu, 10 Jul 2008, Ian Goldberg wrote: > > > The problem is that people run key generation with libgcrypt on machines > > that gather very little entropy into /dev/random, and key generation can > > literally take over an hour. > > On a desktop with IM client? They don't use disk or network IO, both of > which gather entropy (on linux)? > Which systems do people use that are so entropyless, and can we only > use /dev/urandom on those?
We have indeed had reports of people using desktop systems that don't gather entropy. There are network-based KVM switches that let you connect your physical keyboard, video, mouse to a number of different desktops, over the network (something like vnc, presumably). Those desktops then gather very little entropy, and key generation takes hours. Uli also mentioned running a command-line IM app on, for example, a router. > > I'm happy to use /dev/urandom instead, > > since the output of a PRNG that only gets, say, 200 bits of entropy, > > had better be indistinguishable from a truly random source. > > I am not sure I understand this sentence with respect to random vs urandom. As you know, /dev/random blocks if it doesn't have enough real entropy, while /dev/urandom uses the real entropy to seed a PRNG, and gives you the output of that. What my above statement was saying is that the very definition of a secure PRNG is that your probability of being able to tell the difference between its output and true random bits is "negligible" in the number of seed bits. [Here, "negligible" has a specific mathematical meaning: the probability (as a function of the number of seed bits) grows more slowly than the reciprocal of any polynomial of the number of seed bits.] So once you have a couple of hundred bits of entropy, then if an attacker can even tell that you're generating all the rest of your randomness by using /dev/urandom and not /dev/random (by looking at the output, not by the fact that you did it faster), then /dev/urandom's PRNG is totally broken and needs to be replaced. Since I definitely consider the security of Linux's /dev/urandom PRNG (and the security of its /dev/random entropy distiller, for that matter) to be someone else's task to ensure, I'm happy to use it for key generation, at least in cases where I can believe there's at least that minimal amount of entropy. Another option, of course, is for pidgin-otr to capture mouse-movement events itself and augment the PRNG seed manually. I don't think that would help Uli's situation, though. [Although it couldn't hurt, unless the performance issues of seeding the PRNG on every mouse movement becomes crazy.] - Ian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
