> We've been implementing yarrow at zeroknowledge also.  I just read
> through the freebsed-current archives searching for "yarrow", and I
> share some of the concerns raised by Kris Kennaway:


> I've been talking with John Kelsey (one of the Yarrow authors) about
> changing yarrow to support /dev/random for the very same reason (I had
> not read this discussion -- but the same objection independently
> occured to me in connection with linux which has the same Ted T'so
> /dev/random code).


> John Kelsey has also been working on a Yarrow-160-A which simplifies
> some of the design.  I'm hoping to persuade the yarrow designers of
> the importance of supporting /dev/random semantics for the unix
> community acceptance.  John Kelsey and I had some discussions along
> the lines of feeding /dev/random output into yarrow, which I notice
> someone on here considered.  (Sorry I forgot who said that).

By "/dev/random semantics", are you referring to a blocking model
that "counts" entropy and blocks when it beieves it is "empty"?

> Perhaps I could encourage some of you to subscribe to the yarrow list
> we have setup at [EMAIL PROTECTED] (send mail to

Thanks! Doing it now!

> some references to his paper), and I expect some of the yarrow authors
> will when they get back from Crypto.  It might help the cause of
> preserving /dev/random semantics, if those of you participating in
> this discussion back in July chipped in to support my similar
> predictions about community acceptance on this basis -- OS
> implementors are after all the target audience for yarrow.

I am against the blocking model, as I believe that it goes against
what Yarrow is trying to do. If the Yarrow authors argued otherwise,
I'd listen.

> There are several implementors on board -- RST have an implementation
> tracking the changes in yarrow-160-A they plan to release soon, we
> have the 160 implementation I wrote (current tar ball at:
> http://opensource.zeroknowledge.com).


> I must say I think it is important with cryptographic primitives to
> have test vectors, so that you know your implementation is correct and
> conforms to the specification.  It's very difficult to notice errors
> in a PRNG -- the output still looks random.  So the aim of the yarrow
> list is to collectively work on deriving test vectors.

I'd be _most_ interested in this.

> I had a quick look at Mark's yarrow implementation and there are a
> things which I'd caution about:
> - the hash function constructed from using Blowfish in CBC mode you --
>   have to be careful how you use block ciphers to construct hash
>   functions -- they have quite different properties.  For example
>   collision resistance is not generally important for a block cipher,
>   but is all-important for a hash function

Gotcha. I aim to improve my hash function. I've broken it out into
a separate function already.

> - yarrow design specifically calls for a hash functoin and a block
>   cipher -- you may easily be violating some of it's security
>   assumptions by plugging in the above.

If I construct a specific hash function, is this still a problem?

> - blowfish has an expensive key-schedule, so depending on your Pg
>   value it might be faster to use 3DES as specified by yarrow-160.

Hmm. I may just do this once I get onto the performance-tweaking
part of the project.

> - a minor coding question: it doens't look to me like the IV is
>   initialised -- is there something assuring that the ivec local
>   variable will hold zeros -- otherwise your RNG may have non
>   repeatable output -- which is OK in use but not for testing.

I'll fix that.

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