From owner-freebsd-current Fri Aug 25 23:32:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp02.iafrica.com (smtp02.iafrica.com [196.7.0.140]) by hub.freebsd.org (Postfix) with ESMTP id 1D98237B422; Fri, 25 Aug 2000 23:32:00 -0700 (PDT) Received: from [196.7.18.138] (helo=grimreaper.grondar.za ident=root) by smtp02.iafrica.com with esmtp (Exim 1.92 #1) id 13SZVM-000FDv-00; Sat, 26 Aug 2000 08:31:49 +0200 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7Q6Wep24461; Sat, 26 Aug 2000 08:32:40 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008260632.e7Q6Wep24461@grimreaper.grondar.za> To: Adam Back Cc: current@freebsd.org, kris@freebsd.org, jeroen@vangelderen.org, mark@grondar.za Subject: Re: yarrow & /dev/random References: <200008260037.UAA27804@caesar.zks.net> In-Reply-To: <200008260037.UAA27804@caesar.zks.net> ; from Adam Back "Fri, 25 Aug 2000 20:37:06 -0400." Date: Sat, 26 Aug 2000 08:32:40 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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