> 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.[4]
> 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
> go.

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".

Mark Murray
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

Reply via email to