[cryptography] Kernel space vs userspace RNG

Michael Greene mgreene at securityinnovation.com
Thu May 5 06:27:38 EDT 2016


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.us at 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 at randombit.net
>http://lists.randombit.net/mailman/listinfo/cryptography

-- 
Michael Greene
Software Engineer 
mgreene at securityinnovation.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20160505/97a3bef0/attachment-0001.html>


More information about the cryptography mailing list