One technical reason could be that at least some of the entropy sources are
also in the kernel, so it makes some sense to put the RNG there, too. It'd
probably be more implementation effort to be able use the same entropy sources
in a userspace tool.
Another justification could be that it is more difficult to modify kernel
memory than it is to modify userspace memory, so it might be considered more
trustworthy.
On May 5, 2016 2:40:51 AM PDT, shawn wilson <ag4ve...@gmail.com> wrote:
>Just reflecting on the Linux RNG thread a bit ago, is there any
>technical
>reason to have RNG in kernel space? There are things like haveged which
>seem to work really well and putting or charging code in any kernel can
>be
>a bit of a battle (as it should be with code as complex as that
>involving
>crypto - wouldn't want people missing an exploit your new system
>exposes
>and accepting it*). So I wonder what the gain is for putting RNGs in
>the
>kernel.
>
>The only argument I can think of against this is non technical - if you
>rely on users to pick their RNG implementation, they are liable to get
>it
>wrong. This may be valid but I'm still curious about the technical
>reasons
>for RNG in kernel space.
>
>Also, if kernel space is really necessary, I'd think publishing as a
>dkms
>type package would gain more traction for getting into mainline (but
>this
>is probably OT here)
>
>* Obviously that same argument can be made of userspace programs but
>I'd
>much prefer my exploits happen at a less privileged ring whenever
>possible
>:)
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>cryptography mailing list
>cryptography@randombit.net
>http://lists.randombit.net/mailman/listinfo/cryptography
--
Michael Greene
Software Engineer
mgre...@securityinnovation.com
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
