anelok: entropy assist

Werner Almesberger werner at
Sat Oct 19 10:17:13 EDT 2013

As I've already mentioned, the random number generator is one of the
most critical elements in the password safe (or almost any system that
depends on cryptograpy).

We have one hardware RNG in the transceiver, which will be the main
source of entropy. The RNG produces two bits every microsecond, which
is a fairly high rate. What we can never be sure about is whether the
RNG may be biased (i.e., non-random) in some way.

A RNG can be biased due to a design flaw, due to tampering (think
NSA), or due to device malfunction. The latter means that even
extensive lab testing can't guarantee what the RNG will always
perform correctly in the field. This can be mitigated by running some
statistical tests each time the RNG is used, but such tests can only
detect relatively catastrophic failures, not subtle changes.

One way to reduce the effects of a bias is to collect random bits in
an entropy pool and extract a smaller number of bits from the pool
than have been entered. E.g., such a pool could be constructed by
running the MD5 hash algorithm on a sequence of more than 128 random
bits. The resulting hash would then have 128 bits of improved

Another way is to mix entropy from multiple sources.

Systems like Linux try to collect entropy for their random number
generator (e.g., /dev/random) from keyboard input, interrupt timing,
and such. Such events are not random but they still contain a small
amount of randomness that can be used. Unfortunately, Anelok will
have access to few useful sources of entropy that could be
"harvested" in such a way.

But maybe we can do better. Since memory cards tend to be huge
compared to the data we actually need to store, there's a lot of extra
space that wants to be put to good use.

Filling it with random numbers generated by a system that's good at
producing high-quality entropy would allow Anelok to mix them with the
bits it obtains from the hardware RNG.

Like pretty much all the information on the memory card, also this
random data would have to be encrypted and signed a) to prevent anyone
who steals the memory card (or just its content) from reconstructing
the random bits that were used by Anelok (their use can be long-lived)
and b) to make sure nobody can sneak in their own biased "random" data.

I think that, if done properly, such randomness files could even act
as the only source of randomness, e.g., if the transceiver fails or if
someone who considers RF capability a danger removes/disables it.

- Werner

More information about the discussion mailing list