We would like to encourage people who have written yarrow
implementations to participate in deriving test vectors.
By arriving at a standard set of test vectors, we can better assure
ourselves that implementations are consistent with the specification,
and iron out different interpretations of the spec, and discover
coding errors.
ZKS' open source yarrow implementation (BSD license) is at:
http://opensource.zeroknowledge.com
This isn't a final version as there are no test vectors yet, but we've
setup a mailing list for the purpose of deriving test vectors.
send mail with body "subscribe" to
[EMAIL PROTECTED]
those interested may like to participate in discovering differences
between yarrow implementations and fixing the ambiguities in the
yarrow spec.
Ideally you want random driver level support (like /dev/[u]random on
linux and some unixes) on as many OSes as possible.
The API the yarrow library should present to make porting easy is also
tricky as it has to work in the linux kernel, MAC driver levels,
perhaps windows or DOS device drivers etc, and the implementation
restrictions down there are kind of interesting.
But you can also use it as a user land library for OSes without device
level yarrow support as is sometimes the case in openSSL, or say
openSSH. The tricky part there is what to do about forking -- ideally
you want the rng context to be in shared memory, but the SSH may not
support cross platform shared memory. If you don't do that the two
forked processes tend to produce the same output, and even if you mix
in the process-id to prevent that, the entropy one process gathers is
not available to the other processes.
Adam
