> 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.
Look at the sysctls (some improvements and documentation coming).
> 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
I suspect you are missing the whole point of yarrow. Yarrow protects
you from the compromises inherent in attackers injecting their own
junk into the "third pool".
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message