Date: Sun, 27 Aug 2000 18:59:20 -0400 From: "Theodore Y. Ts'o" <tytso@MIT.EDU> To: Adam Back <adam@cypherspace.org> Cc: mark@grondar.za, current@FreeBSD.ORG, kris@FreeBSD.ORG, jeroen@vangelderen.org, yarrow@zeroknowledge.com Subject: Re: yarrow & /dev/random Message-ID: <200008272259.SAA02131@tsx-prime.MIT.EDU>
next in thread | raw e-mail | index | archive | help
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 freebsd.org 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 security. 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008272259.SAA02131>