> This is basically the model I am advocating for /dev/random. It's also the
> alternative "basic design philosophy" described in the yarrow paper.
Erm, read 4.1 again :-). The paragraph that begins "One approach..." is
the old approach. It is also the approach that you are advocating.
The next paragraph "Yarrow takes..." is Yarrow, and the current
implementation.
> See "important issue" number 2 on p6. Yarrow-derived numbers are only
> "good for" 256 bits of strength. Modulo reseeds, Yarrow never accumulates
> more than 256 bits of entropy. Therefore you are silly to use it for
> applications which require more than 256 bits of randomness.
>
> > 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.
>
> Precisely, which is why /dev/random shouldn't use Yarrow, or any other
> seeded-cipher PRNG.
It should not use the old method, which is attackable for many
reasons that Schneier makes clear. (Effectively a 128 bit hash with
a reseed ("stir") every read. Can you spell "Iterative attack"? :-) ).
Where does that leave us?
How good were our old numbers? How many users have I screwed by implementing
that system?
How do we fix it? What accumulation algorithm do we use that does not
clue the reader into what the internal state is?
> > 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
>
> I'm not bothered about this. My point is that, by design, Yarrow is not
> suitable as a replacement for /dev/random (/dev/urandom, yes).
_My_ point is that the old system is broken, and that IMO Yarrow is a
good replacement. (I support my point by noting that Schneier is a far
better cryptographer than I, and he designed the algorithm that I
implemented).
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
