svn commit: r239569 - head/etc/rc.d

[Mark Murray]

Ben Laurie writes:
> > I can certainly trigger a reseed at will, but allowing external writes
> > to overwhelm the system by doing a
> >
> > $ cat /dev/zero > /dev/random
> >
> > ... just ain't gonna happen. No, sir.
> 
> Let's just quantify the risk here: essentially the problem is that if
> I feed something with no entropy into the pool and that is allowed
> to trigger a reseed, then you end up hashing what existing entropy
> you have with the no-entropy input, leading to a loss of entropy. The
> theoretical loss for a perfect hash function is log_2(N)log_2(1/e),
> where N is the number of iterations. log_2(1/e) is ~.66. So, to reduce
> the entropy from, say, 256 bits, if SHA-1 is used, to 128 bits, takes
> ~2^(128/.66) reseeds - that is, ~2^193. Around 10^58. So, you're
> right, it ain't gonna happen, even if you allow an attacker to reseed
> as often as he wants :-)

Fine, but that is not what I'm talking about, _AT_ALL_.

Reseeds are expensive in kernel space; locking/unlocking and thread
consumption are the issue. Right now, this is mitigated by reseeding at
10Hz. To allow reseeds to overwhelm the running kernel by pumping data
into /dev/random is would be very silly indeed, and I'm not going to let
that happen.

> I do want to see the method :-)

This is what I have so far; written, but neither tested nor
finalised. Its not the complete picture; there are minor changes
elsewhere.

The intention is to reduce the number of calls to
random_harvest_internal(). All entropy supplied by this method
is assumed to be junk/hostile; anything that is supplied that
is not so is a free gift. The TSC register is incorporated in
random_harvest_internal(), so extras are added in to help out.

random_yarrow_write(void *buf, int count)
{
        /* This static buffer is uninitialised; this is deliberate. */
        static uint8_t chunk[HARVESTSIZE];
        static int chunk_pos = 0;
        union {
                uint64_t u64;
                uint8_t u8[sizeof(uint64_t)];
        } fastcounter;
        int i;
        uint8_t *inbuf;

        /*
         * Accumulate the input into a HARVESTSIZE chunk. The writer has too
         * much control here, so "estimate" the entropy as zero.
         */
        if (buf != NULL) {
                inbuf = buf;
                for (i = 0; i < count; i++) {
                        chunk[chunk_pos] ^= inbuf[i];
                        chunk_pos = (chunk_pos + 1)%HARVESTSIZE;
                }
                fastcounter.u64 = get_cyclecount();
                for (i = 0; i < sizeof(uint64_t); i++) {
                        chunk[chunk_pos] ^= fastcounter.u8[i];
                        chunk_pos = (chunk_pos + 1)%HARVESTSIZE;
                }
        }
        else
                random_harvest_internal(get_cyclecount(), chunk, HARVESTSIZE,
                    0, 0, RANDOM_WRITE);
}

> My point here is that you don't have full control of the inputs
> to /dev/random, so assuming that they take some particular form
> seems like a mistake to me - the aim, I would hope, would be to
> extract available entropy from whatever inputs you get, regardless of
> quality.  So, the argument against xor is that it is possible for a
> careless/naive person to shoot themselves in the foot, and it would
> be nice to avoid that - it seems unkind to assume that everyone who
> wants to help the PRNG is going to be knowledgeable about its inner
> workings.

This conversation is being reset back 12+ years. *SIGH*. I get the
distinct impression that I'm starting again from scratch here, and I'm
not sure that I have either the energy or inclination to do that.

Are you aware of Yarrow's approach to poor entropy while harvesting?

M
--
Mark R V Murray
Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open)
Pi: 132511160