Messages in this thread |  | | Date | Tue, 12 Sep 2000 09:56:12 +0000 | From | Pravir Chandra <> | Subject | Re: Using Yarrow in /dev/random |
| |
> I'm not a big fan of Yarrow, since it (in my opinion) places too much > faith in the crypto algorithms. It uses a pathetically small entropy > pool, and assumes that hash function will do the rest. Which is fine, > but that makes it a pseudo-RNG, or a crypto-RNG, and not really an > entropy collector. That's not necessarily a bad thing, but IMO that > should live outside the kernel. There's no real point putting something > like Yarrow in kernel space. Better that it collects entropy from a > true entropy collector that's in-kernel (like the current /dev/random), > and that it does the rest of the processing in user space. After all, > the main rason why /dev/random is in the kernel is precisely because > that's the most efficient place to collect as much entropy as possible.
i agree that the yarrow generator does place some faith on the crypto cipher and the accumulator uses a hash, but current /dev/random places faith on a crc and urandom uses a hash. i also agree that the entropy pools are small, but the nature of the hash preserves the amount of entropy that has been uses to create the state of the pools. basically, if the pool size is 160 bits (hash output) its state can be built by more than 160 bits of entropy, its just that adding entropy after that increases the unguessability (conventional attacks) of the state but brute forcing the state is still 2^160.
regardless of any of this, putting yarrow in user space is problematic from an entropy collection standpoint. yarrow accumulator needs multiple entropy sources in order to meet certain criteria in the algorithm for pool stirring and reseeding. reading the mux'd data from /dev/random is really too late for yarrow to discern where each bit of entropy comes from.
> If you look at the current 2.4 /dev/random code, you'll see that there > already are two entropy pools in use, which is designed to be able to do > something like the "catastrpohic reseed" features which Bruce Schneier > is so fond of. What's currently there isn't perfect, in that there's > still a bit too much leakage between the two pools, but I think that > approach is much better than the pure Yarrow approach.
i took a brief look at the new code. if i understand correctly, the general consensus is to have /dev/random be essentially a gateway for entropy and /dev/urandom to be a cryptographically strong prng. i think this fits with yarrow, in that the accumulator can provide entropy and the generator can provide strong prn's. our plan was to keep the accumulator and one generator in the kernel and to provide a library to create n generators in user space so as to help simulation.
pravir chandra. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |