> On Sat, 22 Jul 2000, Mark Murray wrote:
> > > So what it if I want/need 257 bits? :-)
> > 
> > Read them. You'll get them. If you want higher quality randomness than
> > Yarrow gives, read more than once. Do other stuff; play. Don't get stuck
> > in the "I have exhausted the randomness pool" loop; Yarrow does not play
> > that game.
> I think you're missing the point. The only way I can get a random number
> with more than n bits of entropy out of Yarrow-n is if I sample either
> side of a reseed operation, which in general comes down to timing
> guesswork and having to make assumptions about the PRNG implementation.

I understand that. :-)

Your are missing the point that it is not possible to get more than
the ${number-of-bits-ofrandomness} from any accumulator or PRNG. You
have to draw the line somewhere; The current implementation has it
at 256.

> If you want to generate a cryptographic key of length n bits then you
> really want >n bits of entropy in the random source you're deriving it
> from, otherwise your key is actually much weaker than advertised because
> it's easier for the attacker to attack the state of the PRNG that derived
> it than to attack the key itself.

Aha! That is where Yarrow wins. The paper argues it much better than
me: Section 4.1, the paragraph that begins "Yarrow takes a different

> > We currently have Yarrow-256(Blowfish); wanna make it Yarrow-1024? I could
> > make it so.
> Well, if we did that then how about generating 2048-bit keys? :-)

Where do you draw the line? I could make it Yarrow-N, only to have
someone insist on $((N+1)) in the very next breath.

With what we have, I am staking my career on the "uncrackability"
of Blowfish-256. If that holds then Yarrow is safe. (The old one
was MD5, with all its weaknesses such as birthday attacks, and
blocking added to compensate for folk raping it for internal state;
this blocking was compromised by the non-blocking /dev/urandom. The
design was too simple. The current design has multiple accumulators,
dual pools, and cryptographically overseen reseed mechanism; on top
of that, the output is encrypted in its own right, so there is added
protection against folk guessing the internal state.).

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