> 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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:18 EST