bet at rahul.net
Wed Mar 31 19:54:27 PST 2004
2004-04-01T03:26:34 Robert Connolly:
> Non-crypto quality runtime random number generator for libc.
> For when you want a random value for single use.
If you don't need crypto quality, then seed w/ pid^time.
> Take the values from gettimeofday, getpid, and environ. Gettimeofday is
> predictable, but knowing the microsecond a function was executed on isn't so
usec-res time means however many low-order bits of time the attacker
can't measure, they have to guess. Not enough.
> The pid is not very predictable; its unknown to remote users,
If you don't need crypto quality, then seed w/ pid^time. If you do,
then pid doesn't help. For init scripts it's pretty darned close to
constant; for normal users it's observable.
> The reason I like environ is because, at least on modern kernels,
> its read only by owner.
The reason I don't like it is that it's pretty darned near to
constant, and not particularly secret. Yes, /dev/$$/environ isn't
world-readable, but the environment is driven almost entirely from
If you want to try and cons up some hard-to-guess bits from a system
with little entropy, here's what I'd do.
First, toss some noise into the system by doing some network
interactions --- e.g., do DNS lookups on names from logfiles,
stretching over hours of logs; taking /dev/random at that point,
randomly pick some words from dict and try google searches. At
this point your network interaction has seeded /dev/random to an
interesting degree. Of course if your system is completely idle all
the time, the trick of reaching back into logs for hard-to-guess
names won't turn the trick. For a mostly-idle system with no ability
to preserve state across reboots and no high-entropy local devices,
I'd either look to hardware RNGs, or configure ipsec to a gizmo with
good entropy, or hunt harder for a way to store accumulated entropy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the hlfs-dev