On Sat, 22 Jul 2000, Jeroen C. van Gelderen wrote:
> I agree that you need long RSA keys ... but the real
> discussion isn't really about key length but rather about
> the overall complexity of attacking the key:
Okay, using RSA keys wasn't the best example to pick, but Yarrow also
seems easy to misuse in other cases: for example if you want to generate
multiple 256-bit symmetric keys (or other random data) at the same time,
each additional key after the first won't contain any additional entropy,
so if you break the state of the PRNG at the time the first one was
generated you get the others for free (until the thing reseeds).
This design tradeoff is discussed in section 4.1 of the paper.
> That said, there is nothing to prevent the system admin
> from tweaking the Yarrow security parameters so that
> Yarrow will only spit out as many bits or pseudo-randomness
> as it gathers bits of entropy.
Well, I don't see a way to tune this without modifying the Yarrow design,
since the entropy pool is intentionally decoupled from the output
mechanism, and it seems like it would add additional (unnecessary)
overhead anyway to use it in that fashion.
Indications are we can probably get quite a lot of usable entropy from a
standard system (on the order of many kilobytes per second - but I need to
read more of the literature about processing of entropy samples) - in this
case I think maintaining a third pool which is directly tapped by
/dev/random, and leaving Yarrow sitting behind /dev/urandom is the way to
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message