> 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:
OK...
> 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).
Great!
> 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
> [EMAIL PROTECTED]).
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).
Great!
> 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.
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
