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

Tweakable.

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

M
--
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