[Cryptography] The Crypto Pi

[Ben Laurie]

On 18 January 2015 at 14:50, Ralf Senderek <crypto at senderek.ie> wrote:
> 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.

I'm pretty sure modern FreeBSDs do use it. Can't speak to the pi
particularly, though.

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

We did some experiments a while back which suggest that you can get
sufficient entropy during startup by measuring device attach times.
Probably worth repeating the experiment on the pi - and enabling this
(I am not sure whether FreeBSD does by default, I got tired of arguing
about it).

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

I'm not sure what "removing bits from the pool" really means -
extracting n bits from a pool does not, IMO, remove n bits, or even
any large fraction of n, from the pool.