Date: Sat, 26 Aug 2000 08:32:40 +0200 From: Mark Murray <mark@grondar.za> To: Adam Back <adamb@zeroknowledge.com> Cc: current@freebsd.org, kris@freebsd.org, jeroen@vangelderen.org, mark@grondar.za Subject: Re: yarrow & /dev/random Message-ID: <200008260632.e7Q6Wep24461@grimreaper.grondar.za> In-Reply-To: <200008260037.UAA27804@caesar.zks.net> ; from Adam Back <adamb@zeroknowledge.com> "Fri, 25 Aug 2000 20:37:06 -0400." References: <200008260037.UAA27804@caesar.zks.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 yarrow@zeroknowledge.com (send mail to > yarrow-request@zeroknowldege.com). 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008260632.e7Q6Wep24461>