I don't see any compelling advantage in replacing /dev/urandom's
output function with a more yarrow like one.
The Yarrow protocol brings two things:
- recovery from the state compromise attack Ted refers to.
- design that has been formally reasonsed about (many of the existing
CPRNG have been hacked together from dubious constructs including MD4,
and even non-cryptographic whiteners); they may be argued to be
secure, but I'd sooner not use speed-freak hacks -- CPRNGs are fragile
enough as they are. Just a plea for conservative design, and reuse of
crypto constructs with known (good) properties. The HMAC approach
applied to CPRNGs, instead of the encrypt a CRC64, because it's
faster.
Not to slag off /dev/[u]random which are pretty much deployed state of
the art CPRNG at this point, and a Good Thing.
So if you aren't adding the state compromise recovery property,
there's not much gained by using a different output function --
/dev/urandom's is good enough.
I think Kelsey et al are now looking at /dev/random issue for yarrow
(it doesn't play with /dev/[u]random because it's tricky having
CPRNG's with different design philosophys sharing physical entropy
sources.) John may like to comment.
You might want to hold off for the conclusion to this. A few people
have ansi C yarrow source kicking around you might like to re-use as
well.
Adam
