Adam writes:
>Yes.  But the /dev/random device is traditionally crw-r--r-- which
>means user processes can't write to it.  So you'd have to be root to
>do that.
>What could be done for yarrow is to change the device permissions to
>crw-rw-rw- and mix into a shared user source and set k_of_n_thresh so
>that the user can only trigger fast reseeds, and consider slow reseed
>de-skewing function output for blocking /dev/random; or just add user
>input with an entropy estimate of 0 so they can't affect reseeding,
>and draw fast reseed de-skewing function output for block /dev/random
>(slow output may be too slow).

I'm not on the lists, so I've missed some of the discussion
on this threads; I was pointed to the web archives by Adam.

A couple of comments here.  It was always the intention that /dev/random
be 0666, and in my implementation, writing to /dev/random mixed the input
into the entropy pool *without* changing the entropy estimate.  The
mixing algorithm was carefully chosen so that even if an attacker mixed
all zero's, or some other carefully chosen input, he/she would gain no
more information about the pool than he/she already had (which hopefully
is non, of course.  :-)

I used an ioctl which atomically adds data into the entropy pool *and*
updates the entropy count.  I did this because (a) the (trusted,
privileged) user-mode random collection daemon has the best idea of how
much entropy the input data has, and (b) if someone is actively drawing
on the entropy pool, you want to update the entropy count at exactly the
same time as you add the entropy to the entropy pool.

As far as yarrow versus the current design, I've certainly looked at
yarrow, and I've certainly considered adding some of yarrow's design
into my /dev/random implementation.  Given that I strongly recommend
that the 512 bytes of entropy be saved from /dev/random at shutdown
time, and then written to /dev/random at startup time (without updating
the entropy estimate), I question how realistic the attack scenario that
Yarrow tries so hard to defend against.  The other problem I have
against the Yarrow design is that it depends on the strength of the
crypto primitives a bit more than I feel comfortable doing.  In my
/dev/random design, which draws heavily from the philosophy of PGP's
RNG, we use a crypto primitive for whitening, but as long as there is a
sufficient amount of system entropy getting poured into the pool, the
crypto primitive could be replaced with a CRC function (or even an
additive checksum!) without really doing a lot of damage to system

I also feel very strongly that something like 3DES/AES counter mode is
something which a crypto application which needs a lot of session keys
should be implemented in user-mode ---- in a library, probably.  There's
no real reason why that needs to be implemented in the kernel ---
/dev/random needs to be there because it's doing all of the sampling of
the system environment, and the entropy pool needs to be stored securely
and easily updated by the entropy collection routines.  

So it may be that the best way to handle things is to implement the
upper level of a yarrow-like design in a usermode library, and which
does its "catastrophic reseeding" by reading from /dev/random as
necessary.  Certainly that is my bias at this point.

                                                - Ted

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to