Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Andi Kleen]

Richard Gooch <rgooch@ras.ucalgary.ca> writes:

> Theodore Tso writes:
> > On Mon, Aug 20, 2001 at 04:25:26PM +0200, Martin Dalecki wrote:
> > > 
> > > The primary reson of invention of /dev/random was the need
> > > for a bit of salt to the initial packet sequence number inside
> > > the networking code in linux. And for this purspose the
> > > whole /dev/*random stuff is INDEED a gratitious overdesign.
> > > For anything else crypto related it just doesn't cut the corner.
> > 
> > A number of other people helped me with the design and development of
> > the /dev/random driver, including one of the primary authors of the
> > random number generation routines in PGP 2.x and 5.0.  Most folks feel
> > that it does a good job.
> 
> Indeed. If Martin has some deep insight as to why the /dev/random
> implementation is insufficient for strong crypto, I'd like to hear
> it.

The only flaw I see in the random device is that its enviromental constraints
are not sufficiently documented.

It is rather unreliable on boxes with no hard disk IO or 
non supported hard disk IO (i.e. until recently a lot of RAID controllers
didn't feed entropy) and no keyboard/mouse -- that is on a lot of appliances
and servers. The box has some random pool still left over from installation,
which gets smaller and smaller over runtime until urandom quickly degenerates
to a not-so-great-and-slow pseudo random generator and /dev/random turns into 
a DoS.

It is not that they are hard to fix; e.g. a $10 sound card
with a noise generating circuit on input and a small daemon to feed
/dev/audio to /dev/random can do it; but few people seem to know about
these problems and still trust the session key generation of their sshd 
(which uses /dev/urandom BTW I guess because of these problems) on their 
headless servers. The both SSL libraries I checked (mozilla and openssl)
do not even seem to use it at all.

-Andi

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Paul Jakma]

On 21 Aug 2001, Andi Kleen wrote:

> It is not that they are hard to fix; e.g. a $10 sound card
> with a noise generating circuit on input and a small daemon to feed
> /dev/audio to /dev/random can do it; but few people seem to know about

does this update the entropy count though? from previous 
discussions, i believe not, which iiuc means /dev/random will block 
just as frequently/infrequently irrespective of whether you feed 
stuff into /dev/random.

related: the i810 RNG has a driver, but it feeds data to /dev/random 
via a userspace daemon (rngd), so again entropy count is not changed.

kind of shame on the only mass-market RNG hardware out there.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Many people are unenthusiastic about their work.

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Andi Kleen]

On Tue, Aug 21, 2001 at 04:02:47AM +0100, Paul Jakma wrote:
> On 21 Aug 2001, Andi Kleen wrote:
> 
> > It is not that they are hard to fix; e.g. a $10 sound card
> > with a noise generating circuit on input and a small daemon to feed
> > /dev/audio to /dev/random can do it; but few people seem to know about
> 
> does this update the entropy count though? from previous 
> discussions, i believe not, which iiuc means /dev/random will block 
> just as frequently/infrequently irrespective of whether you feed 
> stuff into /dev/random.

Just writing into /dev/random feeds it, but only credits a very small
amount of entropy into the store, so you need to feed a lot of data.
To feed it with full accounting you need to use a special ioctl on /dev/random;
e.g. using the rndfeed tool (see ftp.firstfloor.org:/pub/ak/smallsrc/rndfeed.c)

-Andi

RE: [PATCH] let Net Devices feed Entropy, updated (1/2)

[David Schwartz]

> related: the i810 RNG has a driver, but it feeds data to /dev/random
> via a userspace daemon (rngd), so again entropy count is not changed.
>
> kind of shame on the only mass-market RNG hardware out there.

	Just tweak the daemon to update the entropy count correctly using the
appropriate ioctl function (RND_ADD_ENTROPY). Search drivers/chars/random.c
for random_ioctl. I've written several programs that acquire entropy from
various sources and exchange them with the kernel entropy pool. It's not
difficult at all.

	DS

RE: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Paul Jakma]

On Mon, 20 Aug 2001, David Schwartz wrote:

> appropriate ioctl function (RND_ADD_ENTROPY). Search drivers/chars/random.c

shame on me.

it appears the i810 RNG daemon does update the entropy count.

--paulj

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[David Wagner]

Andi Kleen  wrote:
>It is not that they are hard to fix; e.g. a $10 sound card
>with a noise generating circuit on input and a small daemon to feed
>/dev/audio to /dev/random can do it; [...]

This is a good idea, but do note that you have to be a little careful:
there are lots of ways that the result can look random enough to fool
/dev/random's entropy count but be non-random enough to provide much
less entropy than you'd otherwise expect (e.g., 60Hz effects, etc.).

I think it's a workable approach, and I warmly recommend using a broad
diversity of entropy sources (including, e.g., soundcards), but you just
have to be careful to avoid some of the pitfalls.

Re: [PATCH] Optionally let Net Devices feed Entropy

[Francois Romieu]

Robert Love <rml@tech9.net> :
[...]
> What is experimental about it?

The implicit-and-should-be-debated-in-2.5 assumption that the entropy 
estimate still makes sense ?

-- 
Ueimor

Re: [PATCH] Optionally let Net Devices feed Entropy

[Alex Bligh - linux-kernel]

>> What is experimental about it?
>
> The implicit-and-should-be-debated-in-2.5 assumption that the entropy
> estimate still makes sense ?

As opposed to the huge amount of sense it currently makes to
collect it depending on your NIC manufacturer, as opposed to
dependent upon a config option?

If you mean that the option should be labelled 'not for
the paranoid' I agree. The patch does that. 'Experimental'
means the code may crash, or perform other than as advertized.

--
Alex Bligh

Re: [PATCH] Optionally let Net Devices feed Entropy

[D. Stimits]

Alex Bligh - linux-kernel wrote:
> 
> >> What is experimental about it?
> >
> > The implicit-and-should-be-debated-in-2.5 assumption that the entropy
> > estimate still makes sense ?
> 
> As opposed to the huge amount of sense it currently makes to
> collect it depending on your NIC manufacturer, as opposed to
> dependent upon a config option?
> 
> If you mean that the option should be labelled 'not for
> the paranoid' I agree. The patch does that. 'Experimental'
> means the code may crash, or perform other than as advertized.
> 
> --
> Alex Bligh
> -
> 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/

It would be interesting if an option were possible for entropy pool via
loopback traffic.

D. Stimits, stimits@idcomm.com

Re: [PATCH] Optionally let Net Devices feed Entropy

[Robert Love]

On 16 Aug 2001 14:19:57 -0600, D. Stimits wrote:
> It would be interesting if an option were possible for entropy pool via
> loopback traffic.

is that humor? :)

it can certainly generate a large amount of entropy if you let it.

but the general mechanism for grabbing entropy from char/net devices is
measuring values from their interrupt timings.  this is done via a flag
value in request_irq.

loopback has no interrupts thus no request_irq

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: [PATCH] Optionally let Net Devices feed Entropy

[D. Stimits]

Robert Love wrote:
> 
> On 16 Aug 2001 14:19:57 -0600, D. Stimits wrote:
> > It would be interesting if an option were possible for entropy pool via
> > loopback traffic.
> 
> is that humor? :)

To a large degree, yes (but now that I think about it, not
entirely...speculation is dangerous to one's sanity).

> 
> it can certainly generate a large amount of entropy if you let it.
> 
> but the general mechanism for grabbing entropy from char/net devices is
> measuring values from their interrupt timings.  this is done via a flag
> value in request_irq.
> 
> loopback has no interrupts thus no request_irq

After hearing about all of the possible ways of sniffing keyboards, I
have to wonder how hard it would be to create an irq sniffing device to
aid monitoring (like the keyboard device, planted directly in the
computer being monitored, though I suppose once you have the keystrokes
it is a moot point). Then there are also all those wireless mice and
keyboards, which could possibly broadcast useful information about irq
(although knowing the exact time between irq's can only be estimated
without actually tapping straight into the motherboard hardware); there
is no reason to stop at simply monitoring keystrokes (would remote
monitoring of wireless devices offer *useful* info on irq timings?).

I noticed add_timer_randomness depends on time between events, and that
it isn't necessarily irq that matters; but irq is most likely the least
predictable event to use, and nobody has bothered to implement any other
random timing source to feed the function. Something else might be used
as a substitute, e.g., perhaps the temperature monitor on a cpu could be
used to modify a moving snapshot of loopback traffic. I don't know if
the raw data from cpu temperature monitoring is available with
sufficient precision (without regard to the accuracy of the value) to
count on it as a source of "environment noise" that in turn, during
change, can be used to trigger the equivalent of random timing. Some of
the hardware crypto devices seem to use diode noise (which can make a
nice microwave generator as well), perhaps temperature monitoring could
be used for a lower quality version; instead of simply passing the
timing of rising and falling peaks/valleys (since it wouldn't be as
rapid or random as a diode noise generator), one could use that timing
in conjunction with a hash on a sliding window of loopback traffic bytes
(or even to act as a coefficient, and not just a timing trigger).

The general weakness with irq seems to be that (a) it isn't always
occurring at a sufficient rate in systems without mouse/keyboard (and
worse on diskless sytems), and (b) there is some very minor possibility
that outside monitoring or influence can sway the pool or provide help
to crackers (the tech to do this usefully doesn't seem to exist right
now, but I wouldn't bet on it staying that way). Loopback is probably
one of the largest sources of byte traffic, is not subject to irq
monitoring, and does not fall down on the job for
mouseless/keyboardless/headless/diskless stations. What it lacks is a
truly random way of using the traffic; supposing something like
temperature monitoring could be found as an alternate timing device (in
place of irq), loopback could be used (or if any event that occurs in
relation to loopback is random in the way that irq is, some other
alternate timing event could be used). Does anyone happen to know
exactly how much "noise" could be extracted from hardware temperature
monitors (would it be practical)?

D. Stimits, stimits@idcomm.com

> 
> --
> Robert M. Love
> rml at ufl.edu
> rml at tech9.net

Re: [PATCH] Optionally let Net Devices feed Entropy

[Robert Love]

On 17 Aug 2001 16:56:03 -0600, D. Stimits wrote:
> Robert Love wrote:
> > 
> > On 16 Aug 2001 14:19:57 -0600, D. Stimits wrote:
> > > It would be interesting if an option were possible for entropy pool via
> > > loopback traffic.
> > 
> > is that humor? :)
> 
> To a large degree, yes (but now that I think about it, not
> entirely...speculation is dangerous to one's sanity).
> 
> > 
> > it can certainly generate a large amount of entropy if you let it.
> > 
> > but the general mechanism for grabbing entropy from char/net devices is
> > measuring values from their interrupt timings.  this is done via a flag
> > value in request_irq.
> > 
> > loopback has no interrupts thus no request_irq
> 
> After hearing about all of the possible ways of sniffing keyboards, I
> have to wonder how hard it would be to create an irq sniffing device to
> aid monitoring (like the keyboard device, planted directly in the
> computer being monitored, though I suppose once you have the keystrokes
> it is a moot point). Then there are also all those wireless mice and
> keyboards, which could possibly broadcast useful information about irq
> (although knowing the exact time between irq's can only be estimated
> without actually tapping straight into the motherboard hardware); there
> is no reason to stop at simply monitoring keystrokes (would remote
> monitoring of wireless devices offer *useful* info on irq timings?).

i would _think_ its just too unrelated.  even if we can understand the
wireless transmission, the correlation between what is sent and how the
IRQs are triggered is probably pretty vague.

then you have the whole issue of skew between times, etc.

> I noticed add_timer_randomness depends on time between events, and that
> it isn't necessarily irq that matters; but irq is most likely the least
> predictable event to use, and nobody has bothered to implement any other
> random timing source to feed the function.

yep, entropy is gathered as the difference (delta value) between
different registered events.  so far, irqs are used.  i think the way
the block devices work is seperate, too. they dont work off irqs per se
(but if a block device has hardware behind it, its irqs can add entropy
on top of the block device functions).

> Something else might be used
> as a substitute, e.g., perhaps the temperature monitor on a cpu could be
> used to modify a moving snapshot of loopback traffic. I don't know if
> the raw data from cpu temperature monitoring is available with
> sufficient precision (without regard to the accuracy of the value) to
> count on it as a source of "environment noise" that in turn, during
> change, can be used to trigger the equivalent of random timing. Some of
> the hardware crypto devices seem to use diode noise (which can make a
> nice microwave generator as well), perhaps temperature monitoring could
> be used for a lower quality version; instead of simply passing the
> timing of rising and falling peaks/valleys (since it wouldn't be as
> rapid or random as a diode noise generator), one could use that timing
> in conjunction with a hash on a sliding window of loopback traffic bytes
> (or even to act as a coefficient, and not just a timing trigger).

CPU temp is not a bad idea.  the RNG built into the i810/i815/i820
chipsets is like your diode example -- a chip measures some sort of
flucuations over the PCI bus.  quantum physics says that is truly
unpredictable :)

> The general weakness with irq seems to be that (a) it isn't always
> occurring at a sufficient rate in systems without mouse/keyboard (and
> worse on diskless sytems), and (b) there is some very minor possibility
> that outside monitoring or influence can sway the pool or provide help
> to crackers (the tech to do this usefully doesn't seem to exist right
> now, but I wouldn't bet on it staying that way). Loopback is probably
> one of the largest sources of byte traffic, is not subject to irq
> monitoring, and does not fall down on the job for
> mouseless/keyboardless/headless/diskless stations. What it lacks is a
> truly random way of using the traffic; supposing something like
> temperature monitoring could be found as an alternate timing device (in
> place of irq), loopback could be used (or if any event that occurs in
> relation to loopback is random in the way that irq is, some other
> alternate timing event could be used). Does anyone happen to know
> exactly how much "noise" could be extracted from hardware temperature
> monitors (would it be practical)?

(a) is why we need more sources of entropy, like my network patch or
your loopback idea

(b) is debatable. i disagree it poses any true threat to the system.

i dont think temperature probes would have that much noise.  i suppose
if they were precise enough you could use the least significant bits,
but what really matters is how much of that precision is exported via
its interface. i suppose the lsb may be useful.

what i think we really need it to audit more drivers and, of those that
would be "entropic", have them contributed to the entropy pool.

> D. Stimits, stimits@idcomm.com

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

[PATCH] let Net Devices feed Entropy, updated (1/2)

[Robert Love]

this is an update of my patch for 2.4.8-ac8 to allow user configuration
of whether or not network devices feed the entropy pool. the following
patch enables the new setting and provides configure text.  a subsequent
patch updates a handfull of drivers to use the new flag.

the patch works by creating a new request_irq flag, SA_SAMPLE_NET_RANDOM
which defines to SA_SAMPLE_RANDOM or 0 dependening on the configuration
setting (available in Network Devices).  thus the patch adds no more
code after compiling. for more information, see the previous emails in
this thread.

obviously some people fear NICs feeding entropy provides a hazard.  for
those who dont, or are increadibly low on entropy, enable the
configuration option.




diff -urN linux-2.4.8-ac7/Documentation/Configure.help linux/Documentation/Configure.help
--- linux-2.4.8-ac7/Documentation/Configure.help	Sat Aug 18 01:55:54 2001
+++ linux/Documentation/Configure.help	Sat Aug 18 01:52:21 2001
@@ -8679,6 +8679,19 @@
 
   If you don't know what to use this for, you don't need it.
 
+Allow Net Devices to contribute to /dev/random
+CONFIG_NET_RANDOM
+  If you say Y here, network device interrupts will contribute to the
+  kernel entropy pool at /dev/random. Normally, block devices and
+  some other devices (keyboard, mouse) add to the pool. Some people,
+  however, feel that network devices should not contribute to /dev/random
+  because an external attacker could manipulate incoming packets in a
+  manner to force the pool into a determinable state. Note this is
+  completely theoretical.
+
+  If you don't mind the risk or are using a headless system and are in
+  need of more entropy, say Y.
+
 Ethertap network tap (OBSOLETE)
 CONFIG_ETHERTAP
   If you say Y here (and have said Y to "Kernel/User network link
diff -urN linux-2.4.8-ac5/drivers/net/Config.in linux/drivers/net/Config.in
--- linux-2.4.8-ac7/drivers/net/Config.in	Wed Aug 15 19:05:34 2001
+++ linux/drivers/net/Config.in	Wed Aug 15 18:49:50 2001
@@ -9,6 +9,7 @@
 tristate 'Bonding driver support' CONFIG_BONDING
 tristate 'EQL (serial line load balancing) support' CONFIG_EQUALIZER
 tristate 'Universal TUN/TAP device driver support' CONFIG_TUN
+bool 'Allow Net Devices to contribute to /dev/random' CONFIG_NET_RANDOM
 if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
    if [ "$CONFIG_NETLINK" = "y" ]; then
       tristate 'Ethertap network tap (OBSOLETE)' CONFIG_ETHERTAP
diff -urN linux-2.4.8-ac7/include/asm-alpha/signal.h linux/include/asm-alpha/signal.h
--- linux-2.4.8-ac7/include/asm-alpha/signal.h	Wed Jun 24 17:30:11 1998
+++ linux/include/asm-alpha/signal.h	Sat Aug 18 01:52:21 2001
@@ -121,8 +121,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x40000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          1	/* for blocking signals */
 #define SIG_UNBLOCK        2	/* for unblocking signals */
 #define SIG_SETMASK        3	/* for setting the signal mask */
diff -urN linux-2.4.8-ac7/include/asm-arm/signal.h linux/include/asm-arm/signal.h
--- linux-2.4.8-ac7/include/asm-arm/signal.h	Thu Nov 18 22:37:03 1999
+++ linux/include/asm-arm/signal.h	Sat Aug 18 01:52:22 2001
@@ -124,8 +124,20 @@
 #define SA_SAMPLE_RANDOM	0x10000000
 #define SA_IRQNOMASK		0x08000000
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */
diff -urN linux-2.4.8-ac7/include/asm-cris/signal.h linux/include/asm-cris/signal.h
--- linux-2.4.8-ac7/include/asm-cris/signal.h	Thu Feb  8 19:32:44 2001
+++ linux/include/asm-cris/signal.h	Sat Aug 18 01:52:22 2001
@@ -120,8 +120,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */
diff -urN linux-2.4.8-ac7/include/asm-i386/signal.h linux/include/asm-i386/signal.h
--- linux-2.4.8-ac7/include/asm-i386/signal.h	Fri Aug 10 21:13:47 2001
+++ linux/include/asm-i386/signal.h	Sat Aug 18 01:52:22 2001
@@ -119,8 +119,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */
diff -urN linux-2.4.8-ac7/include/asm-ia64/signal.h linux/include/asm-ia64/signal.h
--- linux-2.4.8-ac7/include/asm-ia64/signal.h	Tue Jul 31 13:30:09 2001
+++ linux/include/asm-ia64/signal.h	Sat Aug 18 01:52:22 2001
@@ -106,6 +106,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK          0	/* for blocking signals */
diff -urN linux-2.4.8-ac7/include/asm-m68k/signal.h linux/include/asm-m68k/signal.h
--- linux-2.4.8-ac7/include/asm-m68k/signal.h	Thu Nov 18 22:37:03 1999
+++ linux/include/asm-m68k/signal.h	Sat Aug 18 01:52:22 2001
@@ -116,8 +116,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */
diff -urN linux-2.4.8-ac7/include/asm-mips/signal.h linux/include/asm-mips/signal.h
--- linux-2.4.8-ac7/include/asm-mips/signal.h	Mon Jul 10 01:18:15 2000
+++ linux/include/asm-mips/signal.h	Sat Aug 18 01:52:22 2001
@@ -111,6 +111,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x02000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK	1	/* for blocking signals */
diff -urN linux-2.4.8-ac7/include/asm-mips64/signal.h linux/include/asm-mips64/signal.h
--- linux-2.4.8-ac7/include/asm-mips64/signal.h	Sat May 13 11:31:25 2000
+++ linux/include/asm-mips64/signal.h	Sat Aug 18 01:52:22 2001
@@ -112,6 +112,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x02000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK	1	/* for blocking signals */
diff -urN linux-2.4.8-ac7/include/asm-parisc/signal.h linux/include/asm-parisc/signal.h
--- linux-2.4.8-ac7/include/asm-parisc/signal.h	Tue Dec  5 15:29:39 2000
+++ linux/include/asm-parisc/signal.h	Sat Aug 18 01:52:22 2001
@@ -100,6 +100,17 @@
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
 
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
+#endif
+
 #endif /* __KERNEL__ */
 
 #define SIG_BLOCK          0	/* for blocking signals */
diff -urN linux-2.4.8-ac7/include/asm-ppc/signal.h linux/include/asm-ppc/signal.h
--- linux-2.4.8-ac7/include/asm-ppc/signal.h	Mon May 21 18:02:06 2001
+++ linux/include/asm-ppc/signal.h	Sat Aug 18 01:52:22 2001
@@ -114,8 +114,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */
diff -urN linux-2.4.8-ac7/include/asm-ppc64/signal.h linux/include/asm-ppc64/signal.h
--- linux-2.4.8-ac7/include/asm-ppc64/signal.h	Sat Aug 18 01:56:04 2001
+++ linux/include/asm-ppc64/signal.h	Sat Aug 18 01:52:22 2001
@@ -117,8 +117,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */
diff -urN linux-2.4.8-ac7/include/asm-s390/signal.h linux/include/asm-s390/signal.h
--- linux-2.4.8-ac7/include/asm-s390/signal.h	Wed Apr 11 22:02:28 2001
+++ linux/include/asm-s390/signal.h	Sat Aug 18 01:52:22 2001
@@ -127,8 +127,20 @@
 #define SA_PROBE                SA_ONESHOT
 #define SA_SAMPLE_RANDOM        SA_RESTART
 #define SA_SHIRQ                0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0    /* for blocking signals */
 #define SIG_UNBLOCK        1    /* for unblocking signals */
 #define SIG_SETMASK        2    /* for setting the signal mask */
diff -urN linux-2.4.8-ac7/include/asm-s390x/signal.h linux/include/asm-s390x/signal.h
--- linux-2.4.8-ac7/include/asm-s390x/signal.h	Wed Jul 25 17:12:02 2001
+++ linux/include/asm-s390x/signal.h	Sat Aug 18 01:52:22 2001
@@ -127,8 +127,20 @@
 #define SA_PROBE                SA_ONESHOT
 #define SA_SAMPLE_RANDOM        SA_RESTART
 #define SA_SHIRQ                0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0    /* for blocking signals */
 #define SIG_UNBLOCK        1    /* for unblocking signals */
 #define SIG_SETMASK        2    /* for setting the signal mask */
diff -urN linux-2.4.8-ac7/include/asm-sh/signal.h linux/include/asm-sh/signal.h
--- linux-2.4.8-ac7/include/asm-sh/signal.h	Thu Nov 18 22:37:03 1999
+++ linux/include/asm-sh/signal.h	Sat Aug 18 01:52:22 2001
@@ -107,8 +107,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */
diff -urN linux-2.4.8-ac7/include/asm-sparc/signal.h linux/include/asm-sparc/signal.h
--- linux-2.4.8-ac7/include/asm-sparc/signal.h	Wed Sep  8 14:14:32 1999
+++ linux/include/asm-sparc/signal.h	Sat Aug 18 01:52:22 2001
@@ -176,8 +176,20 @@
 #define SA_PROBE SA_ONESHOT
 #define SA_SAMPLE_RANDOM SA_RESTART
 #define SA_STATIC_ALLOC		0x80
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 /* Type of a signal handler.  */
 #ifdef __KERNEL__
 typedef void (*__sighandler_t)(int, int, struct sigcontext *, char *);
diff -urN linux-2.4.8-ac7/include/asm-sparc64/signal.h linux/include/asm-sparc64/signal.h
--- linux-2.4.8-ac7/include/asm-sparc64/signal.h	Wed Sep  8 14:14:32 1999
+++ linux/include/asm-sparc64/signal.h	Sat Aug 18 01:52:22 2001
@@ -192,8 +192,20 @@
 #define SA_PROBE SA_ONESHOT
 #define SA_SAMPLE_RANDOM SA_RESTART
 #define SA_STATIC_ALLOC		0x80
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 /* Type of a signal handler.  */
 #ifdef __KERNEL__
 typedef void (*__sighandler_t)(int, struct sigcontext *);
diff -urN linux-2.4.8-ac7/include/asm-x86_64/signal.h linux/include/asm-x86_64/signal.h
--- linux-2.4.8-ac7/include/asm-x86_64/signal.h	Sat Aug 18 01:56:04 2001
+++ linux/include/asm-x86_64/signal.h	Sat Aug 18 01:54:01 2001
@@ -119,8 +119,20 @@
 #define SA_PROBE		SA_ONESHOT
 #define SA_SAMPLE_RANDOM	SA_RESTART
 #define SA_SHIRQ		0x04000000
+
+/*
+ * Net Devices can use SA_SAMPLE_NET_RANDOM and thus only
+ * contribute to the kernel entropy pool if users want that
+ * at compile time.
+ */
+#ifdef CONFIG_NET_RANDOM
+#define SA_SAMPLE_NET_RANDOM	SA_SAMPLE_RANDOM
+#else
+#define SA_SAMPLE_NET_RANDOM	0
 #endif
 
+#endif /* __KERNEL__ */
+
 #define SIG_BLOCK          0	/* for blocking signals */
 #define SIG_UNBLOCK        1	/* for unblocking signals */
 #define SIG_SETMASK        2	/* for setting the signal mask */




-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Oliver Xymoron]

On 18 Aug 2001, Robert Love wrote:

> obviously some people fear NICs feeding entropy provides a hazard.  for
> those who dont, or are increadibly low on entropy, enable the
> configuration option.

Why don't those who aren't worried about whether they _really_ have enough
entropy simply use /dev/urandom?

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Rik van Riel]

On Sat, 18 Aug 2001, Oliver Xymoron wrote:
> On 18 Aug 2001, Robert Love wrote:
>
> > obviously some people fear NICs feeding entropy provides a hazard.  for
> > those who dont, or are increadibly low on entropy, enable the
> > configuration option.
>
> Why don't those who aren't worried about whether they _really_ have
> enough entropy simply use /dev/urandom?

So how are you going to feed /dev/urandom on your firewall ??
(which has no keyboard, program or disk activity)

Network entropy is probably better than no entropy for many
applications.

Rik
--
IA64: a worthy successor to i860.

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Oliver Xymoron]

On Sat, 18 Aug 2001, Rik van Riel wrote:

> On Sat, 18 Aug 2001, Oliver Xymoron wrote:
> > On 18 Aug 2001, Robert Love wrote:
> >
> > > obviously some people fear NICs feeding entropy provides a hazard.  for
> > > those who dont, or are increadibly low on entropy, enable the
> > > configuration option.
> >
> > Why don't those who aren't worried about whether they _really_ have
> > enough entropy simply use /dev/urandom?
>
> So how are you going to feed /dev/urandom on your firewall ??
> (which has no keyboard, program or disk activity)

The network is still feeding data to the pool, yes? It's merely
underestimating the value of that data. If you think you're getting enough
entropy for your application, use /dev/urandom, don't weaken /dev/random.

Practically speaking, /dev/urandom is pretty damn strong anyway.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Robert Love]

On 18 Aug 2001 22:33:54 -0500, Oliver Xymoron wrote:
> The network is still feeding data to the pool, yes? It's merely
> underestimating the value of that data. If you think you're getting enough
> entropy for your application, use /dev/urandom, don't weaken /dev/random.
> 
> Practically speaking, /dev/urandom is pretty damn strong anyway.

Honestly, I don't have a clue what you are talking about.  I think you
have a misconception about how the entropy gathering works, the
differences between /dev/random and /dev/urandom, and what entropy even
is.

I don't know what your problem is with with allowing net devices to feed
the pool.

Finally, /dev/random and /dev/urandom have the same "strength" -- the
_only_ difference is that /dev/random will block if the _entropy_ count
is 0. note, again, this is not the byte count.  by design, the size of
the pool does not decrement as you read from it. just the estimate of
the entropy.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Philipp Matthias Hahn]

On Sat, 18 Aug 2001, Oliver Xymoron wrote:
> > > On 18 Aug 2001, Robert Love wrote:
> > > > obviously some people fear NICs feeding entropy provides a hazard.  for
> > > > those who dont, or are increadibly low on entropy, enable the
> > > > configuration option.
> The network is still feeding data to the pool, yes? It's merely
> underestimating the value of that data. If you think you're getting enough
> entropy for your application, use /dev/urandom, don't weaken /dev/random.

Read it the other way around:
He fixed a bug where some network devices where feeding the pool illegally
and making your system "unsecure". The "bug-fix" is configurable so you
can choose for yourself, if you want to have the "old broken unsecure"
bahaviour or you want to disable all entropy feeding by NICs and want your
processes get stuck when reading /dev/random.

BYtE
Philipp
-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Mike Castle]

On Sat, Aug 18, 2001 at 09:38:21PM -0300, Rik van Riel wrote:
> So how are you going to feed /dev/urandom on your firewall ??
> (which has no keyboard, program or disk activity)

Hardware random generator?

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Robert Love]

On 18 Aug 2001 18:41:30 -0500, Oliver Xymoron wrote:
> Why don't those who aren't worried about whether they _really_ have enough
> entropy simply use /dev/urandom?

because there still is no entropy.  /dev/urandom and /dev/random are
from the same source - /dev/random will just block if the entropy count
drops to 0.  note that entropy != bytes in pool.  the "entropy" is an
estimate of the randomness of the pool.  it decrements as bytes are
pulled from the pool.  the byte count does not, thus the pool is not
empty when /dev/random blocks, it just has no "entropy".

on a diskless/headless system, there are no devices to feed the entropy
pool.  thus this patch, which is a lifesaver for some, as Rik pointed
out.

or maybe you are like me, and on a personal LAN or dont care about
external attackers trying to guess your /dev/random, and just want
another source of entropy to boost your self-esteem.

i would like to see this in the mainline kernel. i posted a 2.4.8-pre
patch early, i will rediff for 2.4.9 asap.

fyi, i am considering rewriting the patch. Alex Bligh and I had a
discussion where he suggested a sysctl/proc interface to toggle the
option. this would add post-compile code to the kernel, but allow
greater flexibility.  

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Oliver Xymoron]

On 18 Aug 2001, Robert Love wrote:

> On 18 Aug 2001 18:41:30 -0500, Oliver Xymoron wrote:
> > Why don't those who aren't worried about whether they _really_ have enough
> > entropy simply use /dev/urandom?
>
> because there still is no entropy.

But your claim is there _is_ entropy. If you think there is, go ahead and
use it. Via /dev/urandom. Yes, I know it's theoretically not secure, but
then neither is what you're proposing.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Rik van Riel]

On Sat, 18 Aug 2001, Oliver Xymoron wrote:

> But your claim is there _is_ entropy. If you think there is, go ahead
> and use it. Via /dev/urandom. Yes, I know it's theoretically not
> secure, but then neither is what you're proposing.

OK, you seem to have a misunderstanding about both the
meaning of "entropy" and the things which have been
written and proposed in this thread.

Robert, please don't let Oliver discourage you.

regards,

Rik
--
IA64: a worthy successor to i860.

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Robert Love]

On 19 Aug 2001 00:41:46 -0300, Rik van Riel wrote:
> OK, you seem to have a misunderstanding about both the
> meaning of "entropy" and the things which have been
> written and proposed in this thread.
> 
> Robert, please don't let Oliver discourage you.

I won't, and I appreciate your encourangement and help in this thread.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Robert Love]

On 18 Aug 2001 22:36:00 -0500, Oliver Xymoron wrote:
> But your claim is there _is_ entropy. If you think there is, go ahead and
> use it. Via /dev/urandom. Yes, I know it's theoretically not secure, but
> then neither is what you're proposing.

I am only continuing this because I want to explain...

I claim there is entropy from what?  The difference between interrupts
for net devices?  Everyone agrees that there is.  The issues is that an
external attacker could influence the interrupts to the net device, and
thus make some assumptions about the state.  That is why this patch is
configurable.  Do as you please.  As I said, some people want it or need
it.

Again, /dev/urandom is just as "secure" as /dev/random.  Its the same
pool.  The same stuff.  Except that /dev/random blocks when the entropy
count hits 0.

Now, this count is purely theoretical, too.  Its an estime of the amount
of entropy -- lack of determinability -- in the pool of bytes.

Even when it reaches 0, since the pool is still unknown (only previous
output may be known) and the output is hashed, its still pretty much
undeterminable.  But mathematically and theoretically, our entropy
estimate says it is not.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[lists]

 Perhaps the patch does this already, but if there are concerns about
 pollution from the nasty outside is it possible to add a flag to /proc
 to turn this on/off by interface - that way it could easily be limited
 to only get influenced by the inside network rather than the outside.

 Regards,

 gene/
 lists@sapience.com

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Alex Bligh - linux-kernel]

Gene,

>  Perhaps the patch does this already, but if there are concerns about
>  pollution from the nasty outside is it possible to add a flag to /proc
>  to turn this on/off by interface - that way it could easily be limited
>  to only get influenced by the inside network rather than the outside.

No it doesn't do this, but:

Because it looks at inter-IRQ timing, the risk is mainly (as per
previous posting) the theoretical risk of being able to determine
that inter-IRQ timing from observation of the network(s) connected.
So an attacker sending packets at known intervals on one network
when interleaved with packets arriving at unknown intervals on
another network will not do them much good. Equally observations
made on packet timings on one network will be useless if those
packets are interleaved with packets arriving on another network.
As per previous posting, there is a theoretical risk, (magnitude
dependent upon environment) - hence the config option - but rather
smaller than the risk (say) if you are using a radio mouse & keyboard.

--
Alex Bligh

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Oliver Xymoron]

On 18 Aug 2001, Robert Love wrote:

> On 18 Aug 2001 22:36:00 -0500, Oliver Xymoron wrote:
> > But your claim is there _is_ entropy. If you think there is, go ahead and
> > use it. Via /dev/urandom. Yes, I know it's theoretically not secure, but
> > then neither is what you're proposing.
>
> I am only continuing this because I want to explain...
>
> I claim there is entropy from what?  The difference between interrupts
> for net devices?  Everyone agrees that there is.  The issues is that an
> external attacker could influence the interrupts to the net device, and
> thus make some assumptions about the state.

No, everyone does not agree. Entropy is the degree to which data is
unpredictable. If an attacker can know what's being added to the pool, its
entropy value is zero.[1]

My understanding is that net devices are still mixing data into the pool,
but with an entropy estimate of zero. This seems perfectly fair to me,
it's always safe to underestimate entropy. If they're not mixing data into
the pool at all any more, then that seems wrong to me - we should be
adding likely sources of entropy as well, even if we can't rely on them
enough to credit them.

> Again, /dev/urandom is just as "secure" as /dev/random.  Its the same
> pool.  The same stuff.  Except that /dev/random blocks when the entropy
> count hits 0.

The 'except' is the key difference. IFF the entropy estimate is correct
(less than or equal to the real entropy present in the pool), then the
data return by /dev/random is completely unknowable. /dev/urandom is still
quite strong cryptographically, but not 'perfect' (ignoring possible
bugs, of course).

What you're suggesting is weakening that model. If you care enough to use
/dev/random instead of /dev/urandom because of the -theoretical- security
differences, then you're actually concerned about attackers. Namely
attackers who can go after your network, perhaps taking over your routers
and gateways. By making /dev/random mark network data as real entropy, you
are just fooling yourself. The 'perfect' quality of /dev/random is lost,
and the theoretical difference between it and /dev/urandom vanishes.

So why go to the trouble? Just admit that you don't have enough real
entropy on your system and, if you find the risk acceptable, use
/dev/urandom. Adding a kernel option that says 'make /dev/random be
overconfident' is not the answer.

[1] The extent to which an attacker can mount a timing attack against the
interrupt generation on a fast NIC is unknown but we'd prefer not to be
surprised.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[David Madore]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4859 bytes --]

This discussion is getting nowhere.

Oliver Xymoron in litteris
<Pine.LNX.4.30.0108191124430.740-100000@waste.org> scripsit:
>		      to the real entropy
<...>
>				 'perfect' quality of /dev/random
<...>
>								  real
> entropy

There is no such thing as "real" entropy.  Even in thermodynamics
there is no such thing as "real" entropy.  All entropy is relative to
some knowledge base.  It does not make any sense to say "the entropy
pool contains so-and-so-many logons of entropy".  For a user who can
read the kernel memory, the entropy of the pool is 0 at all times.
For a user who has not come into contact with the box, the entropy is
4096 logons (assuming the pool's size is 4096 bits) when contact is
initiated, and drops by *at most* 8 logons for every bit that is read
from /dev/random - but it is not the state of /dev/random itself which
changes, nor its "absolute" entropy (there is no such thing), it is
only its entropy relative to a certain knowledge base.

Now the kernel makes some very conservative assumptions about the
knowledge base and evaluates the corresponding entropy.  It assumes,
for example, that all outputs of /dev/random are fed to the same
knowledge base.  That is, it maintains only one entropy count (rather
than, e.g., one per process).  This is necessary for simplicity and
security in all cases, but in some cases it may be a tremendous
underestimate of the amount of entropy.  Similarly, it assumes that
every byte that is produced by /dev/random (or /dev/urandom) decreases
the entropy count by 8 logons.  This is also a conservative
assumption; if a program uses only, say, the values it reads mod 26,
then every byte spills only 4.7 logons (relative to the knowledge base
of an observer who can only read those mod 26 values).  Finally, the
kernel assumes that the knowledge base of the observer contains the
mean value and standard deviation and various similar statistical
moments of various "entropy sources", but not their actual contents;
and a choice has been made among those entropy sources.

These are very sensible assumptions, but these are assumptions
nonetheless.  It is utterly naïve to think that the entropy count
maintained by the kernel is the "real entropy count" of the pool, in
some physical sense.  For most useful knowledge bases, the kernel
tremendously *underestimates* the entropy of the pool; in fact, we
might say that for all "useful purposes", the entropy is infinite at
all times.  Supposing it is not means we suppose at least that the
observer can crack the hash function used for stirring the pool, which
is not at all an obvious task.

But the kernel might also overestimate the entropy count.  As I
mentioned before, for someone who can break root in the box, the
entropy is zero at all times.  For someone who can monitor electrical
fluctuations with great enough accuracy, the entropy is not as high as
it may seem.  Also, the assumption made that the added entropy can be
estimated (for timer events) using the first three deltas of the
event's timing, can fail in certain circumstances (and not very nasty
or unreasonable circumstances: if the event occurs at intervals which
follow a cycle of length at least five, you are adding a bounded
amount of entropy to the pool relative to a user who knows this fact,
even if you let the event feed the pool for an arbitrarly long time,
but the kernel will assume that you are, indeed, feeding it boundless
amounts of entropy; so a simple 5-periodic event will cause the
kernel's estimations to fail miserably).

The morale of all this is: the /dev/random device is a useful service,
because the kernel does a pretty good job of producing very pure
random numbers.  But it is not utterly fail-safe.  It nearly always
underestimates the entropy (for what you're concerned with), and it
may overestimate it.

Thus, if you have specific knowledge about your system, it makes
perfect sense to adjust the entropy evaluation.  For example, if you
know that the observers you're concerned about (those against whom you
use the random numbers) cannot observe your network devices (e.g., if
your network device is connected to a local network and you are using
the random numbers across the Internet), it is perfectly reasonable to
add network devices in the estimation of the entropy count.  It does
not make it any less secure.  It merely does not underestimate the
entropy as much.

But all this is completely theoretical, anyway.  Even if your life is
at stake, you can be completely confident that nobody can predict the
next 64 bits that are going to come out of /dev/urandom, even if you
give that would-be-predictor the previous 64kbytes that did come out
of it, and even if you removed *all* the entropy sources from the
system.

-- 
     David A. Madore
    (david.madore@ens.fr,
     http://www.eleves.ens.fr:8080/home/madore/ )

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Oliver Xymoron]

On Sun, 19 Aug 2001, Oliver Xymoron wrote:

> My understanding is that net devices are still mixing data into the pool,
> but with an entropy estimate of zero.

..which appears to be wrong.

> If they're not mixing data into the pool at all any more, then that
> seems wrong to me - we should be adding likely sources of entropy as
> well, even if we can't rely on them enough to credit them.

What we really need is an add_untrusted_randomness().

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Alex Bligh - linux-kernel]

Robert,

> I claim there is entropy from what?  The difference between interrupts
> for net devices?  Everyone agrees that there is.  The issues is that an
> external attacker could influence the interrupts to the net device, and
                          ^^^^^^^^^

Actually, to be fair, the true risk is more that an external attacker could
/obvserve/ the timing of packets to the NIC with sufficient accuracy to
predict the inter-IRQ timing, and hence the consequent manipulation of
the pool. This would mean that entropy was being added, (assuming a system
free of entropy to start with), eventually causing /dev/random not to block,
and thus, short of any other entropy, the net effect would be that
/dev/random would become exactly as good/bad a random number source
as /dev/urandom. However, in most environments, it is not possible
to observe and accurately (microseconds) time the packet coming into
the NIC without physical access to the machine (in which case there
are, urm, easier attacks), and there is a largely indeterminable latency
between the arrival of the packet and the consequent network IRQ, this
latency being neither externally visible, nor being determinable by
some non-root user.

--
Alex Bligh

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[David Ford]

Then add another factor to the equation, randomly pick the next event.

Consider if you would, gather entropy by choosing random bytes from 
checksums from random packets.  All the selection isn't technically 
random but very uncontrolled.  You start by picking a random packet 
(seeded from existing entropy), and take a random byte from the checksum 
of that packet.  Using that byte, add it to the entropy pool and use it 
to help determine the next 'random' packet you'll swipe data from.

An attacker would have to have absolute control over the packets 
arriving at the machine to have a chance.  He still cannot know exactly 
which packets are chosen for entropy gathering being that the next 
packet is chosen randomly from two or more entropy sources.  Neither 
will he know which byte(s) in the checksum are chosen.

In real world situations you should have a plentiful source of 'noise'. 
 The above idea can be improved upon significantly I'm sure.

David

Alex Bligh - linux-kernel wrote:

> Robert,
>
>> I claim there is entropy from what?  The difference between interrupts
>> for net devices?  Everyone agrees that there is.  The issues is that an
>> external attacker could influence the interrupts to the net device, and
>
>                          ^^^^^^^^^
>
> Actually, to be fair, the true risk is more that an external attacker 
> could
> /obvserve/ the timing of packets to the NIC with sufficient accuracy to
> predict the inter-IRQ timing, and hence the consequent manipulation of
> the pool. This would mean that entropy was being added, (assuming a 
> system
> free of entropy to start with), eventually causing /dev/random not to 
> block,
> and thus, short of any other entropy, the net effect would be that
> /dev/random would become exactly as good/bad a random number source
> as /dev/urandom. However, in most environments, it is not possible
> to observe and accurately (microseconds) time the packet coming into
> the NIC without physical access to the machine (in which case there
> are, urm, easier attacks), and there is a largely indeterminable latency
> between the arrival of the packet and the consequent network IRQ, this
> latency being neither externally visible, nor being determinable by
> some non-root user.

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Martin Dalecki]

Robert Love wrote:
> 
> On 18 Aug 2001 22:36:00 -0500, Oliver Xymoron wrote:
> > But your claim is there _is_ entropy. If you think there is, go ahead and
> > use it. Via /dev/urandom. Yes, I know it's theoretically not secure, but
> > then neither is what you're proposing.
> 
> I am only continuing this because I want to explain...
> 
> I claim there is entropy from what?  The difference between interrupts
> for net devices?  Everyone agrees that there is.  The issues is that an
> external attacker could influence the interrupts to the net device, and
> thus make some assumptions about the state.  That is why this patch is
> configurable.  Do as you please.  As I said, some people want it or need
> it.

I think you are just wrong - nobody really needs this patch. /dev/random
or /dev/urandom ar *both* anyway just complete overkill in terms of 
practical security. /dev/urandom is in esp silly, since it is providing
a md5 hash
implementation inside the kernel, which could be *compleatly* and
entierly
done inside user land.

> Again, /dev/urandom is just as "secure" as /dev/random.  Its the same
> pool.  The same stuff.  Except that /dev/random blocks when the entropy
> count hits 0.
> 
> Now, this count is purely theoretical, too.  Its an estime of the amount
> of entropy -- lack of determinability -- in the pool of bytes.

Wrong. Don't let you confuse yourself by the way the term entropy is
used in
the documentation of /dev/random - it's an abuse of the mathematical
definition anyway. The more appriopriate term there
would be: signal source variability estimate.

> Even when it reaches 0, since the pool is still unknown (only previous
> output may be known) and the output is hashed, its still pretty much
> undeterminable.  But mathematically and theoretically, our entropy
> estimate says it is not.

You mean - there is no known algorithm with polynomial time
behaviour enabling us to calculate the next value of this function
from the previous ones - Not more nor less - no pysics and
entropy involved. If you assume this holds true it's mathematically
entierly sufficient that a single only seed value is not known.

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Johan Adolfsson]

Martin Dalecki <dalecki@evision-ventures.com> wrote:
> I think you are just wrong - nobody really needs this patch. /dev/random
> or /dev/urandom ar *both* anyway just complete overkill in terms of
> practical security. /dev/urandom is in esp silly, since it is providing
> a md5 hash implementation inside the kernel, which could be *compleatly*
and
> entierly done inside user land.

And I think you are wrong, this patch is needed.
Keep up the good work Robert!

> You mean - there is no known algorithm with polynomial time
> behaviour enabling us to calculate the next value of this function
> from the previous ones - Not more nor less - no pysics and
> entropy involved. If you assume this holds true it's mathematically
> entierly sufficient that a single only seed value is not known.

Where would you get the single seed from in an embedded head
less system if you don't have a hardware random generator,
no disk and don't seed it from the network interrupts?

I think the patch makes sense - let people have the config option.

/Johan

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Martin Dalecki]

Johan Adolfsson wrote:
> 
> Martin Dalecki <dalecki@evision-ventures.com> wrote:
> > I think you are just wrong - nobody really needs this patch. /dev/random
> > or /dev/urandom ar *both* anyway just complete overkill in terms of
> > practical security. /dev/urandom is in esp silly, since it is providing
> > a md5 hash implementation inside the kernel, which could be *compleatly*
> and
> > entierly done inside user land.
> 
> And I think you are wrong, this patch is needed.
> Keep up the good work Robert!
> 
> > You mean - there is no known algorithm with polynomial time
> > behaviour enabling us to calculate the next value of this function
> > from the previous ones - Not more nor less - no pysics and
> > entropy involved. If you assume this holds true it's mathematically
> > entierly sufficient that a single only seed value is not known.
> 
> Where would you get the single seed from in an embedded head
> less system if you don't have a hardware random generator,
> no disk and don't seed it from the network interrupts?

The device get's powerd up at a random time for the attacker.
That's entierly sufficient if you assume that your checksum function
f(i) hat the property that there is no function g, where we have
f(i+1)=g(f(i)), where g has a polynomial order over the time domain.
i is unknown for the attacker.

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Johan Adolfsson]

> Johan Adolfsson wrote:
> > Where would you get the single seed from in an embedded head
> > less system if you don't have a hardware random generator,
> > no disk and don't seed it from the network interrupts?

Martin Dalecki wrote: 
> The device get's powerd up at a random time for the attacker.

Perhaps true, but for some systems, the time it takes for a certain 
application that need some random data to start is the same at 
each powerup (more or less) so the application might use the 
same session key the first time after each powerup.
(Not that gathering info from network interrupt necessarily 
would improve this case, but it might)

> That's entierly sufficient if you assume that your checksum function
> f(i) hat the property that there is no function g, where we have
> f(i+1)=g(f(i)), where g has a polynomial order over the time domain.
> i is unknown for the attacker.

Can't say I know the details of the functions used in the /dev/[u]random 
functions to say if that assumption is true. But I feel that stiring the
pool using interrupt timing and thus adding the number of unknowns
can't be a bad thing.
Simply relying on the uptime would make it really easy to
predict the f() function wouldn't it?

/Johan

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Alex Bligh - linux-kernel]

> The device get's powerd up at a random time for the attacker.
> That's entierly sufficient if you assume that your checksum function
> f(i) hat the property that there is no function g, where we have
> f(i+1)=g(f(i)), where g has a polynomial order over the time domain.
> i is unknown for the attacker.

So, your argument is that there is no point in all this
entropy collection anyway. So if everything is hunky dory,
why have /dev/random block under such a circumstance?
(which was the original poster's  problem).

--
Alex Bligh

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Martin Dalecki]

Alex Bligh - linux-kernel wrote:
> 
> > The device get's powerd up at a random time for the attacker.
> > That's entierly sufficient if you assume that your checksum function
> > f(i) hat the property that there is no function g, where we have
> > f(i+1)=g(f(i)), where g has a polynomial order over the time domain.
> > i is unknown for the attacker.
> 
> So, your argument is that there is no point in all this
> entropy collection anyway. So if everything is hunky dory,
> why have /dev/random block under such a circumstance?

You are entierly right. 

The primary reson of invention of /dev/random was the need
for a bit of salt to the initial packet sequence number inside
the networking code in linux. And for this purspose the
whole /dev/*random stuff is INDEED a gratitious overdesign.
For anything else crypto related it just doesn't cut the corner.
If you look at the archives I have objected it strongly in the history.

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Theodore Tso]

On Mon, Aug 20, 2001 at 04:25:26PM +0200, Martin Dalecki wrote:
> 
> The primary reson of invention of /dev/random was the need
> for a bit of salt to the initial packet sequence number inside
> the networking code in linux. And for this purspose the
> whole /dev/*random stuff is INDEED a gratitious overdesign.

That simply isn't true.  The original reason that I wrote the
/dev/random driver is that was for crypto key gneration.  The primary
use environment was to provide better key generation routines for user
applications such as PGP, etc., which is the first devices that I
implemented for entropy collection was the keyboard and mouse devices.

The use of the /dev/random code for other purposes (generating initial
packet sequence numbers for networking, generating a unique
boot-session identifier which was requested by the emacs folks, etc.),
all came later.

> For anything else crypto related it just doesn't cut the corner.

A number of other people helped me with the design and development of
the /dev/random driver, including one of the primary authors of the
random number generation routines in PGP 2.x and 5.0.  Most folks feel
that it does a good job.


						- Ted

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Richard Gooch]

Theodore Tso writes:
> On Mon, Aug 20, 2001 at 04:25:26PM +0200, Martin Dalecki wrote:
> > 
> > The primary reson of invention of /dev/random was the need
> > for a bit of salt to the initial packet sequence number inside
> > the networking code in linux. And for this purspose the
> > whole /dev/*random stuff is INDEED a gratitious overdesign.
> > For anything else crypto related it just doesn't cut the corner.
> 
> A number of other people helped me with the design and development of
> the /dev/random driver, including one of the primary authors of the
> random number generation routines in PGP 2.x and 5.0.  Most folks feel
> that it does a good job.

Indeed. If Martin has some deep insight as to why the /dev/random
implementation is insufficient for strong crypto, I'd like to hear
it.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Martin Dalecki]

Richard Gooch wrote:
> 
> Theodore Tso writes:
> > On Mon, Aug 20, 2001 at 04:25:26PM +0200, Martin Dalecki wrote:
> > >
> > > The primary reson of invention of /dev/random was the need
> > > for a bit of salt to the initial packet sequence number inside
> > > the networking code in linux. And for this purspose the
> > > whole /dev/*random stuff is INDEED a gratitious overdesign.
> > > For anything else crypto related it just doesn't cut the corner.
> >
> > A number of other people helped me with the design and development of
> > the /dev/random driver, including one of the primary authors of the
> > random number generation routines in PGP 2.x and 5.0.  Most folks feel
> > that it does a good job.
> 
> Indeed. If Martin has some deep insight as to why the /dev/random
> implementation is insufficient for strong crypto, I'd like to hear
> it.

I don't think that it's unsufficient. In fact I think that it just
doesn't
have to be done all inside the kernel. And I oppose further extending
the
places where the event gathering code goes in between.

BTW> There is one strong flaw in the resoning behing this whole entropy
stuff.

Iff you trust the cryptographic algorithm for the one way function you
are
using then if you initialize it once - there will be only one chance for
an attacker to tamper with the values. The possibility
for tampering with it will have a certain value, which remains CONSTANT
over
the time. You could call it: breaking risk as well.

If you continuously reinitialize your one way function, the propabilitie
to
tamper with them will ADD (of course not in pure arithmetic terms). An
attacer simply
get's multiple chances. And therefore the overall propability of
tampering 
with the values delivered to the user by this device WILL INCREASE.

Multiple initializations help only against cryptographic attacks - but
THEY HURT
overall security of the system, becouse they "open it up".

So this is indeed a serious FLAW inside the logics behind the
implementation of this device.

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Johan Adolfsson]

Martin Dalecki wrote:
> I don't think that it's unsufficient. In fact I think that it just
> doesn't have to be done all inside the kernel. And I oppose further
extending
> the places where the event gathering code goes in between.

As Alex said, since applications expect it to be there I see no reason to
remove it.


> BTW> There is one strong flaw in the resoning behing this whole entropy
> stuff.
>
> Iff you trust the cryptographic algorithm for the one way function you
> are using then if you initialize it once - there will be only one chance
for
> an attacker to tamper with the values. The possibility
> for tampering with it will have a certain value, which remains CONSTANT
> over the time. You could call it: breaking risk as well.

Since the boot process is predictable, it would be much easier for an
attacker to set up an identical setup and it would be no problem at all to
predict the random sequence. Then it would probably be easy to
do a DoS attack forcing the system to reboot and then break in.

> If you continuously reinitialize your one way function, the propabilitie
> to tamper with them will ADD (of course not in pure arithmetic terms).
> An attacer simply get's multiple chances. And therefore the overall
> propability of tampering
> with the values delivered to the user by this device WILL INCREASE.
>
> Multiple initializations help only against cryptographic attacks - but
> THEY HURT
> overall security of the system, becouse they "open it up".
>
> So this is indeed a serious FLAW inside the logics behind the
> implementation of this device.

This sounds bogus to me..;-)
I don't buy it!

/Johan

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Richard Gooch]

Martin Dalecki writes:
> Richard Gooch wrote:
> > 
> > Theodore Tso writes:
> > > On Mon, Aug 20, 2001 at 04:25:26PM +0200, Martin Dalecki wrote:
> > > >
> > > > The primary reson of invention of /dev/random was the need
> > > > for a bit of salt to the initial packet sequence number inside
> > > > the networking code in linux. And for this purspose the
> > > > whole /dev/*random stuff is INDEED a gratitious overdesign.
> > > > For anything else crypto related it just doesn't cut the corner.
> > >
> > > A number of other people helped me with the design and development of
> > > the /dev/random driver, including one of the primary authors of the
> > > random number generation routines in PGP 2.x and 5.0.  Most folks feel
> > > that it does a good job.
> > 
> > Indeed. If Martin has some deep insight as to why the /dev/random
> > implementation is insufficient for strong crypto, I'd like to hear
> > it.
> 
> I don't think that it's unsufficient. In fact I think that it just
> doesn't have to be done all inside the kernel.

This is inconsistent with your earlier comment "for anything else
crypto related it just doesn't cut the corner". So are you retracting
that statement?

> And I oppose further extending the places where the event gathering
> code goes in between.
> 
> BTW> There is one strong flaw in the resoning behing this whole entropy
> stuff.
> 
> Iff you trust the cryptographic algorithm for the one way function
> you are using then if you initialize it once - there will be only
> one chance for an attacker to tamper with the values. The
> possibility for tampering with it will have a certain value, which
> remains CONSTANT over the time. You could call it: breaking risk as
> well.

I'm fairly confident that a user on the system can't tamper with my
mouse movements and keyboard presses. As for other interrupt sources
(such as network, disc and so on) which may be vulnerable to
"tampering" (i.e. injection or monitoring of timing data), that's why
we have the concept of "entropy". Think of it as a measure of trust.

> If you continuously reinitialize your one way function, the
> propabilitie to tamper with them will ADD (of course not in pure
> arithmetic terms). An attacer simply get's multiple chances. And
> therefore the overall propability of tampering with the values
> delivered to the user by this device WILL INCREASE.

This is a completely flawed argument. The more entropy inputs there
are, the harder it is for an attacker to predict or control all of
them.

> Multiple initializations help only against cryptographic attacks -
> but THEY HURT overall security of the system, becouse they "open it
> up".

This doesn't make sense. If, as you say, something is better against
cryptographic attacks, then the overall security of the system is
better. A trivially obvious example is TCP.

> So this is indeed a serious FLAW inside the logics behind the
> implementation of this device.

The flaw is in your argument, which isn't logical, and uses
hand-waving in place of coherent step-by-step analysis of how
/dev/random is somehow harmful to security. Use of a few choice words
in uppercase isn't convincing. Furthermore, you talk about a risk to
system security, but you don't even clearly define what you mean be
that.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[David Wagner]

Martin Dalecki  wrote:
>Multiple initializations help only against cryptographic attacks - but
>THEY HURT overall security of the system, becouse they "open it up".

Either I completely misunderstood what you are trying to say, or your
claim is simply not true.  I've done considerable research on generating
randomness for cryptography, and I think you're a little confused about
how /dev/{,u}random work and about their cryptographic properties.

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Robert Love]

On Mon, 2001-08-20 at 21:11, Theodore Tso wrote:
> A number of other people helped me with the design and development of
> the /dev/random driver, including one of the primary authors of the
> random number generation routines in PGP 2.x and 5.0.  Most folks feel
> that it does a good job.

It does :)

Thank you for adding to this thread.  I want your opinion: as the author
of /dev/random, its your turf.  What do you think of the patch?  It has
been posted for various kernel versions, the newest patches are at
http://tech9.net/rml/linux

Obviously there is a theoretical risk, that is why it is configurable.
Is the need or the practical risk sufficient that the patch is useful?
I have gotten a lot of positive feedback.

If the patch were to be merged into the kernel, would you like anything
changed?  Would a /proc interface be useful (this would add overhead,
right now there is zero extra code after compile)?  What about changing
the entropy estimate to reflect the possible less entropy from net
devices?

Personally, I like the patch as is, but these have been issues raised.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Robert Love]

On 20 Aug 2001 12:47:56 +0200, Martin Dalecki wrote:
> The device get's powerd up at a random time for the attacker.
> That's entierly sufficient if you assume that your checksum function
> f(i) hat the property that there is no function g, where we have
> f(i+1)=g(f(i)), where g has a polynomial order over the time domain.
> i is unknown for the attacker.

isnt that the case?

also, its not even that g completes in polynomial time. its that g is
not algorithmic at all.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Robert Love]

On 20 Aug 2001 12:34:48 +0200, Johan Adolfsson wrote:
> And I think you are wrong, this patch is needed.
> Keep up the good work Robert!

I will -- thank you for the words. :)

> Where would you get the single seed from in an embedded head
> less system if you don't have a hardware random generator,
> no disk and don't seed it from the network interrupts?

exactly.  this thread has gone off on a tangent arguing the very merits
of /dev/random itself.  obviously if you dislike the kernel's entropy
gatherer, this patch won't sit well either.

the proper argument is, assuming that /dev/random is A Good Thing, is
this patch useful?  since its configurable, its not forcing any policy.
since it can be argued pretty strongly that more entropy is needed on a
headless and/or diskless, I think some people need it.  personally, it
boosts my self-esteem to have another source of entropy (my 3c905).  if
you are worried of the threats net devices have to your entropy, by all
means -- dont enable the config setting.

> I think the patch makes sense - let people have the config option.

hopefully we can get the patch merged, if for nothing else for 2.5.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Mike Touloumtzis]

On Sat, Aug 18, 2001 at 11:56:41PM -0400, Robert Love wrote:
> 
> Again, /dev/urandom is just as "secure" as /dev/random.  Its the same
> pool.  The same stuff.  Except that /dev/random blocks when the entropy
> count hits 0.

You have been repeating that there is no difference in security
between /dev/random and /dev/urandom, but consider this: you install
a kernel/hardware combination without any registered SA_SAMPLE_RANDOM
IRQs (i.e. headless, no IDE, no NICs with SA_SAMPLE_RANDOM IRQs).
This configuration is not hard to imagine for, say, a dedicated
server appliance or embedded device.

The entropy pool for such a system starts at 0s, unless I'm
misreading the source; from create_entropy_store():

        memset(r->pool, 0, poolwords*4);

As long as no interrupt ever adds randomness to this pool, I might be
able to predict every bit ever read from /dev/random on this machine.
I don't need to break SHA-1, I just run the algorithm forward from
its starting point.  I guess I would probably have to know the size
of each read, so in practice an active network (TCP initial sequence
numbers) in combination with other reads would make my job harder.
But it's still a scary scenario.  And it comes from the fact that
although /dev/urandom is a strong PRNG, it is still deterministic,
and if I know its complete state at any point and can simulate
subsequent events, I can predict its behavior.

/dev/random is very good for making sure you never generate a GPG
key on a machine like this.  I agree with most people on this thread
that session keys are usually safe coming from /dev/urandom.  But you
should still make sure you have at least one device feeding into
the entropy pool, something I'm sure many admins have no clue about
and don't verify.

miket

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Robert Love]

On Wed, 2001-08-22 at 02:10, Mike Touloumtzis wrote:
> You have been repeating that there is no difference in security
> between /dev/random and /dev/urandom, but consider this: you install
> a kernel/hardware combination without any registered SA_SAMPLE_RANDOM
> IRQs (i.e. headless, no IDE, no NICs with SA_SAMPLE_RANDOM IRQs).
> This configuration is not hard to imagine for, say, a dedicated
> server appliance or embedded device.
> 
> The entropy pool for such a system starts at 0s, unless I'm
> misreading the source; from create_entropy_store():
> 
>         memset(r->pool, 0, poolwords*4);

You are correct, it starts at zero.  Although, you are _supposed_ to
seed the pool with entropy from the previous session (save/restore
entropy on shutdown/boot).  All distributions I know do this correctly.
Obviously, however, this is not possible in your scenerio (no disks and
no entropy anyhow to save).

> As long as no interrupt ever adds randomness to this pool, I might be
> able to predict every bit ever read from /dev/random on this machine.
> I don't need to break SHA-1, I just run the algorithm forward from
> its starting point.  I guess I would probably have to know the size
> of each read, so in practice an active network (TCP initial sequence
> numbers) in combination with other reads would make my job harder.
> But it's still a scary scenario.  And it comes from the fact that
> although /dev/urandom is a strong PRNG, it is still deterministic,
> and if I know its complete state at any point and can simulate
> subsequent events, I can predict its behavior.

In this case, you are right.  Maybe I am unclear, I like /dev/random and
I like the entropy estimating algorithm.  There is just a lot of
confusion about how the entropy pool works and the differences between
/dev/random and /dev/urandom, and it is true that given that SHA-1 is
unbreakable /dev/random and /dev/urandom are alike in most respects.

In your situation, though, it is not ever safe to use the entropy pool
period, since no entropy is generated.  I am not sure if /dev/urandom
would even return.

The solution to this is easy: get something to generate entropy (like my
netdev patch! :) and save/restore the entropy seed.

> /dev/random is very good for making sure you never generate a GPG
> key on a machine like this.  I agree with most people on this thread
> that session keys are usually safe coming from /dev/urandom.  But you
> should still make sure you have at least one device feeding into
> the entropy pool, something I'm sure many admins have no clue about
> and don't verify.

Agreed.  Personally, I always just use /dev/random for stuff I feel
needs true security.  It is important that sysadmins know that something
is generating entropy.  Ideally, it comes from numerous places.  One of
those places can certainly be your network devices if you trust them.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Mike Touloumtzis]

On Wed, Aug 22, 2001 at 02:26:36AM -0400, Robert Love wrote:
> 
> The solution to this is easy: get something to generate entropy (like my
> netdev patch! :) and save/restore the entropy seed.

Agreed, I don't think the netdev patch is a bad idea, and it's
helpful in the case I described.  I was just getting worried
about the assertions (from various directions) that /dev/random
and /dev/urandom are practically indistinguishable unless you
can break SHA-1.  There's enough confusion out there as it is :-).

miket

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Alex Bligh - linux-kernel]

Mike,

>> Again, /dev/urandom is just as "secure" as /dev/random.  Its the same
>> pool.  The same stuff.  Except that /dev/random blocks when the entropy
>> count hits 0.
>
> You have been repeating that there is no difference in security
> between /dev/random and /dev/urandom, but consider this: you install
> a kernel/hardware combination without any registered SA_SAMPLE_RANDOM
> IRQs (i.e. headless, no IDE, no NICs with SA_SAMPLE_RANDOM IRQs).

(& no access to any block devices - but leave that for the time
being)

> The entropy pool for such a system starts at 0s, unless I'm
> misreading the source; from create_entropy_store():
>
>         memset(r->pool, 0, poolwords*4);
>
> As long as no interrupt ever adds randomness to this pool, I might be
> able to predict every bit ever read from /dev/random on this machine.

You would read precisely 0 bits from /dev/random, as it would
sit there blocking, with no entropy in the system.
You would be able to predict the bits from /dev/urandom.
Both pretty useless for generating useful random numbers,
but the blocking behaviour is probably safer.

This is the 'seeding' problem we refer to. After you've seeded
the random number generator (perhaps provide some entropy from
a file from the last boot), you wouldn't have this problem. And
/dev/urandom and /dev/random stay the same.

The suggestion of counting various events which are 'reasonably
unpredictable' but potentially observable, but not count them
as entropy, helps the seeding problem. Noone has argued that
using network IRQs to add randomness to the pool, but NOT count
as entropy, would be bad.

> /dev/random is very good for making sure you never generate a GPG
> key on a machine like this.  I agree with most people on this thread
> that session keys are usually safe coming from /dev/urandom.  But you
> should still make sure you have at least one device feeding into
> the entropy pool, something I'm sure many admins have no clue about
> and don't verify.

If they have none, they will know it very soon, as /dev/random will
block. It is currently hard to boot without accessing block devices,
however (and yes, on a duplicated machine, with embedded hardware
with predictable timing and no moving parts, this isn't much of
an entropy source either).

--
Alex Bligh

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Chris Friesen]

Mike Touloumtzis wrote:
 
> You have been repeating that there is no difference in security
> between /dev/random and /dev/urandom, but consider this: you install
> a kernel/hardware combination without any registered SA_SAMPLE_RANDOM
> IRQs (i.e. headless, no IDE, no NICs with SA_SAMPLE_RANDOM IRQs).
> This configuration is not hard to imagine for, say, a dedicated
> server appliance or embedded device.

So we then have two options, one of which is required if we are going to be able
to get any random numbers from this box:

1) if we contact some server to boot or to mount filesystems, we can also slurp
up some seed values from that server.
2) we enable all NIC drivers to collect entropy

In the case you describe, I don't see any other options.  Without one of these
paths, /dev/random will block, and /dev/urandom will be predictable.

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Alex Bligh - linux-kernel]

>> obviously some people fear NICs feeding entropy provides a hazard.  for
>> those who dont, or are increadibly low on entropy, enable the
>> configuration option.
>
> Why don't those who aren't worried about whether they _really_ have enough
> entropy simply use /dev/urandom?

This is not the issue; some of use _are_ worried whether or not we
have enough entropy (and want a read that blocks until sufficient
additional entropy arrives if entropy is insufficient), but don't have
sources of enough sources of entropy (e.g. on an idling machine where
everything is cached) if one does not allow network IRQ's to
generate entropy. In doing the latter, we do (admittedly) make
the assumption that they are valid sources of entropy (see discussion
past as to why this might or might not be the case), but using /dev/urandom
rather /dev/random will ALWAYS give a less random result in low entropy
situations.

IE I want to use the entropy calcs; I consider network IRQ spacing to be
sufficiently random and unobservable for them to be a valid source
of entropy, and (as the advantages doing so for various configs have
been widely documentated elsewhere) think that there should be a
config option (or /proc option) to support this. I do /not/ want to
ignore entropy calcs entirely (i.e. use /dev/urandom).

--
Alex Bligh

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Mike Castle]

On Sun, Aug 19, 2001 at 09:58:17PM +0100, Alex Bligh - linux-kernel wrote:
> This is not the issue; some of use _are_ worried whether or not we
> have enough entropy (and want a read that blocks until sufficient

If you are that worried, shouldn't you be using a hardware generator?

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Alex Bligh - linux-kernel]

Mike,

(off list - as I've posted this elsewhere)

>> This is not the issue; some of use _are_ worried whether or not we
>> have enough entropy (and want a read that blocks until sufficient
>
> If you are that worried, shouldn't you be using a hardware generator?

You could say the same thing to anyone who uses /dev/random
rather than /dev/urandom. Why use /dev/random when it can
block (inconvenient) instead of a h/w random number generator?

I'm sufficiently concerned that I want to have some 'external'
entropy, and on the machine in which it is causing me problems,
in an idle state, there is no other entropy source, but lots of
network activity which I trust can't be snooped on.

The machine was bought and tested in one config. A hardware
random number generator is something else to go wrong, and
additional expense.

Using an entropy estimate which includes network event timings
is no[1] worse (in this situation) than using (say) IDE interrupt
timings. And no better. It certainly isn't as good as using
an external random number generator. However, it is better
than using /dev/urandom and leaving the kernel unpatched
(see previous analysis). It's a trade-off. But if we can make
(depending on circumstance) the OS (s/w) perform better
with given h/w, that sounds like a good thing to do to me.

[1]=certainly not a lot worse.

--
Alex Bligh

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Mike Castle]

On Sun, Aug 19, 2001 at 11:29:51PM +0100, Alex Bligh - linux-kernel wrote:
> The machine was bought and tested in one config. A hardware
> random number generator is something else to go wrong, and
> additional expense.


And making a change to the kernel is not a different config?

I would argue that is just as dangerous as changing the hardware
configuration.

mrc
-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[Tom Rini]

On Sun, Aug 19, 2001 at 07:26:34PM -0700, Mike Castle wrote:
> On Sun, Aug 19, 2001 at 11:29:51PM +0100, Alex Bligh - linux-kernel wrote:
> > The machine was bought and tested in one config. A hardware
> > random number generator is something else to go wrong, and
> > additional expense.
> 
> And making a change to the kernel is not a different config?

In the very strict QA'ing sense, yes.  Any sort of change whatsoever is a
different config and throws out all of the other testing results.  Which
still leaves the cost argument in this case.  But, there are degrees of
how dangerous a change can be.  From my quick skimming of this code, it
looks like the only changes are to mark network irq bits as possible entropy.
Nothing more.  I could be totally wrong of course. :)
Therefore, it's quite probable anyhow that this config won't have any more
problems that the other config had.  Of course the only way to prove this
is much QA'ing.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/