Re: [amsat-bb] Lava Lamp

[Phil Karn <karn@xxxxxxxxxxxxxxx>]

>If you do (say) od -x /dev/random  it will block on the device
>for a while if you do it too quickly.  It appears to me that
>some type of "entropy threshold" or maybe some fixed time or
>a combination of the two is being enforced in the version that
>is delivered with RH 7.2.

That's exactly right. Estimating how much entropy is in the pool is
the toughest problem in the implementation of this scheme. Desktop
machines with keyboards get lots of entropy from keystroke timings and
the like, but headless servers can be a problem.  There you have to
rely on the timing of disk drive interrupts, as you can't use any
externally visible events like packet arrivals, etc.

The linux /dev/random driver lets you explicitly add entropy to the
pool by simply writing it to the pseudo-device. That makes it easy to
save random state across reboots, or to seed it with noisy bits from a
sound card microphone preamp.

To bring this back to spacecraft security, I suspect that there is
enough external entropy in the A/D inputs to an IHU for this scheme to
(slowly) generate enough cryptographic quality random bits to supply a
key agreement protocol.  While receiver AGC levels, battery currents,
array currents, temperatures, etc, are hardly random numbers, there is
probably enough unpredictability in their least-significant bits to be
useful sources of entropy.

Obviously the A/D values used in the algorithm couldn't be sent in
telemetry, so you'd have to drop them from telemetry while the
algorithm is operating.

Phil




----
Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org