Integrated crypto

Bennett Todd 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 
> predictable.

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
world-readable files.

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
over reboots.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20040401/bf1357c8/attachment.sig>


More information about the hlfs-dev mailing list