Re: Problem with random.c and PPC

[Oliver Xymoron <oxymoron@waste.org>]

On Fri, Aug 16, 2002 at 05:51:35PM +0000, henrique wrote:
> 
> What would you do in my situation. I am dealing with the Motorola
> MPC860T and my system has no disk (I use a flash), no mouse, no
> keyboard, no PCI bus. It has just a fast-ethernet, a console port
> and some serial ports.

I've just recently dealt with analyzing this very situation in my own work.

> After reading the discussion on the lkml I realize that the only
> places I can get randomness in my system is in the serial.c (that
> controls the serial ports) and arch/ppc/8xx_io/fec.c (fast eth
> driver) interrupts.
> 
> What do you think about this solution ???

For the purposes of a network appliance, it's probably sufficient. But
if you're making a term server, beware. You may be able to trust an
interactive user who's authenticated themselves to your configuration
UI to generate randomly timed keystrokes, but you can't trust just any
signal sent to you on a serial port. 

Realistically, the hashing done by /dev/urandom is probably strong
enough for most purposes. It's as cryptographically strong as whatever
block cipher you're likely to use with it. /dev/random goes one step
further and tries to offer something that's theoretically
unbreakable. Useful for generating things like large public keys, less
useful for generating the session keys used by SSL and the
like. They're easier to break by direct attack.

If that's not good enough for you, build in a noise generator like a
reverse biased diode. 

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."