Subject: Re: CVS commit: syssrc/sys/dev/ic
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Perry E. Metzger <>
List: tech-kern
Date: 11/08/2001 16:18:35
Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:
> In message <>,
> "Perry E. Metzger" writes:
> >I've always been uncomfortable with using the network controllers for
> >entropy and I've said so a lot.
> But is your discomfort warranted? I dont think it is--

Which of us has dealt with the world of crypto more?

Cryptographic systems are by their nature extremely fragile. Even a
small statistical wedge is often sufficient to tug a large rope
through. The usual hacker "f**k you I want to do it this way"
stubbornness is very dangerous.

It is frequently the case that new attacks are developed based on
truly minimal information. Take Paul Kocher's timing and power
utilization attacks. BTW, both of those are seemingly impractical
except they both work.

> Interrupt latency on the receiving NetBSD box isn't reproducible to
> better than microsecond resolution.

How do you really know? And if it is true, are you sure the
information isn't enough to permit statistical reduction in the search
space sufficient to drive a wedge in? Are you sure no one will ever
foolishly use the RNG in such a way as to make an adaptive attack

People building these systems can't say "this is good enough". You
have to be highly conservative. You have to look at a system and say
"I don't know how to attack the system using X but by removing X I
eliminate a whole class of potential attacks so I'll do it." People
often throw in monkey wrenches even if they have no evidence they are
absolutely needed -- and it turns out later they were absolutely
needed. Folks who go with "good enough" sorts of designs end up with

> It might be fair to say that its not safe on NetBSD ports which lack a
> good high-resolution timer source.

Actually, it is potentially unsafe in different ways both on high and
low resolution timer based systems. You can't know that it is
safe. Get rid of it.

Perry E. Metzger
NetBSD Development, Support & CDs.