lkml.org 
[lkml]   [2002]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] (0/4) Entropy accounting fixes
From
Date
On Sun, 2002-08-18 at 03:31, Bernd Eckenfels wrote:

> A question: what is the denger of the network entropy? is it, that one is a
> fraid that snooping could gather knowledge about random source, or is it
> more along the line that one fears that specially deviced packages can feed
> manufactured, and therefore not randmom bits?

The later. Some believe someone on your local network, who understands
the timing of the physical layers and devices, can influence the entropy
pool. Further, then, we assume SHA is cracked. Then they know enough
state and can presumably determine the output of [u]random.

Of course, this is all theoretical but I would not gamble in certain
situations either. In some, like my workstation on my network, I feel
safe and enjoy having sshd not block waiting for entropy. So I wrote
the netdev-random stuff...

Note the patches work in the converse manner, too: _today_ there are
network drivers that contribute entropy. With netdev-random you can
stop that if you wish.

> In the first case, how big would be the hardware proccessing variance for an
> interrupt be? Is it realy predictable from sniffing the network how that
> will result in interrupts?

Possibly.

> How can softinterrupts help here?

Under load the execution of softinterrupts is virtually
non-deterministic, so they do help but we do the timing off the
interrupt handler itself.

Robert Love

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.088 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site