[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 <[EMAIL PROTECTED]>
> [...]
>
> 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 <[EMAIL PROTECTED]>:
> [...] 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 [EMAIL PROTECTED] (send mail to
[EMAIL PROTECTED]). 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
