From owner-freebsd-current Fri Aug 25 17:43:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from r00t.besiex.org (r00t.besiex.org [208.222.215.145]) by hub.freebsd.org (Postfix) with ESMTP id D6F9437B42C; Fri, 25 Aug 2000 17:43:09 -0700 (PDT) Received: (from adam@localhost) by r00t.besiex.org (8.8.7/8.8.7) id UAA21527; Fri, 25 Aug 2000 20:43:04 -0400 Date: Fri, 25 Aug 2000 20:43:04 -0400 Message-Id: <200008260043.UAA21527@r00t.besiex.org> From: Adam Back To: current@freebsd.org Cc: kris@freebsd.org Cc: jeroen@vangelderen.org Cc: mark@grondar.za Subject: yarrow & /dev/random Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [try again this foobared the first time -- apologies for duplicates] [If this bounces because I am not a list member, could I trouble one of you to forward it to the list? -- Thanks] Hi all 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: Kris Kennaway > [...] > > I'm not bothered about this. My point is that, by design, Yarrow is not > suitable as a replacement for /dev/random (/dev/urandom, yes). and Jeroen van Gelderen : > [...] At a more fundamental level we will need to answer the > question: "Do we need to preserve the current /dev/random semantics > or can we decide to change 'em? [1]". And how will this affect our > applications *in practice*. > > So let's concentrate this discussion on the practical issues > and explain why you think backing /dev/random with Yarrow and > changing the semantics is justifyable or even a good thing. and several others I saw. 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). 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). Peter Gutmann is subscribed (I see 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. 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 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 - yarrow design specifically calls for a hash function and a block cipher -- you may easily be violating some of it's security assumptions by plugging in the above. - blowfish has an expensive key-schedule, so depending on your Pg value it might be faster to use 3DES as specified by yarrow-160. - 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 - making testing difficult. Adam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message