[Cryptography] The Crypto Pi

Ralf Senderek crypto at senderek.ie
Sun Jan 18 09:50:32 EST 2015

OnWed Jan 14 04:41:15 EST 2015 John Gilmore wrote:

> [quoting Bakul Shah]
> > On linux/pi the h/w RNG is available under /dev/hwrng.
> > /dev/random is their standard "cryptographic pseudo RNG".  It
> > seems to be extremely slow (80 bits/second) or broken or has
> > the wrong default settings.
> >
> > FreeBSD/pi /dev/random is much much faster @ 33Mibis/sec. AFAIK
> > it doesn't use the h/w RNG.
> The problem on Linux is probably that they failed to run rngd, the
> hardware randomness daemon.  (In Debian/Ubuntu it's in the "rng-tools"
> package.)
> The problem on FreeBSD is that /dev/random doesn't wait for entropy,
> it just makes pseudorandomness as fast as it can.

The Crypto Pi needs a random key with at least 128 bits of entropy
for every message (AES). The desirable hardware platform would be
the beagle bone and the OS OpenBSD to make auditing possible.

But there is a problem with the randomness source on the beagle bone.
I've monitored the state of the kernel's entropy pool via /proc and
found that if you read 10 Bytes from /dev/random the entropy level
drops by 52 bits. A short time later reading another 10 Bytes the beagle
blocks for 54 seconds. Reading 20 bytes for the first time removes
116 bit of entropy from the pool and the second read blocks for nearly
70 seconds. The beagle bone needs 143 seconds to recover and to add
a 100 bits of entropy back to the pool. There's no rngd running.

On the Raspberry Pi, reading 10 Bytes drains 180 to 240 bits from the
pool, and reading 100 Bytes drains 960 bits of entropy, but the RPI
recovers rather quickly (with or without the rngd running) at a speed
of 100 bits per second.

OpenBSD will only be available on the beagle bone, but the questionable
random source on the beagle might justify the choice of the RPI as the
hardware platform for the Crypto Pi.


More information about the cryptography mailing list