> > > This design tradeoff is discussed in section 4.1 of the paper.
> >
> > Tweakable.
>
> Doing a reseed operation with every output is going to be *very*
> computationally expensive.
Tradeoff. What do you want? Lightning fast? Excessive security? Balance
it out.
> > > 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).
>
> Please tell me which of the following sysctls will cause Yarrow to
> deactivate the keyed cipher feature that spits out a constant data
> stream independent of the state of the entropy pools:
>
> kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10
> kern.random.yarrow.fastthresh: 100 kern.random.yarrow.slowthresh: 160
> kern.random.yarrow.slowoverthresh: 2
None, but very paranoid reseed intervals can be set if
required. (Requires more entropy-harvesting, but doable).
> > 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, I understand this stuff quite well - I'm not "missing the whole
> point of Yarrow" at all.
The acknowlegment that I am looking for is that the old, simple "gather
entropy, stir with hash, serve" model is inadequate IMO, and I have not
seen any alternatives.
> Yarrow is a good system as far as it goes,
> but the authors themselves admit this limitation - you just can't use
> this tool in contexts it was not designed for.
Goes for any tool; a universal truth. I'm trying to come up with a
better tool that what was, and I believe that I have, and I am perhaps
misunderstanding folks' motives in shouting for the blocking model. In
quite a few cases, it has been a very obvious non-understanding of what
Yarrow is (I apologise for lumping you in this category).
I'll relent somewhat if a secure entropy distilling algorithm could be
found; one which stands up to crypanalysis.
Will you relent a step or two if I can get the entropy harvesting _rate_
high enough? :-)
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
