svn commit: r274739 - head/sys/mips/conf

Mark R V Murray mark at grondar.org
Fri Nov 21 19:37:27 UTC 2014


> On 21 Nov 2014, at 18:57, Ian Lepore <ian at FreeBSD.org> wrote:
> 
> All I've ever asked for, since day one of discussing this topic, is a
> knob to prevent /dev/random from blocking, ever.  A way in which an
> administrativive policy decision can be made about what consitutes "good
> enough" entropy (and by extension, security).  The knob could be of the
> nature that it's hard to turn on accidentally -- it's a dangerous thing
> and like an industrial stamping press maybe you have to hold down two
> buttons far apart from each other to make it go.

I’m suspicious of motive here. You are planning on ignoring lousy
entropy coming out of /dev/random; you seem to need a way of breaking
to do so. (I can’t think of a better word than “ignoring”; what I mean
is that you don’t seem to care how bad the output is.)

If you don’t care about the contents of /dev/random, why not simply
ignore it? Choosing to use tools that require good-quality /dev/random
output means you should choose other tools, not break /dev/random!

> As far as I know we have that now, but it sounds like not forever.  I'm
> just arguing in favor of providing the tools, making it reasonably hard
> to accidentally cut yourself on them, but ultimately leaving the policy
> decisions of how to use them to the people who own and run the systems.
> I kind of thought that was the unix way.

The Snowden revelations have made folks considerably more paranoid.

Providing tools that bad guys could potentially use where the good guys
have alternatives is not a way that security-minded folks are keen to
go.

You have the right to ignore /dev/random. Asking for a back door to
break it is a bigger deal. Bad guys like these back doors.

M
-- 
Mark R V Murray



More information about the freebsd-arch mailing list