[PATCH] Optionally let Net Devices feed Entropy

[PATCH] Optionally let Net Devices feed Entropy

[Robert Love]

(patches will be attached in subsequent emails.  there is a set for
2.4.9-pre4 and another for 2.4.8-ac5.  Patch #1 includes the core code
changes, configure changes, etc.  Patch #2 includes some updated network
drivers).

Its a long standing debate whether to allow network drivers to
contribute to the kernel entropy pool.  This e-mail is not to convince
anyone of anything, but give users a choice.

Right now, a very small number of network devices add to /dev/random.
The majority of them don't, presumably because of the fear of an
external attacker manipulating the kernel entropy pool.

The following patches allow the user to configure at compile-time
whether or not network devices should be allowed to feed the pool.  For
those of us who don't fear external attackers, this is a nice addition
of entropy.  It is also useful for those who are on a headless system
and need some more sources of entropy.

A new configure statement is available in Network Devices.  Enabling it
enables CONFIG_NET_RANDOM which sets a new request_irq flag,
SA_SAMPLE_RANDOM_NET.  If enabled, that flag is defined as
SA_SAMPLE_RANDOM.  If disabled, the flag is defined as 0.  Thus there is
no additional code after compile.

The idea, then, should be to add SA_SAMPLE_RANDOM_NET to each network
devices request_irq call.

Patch #2 does this for some devices: 3c501, 3c505, 3c509, 3c523, 3c59x,
8139too, cs89x0, eepro, eepro100, eexpress, ibmlana, ne2k-pci, pcnet_cs,
xircom_tulic_cb, sk_mca, smc9194, tulic_core, and wavelan.  All of the
devices which already contribute entropy have been updated.

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

[PATCH] 2.4.9-pre4: Optionally let Net Devices feed Entropy (1/2)

[Robert Love]

against 2.4.9-pre4, patch #1 of 2 (required: adds the new define
for all architectures, configure support, etc.) see previous email.

diff -urN linux-2.4.9-pre4/Documentation/Configure.help linux/Documentation/Configure.help
--- linux-2.4.9-pre4/Documentation/Configure.help	Wed Aug 15 23:12:28 2001
+++ linux/Documentation/Configure.help	Wed Aug 15 23:19:52 2001
@@ -7728,6 +7728,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.9-pre4/drivers/net/Config.in linux/drivers/net/Config.in
--- linux-2.4.9-pre4/drivers/net/Config.in	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/Config.in	Wed Aug 15 23:19:52 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.9-pre4/include/asm-alpha/signal.h linux/include/asm-alpha/signal.h
--- linux-2.4.9-pre4/include/asm-alpha/signal.h	Wed Aug 15 23:09:20 2001
+++ linux/include/asm-alpha/signal.h	Wed Aug 15 23:19:52 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.9-pre4/include/asm-arm/signal.h linux/include/asm-arm/signal.h
--- linux-2.4.9-pre4/include/asm-arm/signal.h	Wed Aug 15 23:09:28 2001
+++ linux/include/asm-arm/signal.h	Wed Aug 15 23:19:52 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.9-pre4/include/asm-cris/signal.h linux/include/asm-cris/signal.h
--- linux-2.4.9-pre4/include/asm-cris/signal.h	Wed Aug 15 23:09:37 2001
+++ linux/include/asm-cris/signal.h	Wed Aug 15 23:19:52 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.9-pre4/include/asm-i386/signal.h linux/include/asm-i386/signal.h
--- linux-2.4.9-pre4/include/asm-i386/signal.h	Wed Aug 15 23:09:17 2001
+++ linux/include/asm-i386/signal.h	Wed Aug 15 23:19:52 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.9-pre4/include/asm-ia64/signal.h linux/include/asm-ia64/signal.h
--- linux-2.4.9-pre4/include/asm-ia64/signal.h	Wed Aug 15 23:09:36 2001
+++ linux/include/asm-ia64/signal.h	Wed Aug 15 23:19:52 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.9-pre4/include/asm-m68k/signal.h linux/include/asm-m68k/signal.h
--- linux-2.4.9-pre4/include/asm-m68k/signal.h	Wed Aug 15 23:09:21 2001
+++ linux/include/asm-m68k/signal.h	Wed Aug 15 23:19:52 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.9-pre4/include/asm-mips/signal.h linux/include/asm-mips/signal.h
--- linux-2.4.9-pre4/include/asm-mips/signal.h	Wed Aug 15 23:09:18 2001
+++ linux/include/asm-mips/signal.h	Wed Aug 15 23:19:52 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.9-pre4/include/asm-mips64/signal.h linux/include/asm-mips64/signal.h
--- linux-2.4.9-pre4/include/asm-mips64/signal.h	Wed Aug 15 23:09:37 2001
+++ linux/include/asm-mips64/signal.h	Wed Aug 15 23:19:53 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.9-pre4/include/asm-parisc/signal.h linux/include/asm-parisc/signal.h
--- linux-2.4.9-pre4/include/asm-parisc/signal.h	Wed Aug 15 23:09:37 2001
+++ linux/include/asm-parisc/signal.h	Wed Aug 15 23:19:53 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.9-pre4/include/asm-ppc/signal.h linux/include/asm-ppc/signal.h
--- linux-2.4.9-pre4/include/asm-ppc/signal.h	Wed Aug 15 23:09:25 2001
+++ linux/include/asm-ppc/signal.h	Wed Aug 15 23:19:53 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.9-pre4/include/asm-s390/signal.h linux/include/asm-s390/signal.h
--- linux-2.4.9-pre4/include/asm-s390/signal.h	Wed Aug 15 23:09:37 2001
+++ linux/include/asm-s390/signal.h	Wed Aug 15 23:20:04 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.9-pre4/include/asm-s390x/signal.h linux/include/asm-s390x/signal.h
--- linux-2.4.9-pre4/include/asm-s390x/signal.h	Wed Aug 15 23:09:37 2001
+++ linux/include/asm-s390x/signal.h	Wed Aug 15 23:20:04 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.9-pre4/include/asm-sh/signal.h linux/include/asm-sh/signal.h
--- linux-2.4.9-pre4/include/asm-sh/signal.h	Wed Aug 15 23:09:29 2001
+++ linux/include/asm-sh/signal.h	Wed Aug 15 23:20:04 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.9-pre4/include/asm-sparc/signal.h linux/include/asm-sparc/signal.h
--- linux-2.4.9-pre4/include/asm-sparc/signal.h	Wed Aug 15 23:09:23 2001
+++ linux/include/asm-sparc/signal.h	Wed Aug 15 23:20:04 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.9-pre4/include/asm-sparc64/signal.h linux/include/asm-sparc64/signal.h
--- linux-2.4.9-pre4/include/asm-sparc64/signal.h	Wed Aug 15 23:09:27 2001
+++ linux/include/asm-sparc64/signal.h	Wed Aug 15 23:20:04 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 *);

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

[PATCH] 2.4.9-pre4: Optionally let Net Devices feed Entropy (2/2)

[Robert Love]

against 2.4.9-pre4.  patch 2 of 2 (updates some drivers to use new
optional random support). see previous email.


diff -urN linux-2.4.9-pre4/drivers/net/3c501.c linux/drivers/net/3c501.c
--- linux-2.4.9-pre4/drivers/net/3c501.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/3c501.c	Wed Aug 15 23:20:07 2001
@@ -410,7 +410,8 @@
 	if (el_debug > 2)
 		printk("%s: Doing el_open()...", dev->name);
 
-	if ((retval = request_irq(dev->irq, &el_interrupt, 0, dev->name, dev)))
+	if ((retval = request_irq(dev->irq, &el_interrupt,
+				SA_SAMPLE_NET_RANDOM, dev->name, dev)))
 		return retval;
 
 	spin_lock_irqsave(&lp->lock, flags);
diff -urN linux-2.4.9-pre4/drivers/net/3c505.c linux/drivers/net/3c505.c
--- linux-2.4.9-pre4/drivers/net/3c505.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/3c505.c	Wed Aug 15 23:20:07 2001
@@ -897,7 +897,8 @@
 	/*
 	 * install our interrupt service routine
 	 */
-	if ((retval = request_irq(dev->irq, &elp_interrupt, 0, dev->name, dev))) {
+	if ((retval = request_irq(dev->irq, &elp_interrupt,
+					SA_SAMPLE_NET_RANDOM, dev->name, dev))) {
 		printk(KERN_ERR "%s: could not allocate IRQ%d\n", dev->name, dev->irq);
 		return retval;
 	}
diff -urN linux-2.4.9-pre4/drivers/net/3c509.c linux/drivers/net/3c509.c
--- linux-2.4.9-pre4/drivers/net/3c509.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/3c509.c	Wed Aug 15 23:20:08 2001
@@ -560,7 +560,8 @@
 	outw(RxReset, ioaddr + EL3_CMD);
 	outw(SetStatusEnb | 0x00, ioaddr + EL3_CMD);
 
-	i = request_irq(dev->irq, &el3_interrupt, 0, dev->name, dev);
+	i = request_irq(dev->irq, &el3_interrupt,
+			SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (i) return i;
 
 	EL3WINDOW(0);
diff -urN linux-2.4.9-pre4/drivers/net/3c523.c linux/drivers/net/3c523.c
--- linux-2.4.9-pre4/drivers/net/3c523.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/3c523.c	Wed Aug 15 23:20:08 2001
@@ -280,7 +280,7 @@
 
 	elmc_id_attn586();	/* disable interrupts */
 
-	ret = request_irq(dev->irq, &elmc_interrupt, SA_SHIRQ | SA_SAMPLE_RANDOM,
+	ret = request_irq(dev->irq, &elmc_interrupt, SA_SHIRQ | SA_SAMPLE_NET_RANDOM,
 			  dev->name, dev);
 	if (ret) {
 		printk(KERN_ERR "%s: couldn't get irq %d\n", dev->name, dev->irq);
diff -urN linux-2.4.9-pre4/drivers/net/3c59x.c linux/drivers/net/3c59x.c
--- linux-2.4.9-pre4/drivers/net/3c59x.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/3c59x.c	Wed Aug 15 23:20:08 2001
@@ -1581,7 +1581,7 @@
 
 	/* Use the now-standard shared IRQ implementation. */
 	if ((retval = request_irq(dev->irq, vp->full_bus_master_rx ?
-				&boomerang_interrupt : &vortex_interrupt, SA_SHIRQ, dev->name, dev))) {
+				&boomerang_interrupt : &vortex_interrupt, SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev))) {
 		printk(KERN_ERR "%s: Could not reserve IRQ %d\n", dev->name, dev->irq);
 		goto out;
 	}
diff -urN linux-2.4.9-pre4/drivers/net/8139too.c linux/drivers/net/8139too.c
--- linux-2.4.9-pre4/drivers/net/8139too.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/8139too.c	Wed Aug 15 23:20:08 2001
@@ -1289,7 +1289,8 @@
 
 	DPRINTK ("ENTER\n");
 
-	retval = request_irq (dev->irq, rtl8139_interrupt, SA_SHIRQ, dev->name, dev);
+	retval = request_irq (dev->irq, rtl8139_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (retval) {
 		DPRINTK ("EXIT, returning %d\n", retval);
 		return retval;
diff -urN linux-2.4.9-pre4/drivers/net/cs89x0.c linux/drivers/net/cs89x0.c
--- linux-2.4.9-pre4/drivers/net/cs89x0.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/cs89x0.c	Wed Aug 15 23:20:08 2001
@@ -1057,7 +1057,7 @@
 
 		for (i = 2; i < CS8920_NO_INTS; i++) {
 			if ((1 << dev->irq) & lp->irq_map) {
-				if (request_irq(i, net_interrupt, 0, dev->name, dev) == 0) {
+				if (request_irq(i, net_interrupt, SA_SAMPLE_NET_RANDOM, dev->name, dev) == 0) {
 					dev->irq = i;
 					write_irq(dev, lp->chip_type, i);
 					/* writereg(dev, PP_BufCFG, GENERATE_SW_INTERRUPT); */
diff -urN linux-2.4.9-pre4/drivers/net/eepro.c linux/drivers/net/eepro.c
--- linux-2.4.9-pre4/drivers/net/eepro.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/eepro.c	Wed Aug 15 23:20:08 2001
@@ -944,7 +944,8 @@
 		return -EAGAIN;
 	}
 		
-	if (request_irq(dev->irq , &eepro_interrupt, 0, dev->name, dev)) {
+	if (request_irq(dev->irq , &eepro_interrupt, SA_SAMPLE_NET_RANDOM,
+				dev->name, dev)) {
 		printk("%s: unable to get IRQ %d.\n", dev->name, dev->irq);
 		return -EAGAIN;
 	}
diff -urN linux-2.4.9-pre4/drivers/net/eepro100.c linux/drivers/net/eepro100.c
--- linux-2.4.9-pre4/drivers/net/eepro100.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/eepro100.c	Wed Aug 15 23:20:08 2001
@@ -932,7 +932,8 @@
 	sp->in_interrupt = 0;
 
 	/* .. we can safely take handler calls during init. */
-	retval = request_irq(dev->irq, &speedo_interrupt, SA_SHIRQ, dev->name, dev);
+	retval = request_irq(dev->irq, &speedo_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (retval) {
 		MOD_DEC_USE_COUNT;
 		return retval;
diff -urN linux-2.4.9-pre4/drivers/net/eexpress.c linux/drivers/net/eexpress.c
--- linux-2.4.9-pre4/drivers/net/eexpress.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/eexpress.c	Wed Aug 15 23:20:08 2001
@@ -433,7 +433,8 @@
 	if (!dev->irq || !irqrmap[dev->irq])
 		return -ENXIO;
 
-	ret = request_irq(dev->irq,&eexp_irq,0,dev->name,dev);
+	ret = request_irq(dev->irq,&eexp_irq,SA_SAMPLE_NET_RANDOM,
+			dev->name,dev);
 	if (ret) return ret;
 
 	request_region(ioaddr, EEXP_IO_EXTENT, "EtherExpress");
diff -urN linux-2.4.9-pre4/drivers/net/ibmlana.c linux/drivers/net/ibmlana.c
--- linux-2.4.9-pre4/drivers/net/ibmlana.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/ibmlana.c	Wed Aug 15 23:20:08 2001
@@ -856,7 +856,7 @@
 
 	result =
 	    request_irq(priv->realirq, irq_handler,
-			SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (result != 0) {
 		printk("%s: failed to register irq %d\n", dev->name,
 		       dev->irq);
diff -urN linux-2.4.9-pre4/drivers/net/ne2k-pci.c linux/drivers/net/ne2k-pci.c
--- linux-2.4.9-pre4/drivers/net/ne2k-pci.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/ne2k-pci.c	Wed Aug 15 23:20:08 2001
@@ -387,7 +387,8 @@
 
 static int ne2k_pci_open(struct net_device *dev)
 {
-	int ret = request_irq(dev->irq, ei_interrupt, SA_SHIRQ, dev->name, dev);
+	int ret = request_irq(dev->irq, ei_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (ret)
 		return ret;
 
diff -urN linux-2.4.9-pre4/drivers/net/pcmcia/pcnet_cs.c linux/drivers/net/pcmcia/pcnet_cs.c
--- linux-2.4.9-pre4/drivers/net/pcmcia/pcnet_cs.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/pcmcia/pcnet_cs.c	Wed Aug 15 23:20:08 2001
@@ -977,7 +977,7 @@
     MOD_INC_USE_COUNT;
 
     set_misc_reg(dev);
-    request_irq(dev->irq, ei_irq_wrapper, SA_SHIRQ, dev_info, dev);
+    request_irq(dev->irq, ei_irq_wrapper, SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev_info, dev);
 
     info->link_status = 0x00;
     info->watchdog.function = &ei_watchdog;
diff -urN linux-2.4.9-pre4/drivers/net/pcmcia/xircom_tulip_cb.c linux/drivers/net/pcmcia/xircom_tulip_cb.c
--- linux-2.4.9-pre4/drivers/net/pcmcia/xircom_tulip_cb.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/pcmcia/xircom_tulip_cb.c	Wed Aug 15 23:20:25 2001
@@ -768,7 +768,8 @@
 {
 	struct tulip_private *tp = (struct tulip_private *)dev->priv;
 
-	if (request_irq(dev->irq, &tulip_interrupt, SA_SHIRQ, dev->name, dev))
+	if (request_irq(dev->irq, &tulip_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev))
 		return -EAGAIN;
 
 	tulip_init_ring(dev);
diff -urN linux-2.4.9-pre4/drivers/net/sk_mca.c linux/drivers/net/sk_mca.c
--- linux-2.4.9-pre4/drivers/net/sk_mca.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/sk_mca.c	Wed Aug 15 23:20:25 2001
@@ -861,7 +861,7 @@
 	/* register resources - only necessary for IRQ */
 	result =
 	    request_irq(priv->realirq, irq_handler,
-			SA_SHIRQ | SA_SAMPLE_RANDOM, "sk_mca", dev);
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, "sk_mca", dev);
 	if (result != 0) {
 		printk("%s: failed to register irq %d\n", dev->name,
 		       dev->irq);
diff -urN linux-2.4.9-pre4/drivers/net/smc9194.c linux/drivers/net/smc9194.c
--- linux-2.4.9-pre4/drivers/net/smc9194.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/smc9194.c	Wed Aug 15 23:20:25 2001
@@ -1019,7 +1019,7 @@
 	ether_setup(dev);
 
 	/* Grab the IRQ */
-      	retval = request_irq(dev->irq, &smc_interrupt, 0, dev->name, dev);
+      	retval = request_irq(dev->irq, &smc_interrupt, SA_SAMPLE_NET_RANDOM, dev->name, dev);
       	if (retval) {
 		printk("%s: unable to get IRQ %d (irqval=%d).\n", dev->name,
 			dev->irq, retval);
diff -urN linux-2.4.9-pre4/drivers/net/tulip/tulip_core.c linux/drivers/net/tulip/tulip_core.c
--- linux-2.4.9-pre4/drivers/net/tulip/tulip_core.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/tulip/tulip_core.c	Wed Aug 15 23:20:25 2001
@@ -504,7 +504,9 @@
 	int retval;
 	MOD_INC_USE_COUNT;
 
-	if ((retval = request_irq(dev->irq, &tulip_interrupt, SA_SHIRQ, dev->name, dev))) {
+	if ((retval = request_irq(dev->irq, &tulip_interrupt,
+					SA_SHIRQ | SA_SAMPLE_NET_RANDOM,
+					dev->name, dev))) {
 		MOD_DEC_USE_COUNT;
 		return retval;
 	}
diff -urN linux-2.4.9-pre4/drivers/net/wavelan.c linux/drivers/net/wavelan.c
--- linux-2.4.9-pre4/drivers/net/wavelan.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/wavelan.c	Wed Aug 15 23:20:25 2001
@@ -3897,7 +3897,8 @@
 		return -ENXIO;
 	}
 
-	if (request_irq(dev->irq, &wavelan_interrupt, 0, "WaveLAN", dev) != 0) 
+	if (request_irq(dev->irq, &wavelan_interrupt, SA_SAMPLE_NET_RANDOM,
+				"WaveLAN", dev) != 0) 
 	{
 #ifdef DEBUG_CONFIG_ERROR
 		printk(KERN_WARNING "%s: wavelan_open(): invalid IRQ\n",



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

[PATCH] 2.4.8-ac5: let Net Devices feed Entropy (1/2)

[Robert Love]

against 2.4.8-ac5.  patch #1 of 2 (required: adds the new define
for all architectures, configure support, etc.) see previous email.


diff -urN linux-2.4.8-ac5/Documentation/Configure.help linux/Documentation/Configure.help
--- linux-2.4.8-ac5/Documentation/Configure.help	Wed Aug 15 19:05:29 2001
+++ linux/Documentation/Configure.help	Wed Aug 15 19:10:01 2001
@@ -8594,6 +8594,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-ac5/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-ac5/include/asm-alpha/signal.h linux/include/asm-alpha/signal.h
--- linux-2.4.8-ac5/include/asm-alpha/signal.h	Wed Jun 24 17:30:11 1998
+++ linux/include/asm-alpha/signal.h	Wed Aug 15 18:12:10 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-ac5/include/asm-arm/signal.h linux/include/asm-arm/signal.h
--- linux-2.4.8-ac5/include/asm-arm/signal.h	Thu Nov 18 22:37:03 1999
+++ linux/include/asm-arm/signal.h	Wed Aug 15 18:12:29 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-ac5/include/asm-cris/signal.h linux/include/asm-cris/signal.h
--- linux-2.4.8-ac5/include/asm-cris/signal.h	Thu Feb  8 19:32:44 2001
+++ linux/include/asm-cris/signal.h	Wed Aug 15 18:12:40 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-ac5/include/asm-i386/signal.h linux/include/asm-i386/signal.h
--- linux-2.4.8-ac5/include/asm-i386/signal.h	Fri Aug 10 21:13:47 2001
+++ linux/include/asm-i386/signal.h	Wed Aug 15 19:02:11 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-ac5/include/asm-ia64/signal.h linux/include/asm-ia64/signal.h
--- linux-2.4.8-ac5/include/asm-ia64/signal.h	Tue Jul 31 13:30:09 2001
+++ linux/include/asm-ia64/signal.h	Wed Aug 15 18:13:06 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-ac5/include/asm-m68k/signal.h linux/include/asm-m68k/signal.h
--- linux-2.4.8-ac5/include/asm-m68k/signal.h	Thu Nov 18 22:37:03 1999
+++ linux/include/asm-m68k/signal.h	Wed Aug 15 18:13:16 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-ac5/include/asm-mips/signal.h linux/include/asm-mips/signal.h
--- linux-2.4.8-ac5/include/asm-mips/signal.h	Mon Jul 10 01:18:15 2000
+++ linux/include/asm-mips/signal.h	Wed Aug 15 18:13:28 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-ac5/include/asm-mips64/signal.h linux/include/asm-mips64/signal.h
--- linux-2.4.8-ac5/include/asm-mips64/signal.h	Sat May 13 11:31:25 2000
+++ linux/include/asm-mips64/signal.h	Wed Aug 15 18:13:43 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-ac5/include/asm-parisc/signal.h linux/include/asm-parisc/signal.h
--- linux-2.4.8-ac5/include/asm-parisc/signal.h	Tue Dec  5 15:29:39 2000
+++ linux/include/asm-parisc/signal.h	Wed Aug 15 18:13:53 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-ac5/include/asm-ppc/signal.h linux/include/asm-ppc/signal.h
--- linux-2.4.8-ac5/include/asm-ppc/signal.h	Mon May 21 18:02:06 2001
+++ linux/include/asm-ppc/signal.h	Wed Aug 15 18:14:02 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-ac5/include/asm-ppc64/signal.h linux/include/asm-ppc64/signal.h
--- linux-2.4.8-ac5/include/asm-ppc64/signal.h	Wed Aug 15 19:05:43 2001
+++ linux/include/asm-ppc64/signal.h	Wed Aug 15 18:14:14 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-ac5/include/asm-s390/signal.h linux/include/asm-s390/signal.h
--- linux-2.4.8-ac5/include/asm-s390/signal.h	Wed Apr 11 22:02:28 2001
+++ linux/include/asm-s390/signal.h	Wed Aug 15 18:14:25 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-ac5/include/asm-s390x/signal.h linux/include/asm-s390x/signal.h
--- linux-2.4.8-ac5/include/asm-s390x/signal.h	Wed Jul 25 17:12:02 2001
+++ linux/include/asm-s390x/signal.h	Wed Aug 15 18:14:32 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-ac5/include/asm-sh/signal.h linux/include/asm-sh/signal.h
--- linux-2.4.8-ac5/include/asm-sh/signal.h	Thu Nov 18 22:37:03 1999
+++ linux/include/asm-sh/signal.h	Wed Aug 15 18:14:43 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-ac5/include/asm-sparc/signal.h linux/include/asm-sparc/signal.h
--- linux-2.4.8-ac5/include/asm-sparc/signal.h	Wed Sep  8 14:14:32 1999
+++ linux/include/asm-sparc/signal.h	Wed Aug 15 18:14:52 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-ac5/include/asm-sparc64/signal.h linux/include/asm-sparc64/signal.h
--- linux-2.4.8-ac5/include/asm-sparc64/signal.h	Wed Sep  8 14:14:32 1999
+++ linux/include/asm-sparc64/signal.h	Wed Aug 15 18:15:02 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 *);


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

[PATCH] 2.4.8-ac5: let Net Devices feed Entropy (2/2)

[Robert Love]

against 2.4.8-ac5. patch #2 of 2 (updates some drivers to use new
optional random support). see previous email


diff -urN linux-2.4.9-pre4/drivers/net/3c501.c linux/drivers/net/3c501.c
--- linux-2.4.9-pre4/drivers/net/3c501.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/3c501.c	Wed Aug 15 23:20:07 2001
@@ -410,7 +410,8 @@
 	if (el_debug > 2)
 		printk("%s: Doing el_open()...", dev->name);
 
-	if ((retval = request_irq(dev->irq, &el_interrupt, 0, dev->name, dev)))
+	if ((retval = request_irq(dev->irq, &el_interrupt,
+				SA_SAMPLE_NET_RANDOM, dev->name, dev)))
 		return retval;
 
 	spin_lock_irqsave(&lp->lock, flags);
diff -urN linux-2.4.9-pre4/drivers/net/3c505.c linux/drivers/net/3c505.c
--- linux-2.4.9-pre4/drivers/net/3c505.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/3c505.c	Wed Aug 15 23:20:07 2001
@@ -897,7 +897,8 @@
 	/*
 	 * install our interrupt service routine
 	 */
-	if ((retval = request_irq(dev->irq, &elp_interrupt, 0, dev->name, dev))) {
+	if ((retval = request_irq(dev->irq, &elp_interrupt,
+					SA_SAMPLE_NET_RANDOM, dev->name, dev))) {
 		printk(KERN_ERR "%s: could not allocate IRQ%d\n", dev->name, dev->irq);
 		return retval;
 	}
diff -urN linux-2.4.9-pre4/drivers/net/3c509.c linux/drivers/net/3c509.c
--- linux-2.4.9-pre4/drivers/net/3c509.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/3c509.c	Wed Aug 15 23:20:08 2001
@@ -560,7 +560,8 @@
 	outw(RxReset, ioaddr + EL3_CMD);
 	outw(SetStatusEnb | 0x00, ioaddr + EL3_CMD);
 
-	i = request_irq(dev->irq, &el3_interrupt, 0, dev->name, dev);
+	i = request_irq(dev->irq, &el3_interrupt,
+			SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (i) return i;
 
 	EL3WINDOW(0);
diff -urN linux-2.4.9-pre4/drivers/net/3c523.c linux/drivers/net/3c523.c
--- linux-2.4.9-pre4/drivers/net/3c523.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/3c523.c	Wed Aug 15 23:20:08 2001
@@ -280,7 +280,7 @@
 
 	elmc_id_attn586();	/* disable interrupts */
 
-	ret = request_irq(dev->irq, &elmc_interrupt, SA_SHIRQ | SA_SAMPLE_RANDOM,
+	ret = request_irq(dev->irq, &elmc_interrupt, SA_SHIRQ | SA_SAMPLE_NET_RANDOM,
 			  dev->name, dev);
 	if (ret) {
 		printk(KERN_ERR "%s: couldn't get irq %d\n", dev->name, dev->irq);
diff -urN linux-2.4.9-pre4/drivers/net/3c59x.c linux/drivers/net/3c59x.c
--- linux-2.4.9-pre4/drivers/net/3c59x.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/3c59x.c	Wed Aug 15 23:20:08 2001
@@ -1581,7 +1581,7 @@
 
 	/* Use the now-standard shared IRQ implementation. */
 	if ((retval = request_irq(dev->irq, vp->full_bus_master_rx ?
-				&boomerang_interrupt : &vortex_interrupt, SA_SHIRQ, dev->name, dev))) {
+				&boomerang_interrupt : &vortex_interrupt, SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev))) {
 		printk(KERN_ERR "%s: Could not reserve IRQ %d\n", dev->name, dev->irq);
 		goto out;
 	}
diff -urN linux-2.4.9-pre4/drivers/net/8139too.c linux/drivers/net/8139too.c
--- linux-2.4.9-pre4/drivers/net/8139too.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/8139too.c	Wed Aug 15 23:20:08 2001
@@ -1289,7 +1289,8 @@
 
 	DPRINTK ("ENTER\n");
 
-	retval = request_irq (dev->irq, rtl8139_interrupt, SA_SHIRQ, dev->name, dev);
+	retval = request_irq (dev->irq, rtl8139_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (retval) {
 		DPRINTK ("EXIT, returning %d\n", retval);
 		return retval;
diff -urN linux-2.4.9-pre4/drivers/net/cs89x0.c linux/drivers/net/cs89x0.c
--- linux-2.4.9-pre4/drivers/net/cs89x0.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/cs89x0.c	Wed Aug 15 23:20:08 2001
@@ -1057,7 +1057,7 @@
 
 		for (i = 2; i < CS8920_NO_INTS; i++) {
 			if ((1 << dev->irq) & lp->irq_map) {
-				if (request_irq(i, net_interrupt, 0, dev->name, dev) == 0) {
+				if (request_irq(i, net_interrupt, SA_SAMPLE_NET_RANDOM, dev->name, dev) == 0) {
 					dev->irq = i;
 					write_irq(dev, lp->chip_type, i);
 					/* writereg(dev, PP_BufCFG, GENERATE_SW_INTERRUPT); */
diff -urN linux-2.4.9-pre4/drivers/net/eepro.c linux/drivers/net/eepro.c
--- linux-2.4.9-pre4/drivers/net/eepro.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/eepro.c	Wed Aug 15 23:20:08 2001
@@ -944,7 +944,8 @@
 		return -EAGAIN;
 	}
 		
-	if (request_irq(dev->irq , &eepro_interrupt, 0, dev->name, dev)) {
+	if (request_irq(dev->irq , &eepro_interrupt, SA_SAMPLE_NET_RANDOM,
+				dev->name, dev)) {
 		printk("%s: unable to get IRQ %d.\n", dev->name, dev->irq);
 		return -EAGAIN;
 	}
diff -urN linux-2.4.9-pre4/drivers/net/eepro100.c linux/drivers/net/eepro100.c
--- linux-2.4.9-pre4/drivers/net/eepro100.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/eepro100.c	Wed Aug 15 23:20:08 2001
@@ -932,7 +932,8 @@
 	sp->in_interrupt = 0;
 
 	/* .. we can safely take handler calls during init. */
-	retval = request_irq(dev->irq, &speedo_interrupt, SA_SHIRQ, dev->name, dev);
+	retval = request_irq(dev->irq, &speedo_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (retval) {
 		MOD_DEC_USE_COUNT;
 		return retval;
diff -urN linux-2.4.9-pre4/drivers/net/eexpress.c linux/drivers/net/eexpress.c
--- linux-2.4.9-pre4/drivers/net/eexpress.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/eexpress.c	Wed Aug 15 23:20:08 2001
@@ -433,7 +433,8 @@
 	if (!dev->irq || !irqrmap[dev->irq])
 		return -ENXIO;
 
-	ret = request_irq(dev->irq,&eexp_irq,0,dev->name,dev);
+	ret = request_irq(dev->irq,&eexp_irq,SA_SAMPLE_NET_RANDOM,
+			dev->name,dev);
 	if (ret) return ret;
 
 	request_region(ioaddr, EEXP_IO_EXTENT, "EtherExpress");
diff -urN linux-2.4.9-pre4/drivers/net/ibmlana.c linux/drivers/net/ibmlana.c
--- linux-2.4.9-pre4/drivers/net/ibmlana.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/ibmlana.c	Wed Aug 15 23:20:08 2001
@@ -856,7 +856,7 @@
 
 	result =
 	    request_irq(priv->realirq, irq_handler,
-			SA_SHIRQ | SA_SAMPLE_RANDOM, dev->name, dev);
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (result != 0) {
 		printk("%s: failed to register irq %d\n", dev->name,
 		       dev->irq);
diff -urN linux-2.4.9-pre4/drivers/net/ne2k-pci.c linux/drivers/net/ne2k-pci.c
--- linux-2.4.9-pre4/drivers/net/ne2k-pci.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/ne2k-pci.c	Wed Aug 15 23:20:08 2001
@@ -387,7 +387,8 @@
 
 static int ne2k_pci_open(struct net_device *dev)
 {
-	int ret = request_irq(dev->irq, ei_interrupt, SA_SHIRQ, dev->name, dev);
+	int ret = request_irq(dev->irq, ei_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev);
 	if (ret)
 		return ret;
 
diff -urN linux-2.4.9-pre4/drivers/net/pcmcia/pcnet_cs.c linux/drivers/net/pcmcia/pcnet_cs.c
--- linux-2.4.9-pre4/drivers/net/pcmcia/pcnet_cs.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/pcmcia/pcnet_cs.c	Wed Aug 15 23:20:08 2001
@@ -977,7 +977,7 @@
     MOD_INC_USE_COUNT;
 
     set_misc_reg(dev);
-    request_irq(dev->irq, ei_irq_wrapper, SA_SHIRQ, dev_info, dev);
+    request_irq(dev->irq, ei_irq_wrapper, SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev_info, dev);
 
     info->link_status = 0x00;
     info->watchdog.function = &ei_watchdog;
diff -urN linux-2.4.9-pre4/drivers/net/pcmcia/xircom_tulip_cb.c linux/drivers/net/pcmcia/xircom_tulip_cb.c
--- linux-2.4.9-pre4/drivers/net/pcmcia/xircom_tulip_cb.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/pcmcia/xircom_tulip_cb.c	Wed Aug 15 23:20:25 2001
@@ -768,7 +768,8 @@
 {
 	struct tulip_private *tp = (struct tulip_private *)dev->priv;
 
-	if (request_irq(dev->irq, &tulip_interrupt, SA_SHIRQ, dev->name, dev))
+	if (request_irq(dev->irq, &tulip_interrupt,
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, dev->name, dev))
 		return -EAGAIN;
 
 	tulip_init_ring(dev);
diff -urN linux-2.4.9-pre4/drivers/net/sk_mca.c linux/drivers/net/sk_mca.c
--- linux-2.4.9-pre4/drivers/net/sk_mca.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/sk_mca.c	Wed Aug 15 23:20:25 2001
@@ -861,7 +861,7 @@
 	/* register resources - only necessary for IRQ */
 	result =
 	    request_irq(priv->realirq, irq_handler,
-			SA_SHIRQ | SA_SAMPLE_RANDOM, "sk_mca", dev);
+			SA_SHIRQ | SA_SAMPLE_NET_RANDOM, "sk_mca", dev);
 	if (result != 0) {
 		printk("%s: failed to register irq %d\n", dev->name,
 		       dev->irq);
diff -urN linux-2.4.9-pre4/drivers/net/smc9194.c linux/drivers/net/smc9194.c
--- linux-2.4.9-pre4/drivers/net/smc9194.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/smc9194.c	Wed Aug 15 23:20:25 2001
@@ -1019,7 +1019,7 @@
 	ether_setup(dev);
 
 	/* Grab the IRQ */
-      	retval = request_irq(dev->irq, &smc_interrupt, 0, dev->name, dev);
+      	retval = request_irq(dev->irq, &smc_interrupt, SA_SAMPLE_NET_RANDOM, dev->name, dev);
       	if (retval) {
 		printk("%s: unable to get IRQ %d (irqval=%d).\n", dev->name,
 			dev->irq, retval);
diff -urN linux-2.4.9-pre4/drivers/net/tulip/tulip_core.c linux/drivers/net/tulip/tulip_core.c
--- linux-2.4.9-pre4/drivers/net/tulip/tulip_core.c	Wed Aug 15 23:09:40 2001
+++ linux/drivers/net/tulip/tulip_core.c	Wed Aug 15 23:20:25 2001
@@ -504,7 +504,9 @@
 	int retval;
 	MOD_INC_USE_COUNT;
 
-	if ((retval = request_irq(dev->irq, &tulip_interrupt, SA_SHIRQ, dev->name, dev))) {
+	if ((retval = request_irq(dev->irq, &tulip_interrupt,
+					SA_SHIRQ | SA_SAMPLE_NET_RANDOM,
+					dev->name, dev))) {
 		MOD_DEC_USE_COUNT;
 		return retval;
 	}
diff -urN linux-2.4.9-pre4/drivers/net/wavelan.c linux/drivers/net/wavelan.c
--- linux-2.4.9-pre4/drivers/net/wavelan.c	Wed Aug 15 23:09:39 2001
+++ linux/drivers/net/wavelan.c	Wed Aug 15 23:20:25 2001
@@ -3897,7 +3897,8 @@
 		return -ENXIO;
 	}
 
-	if (request_irq(dev->irq, &wavelan_interrupt, 0, "WaveLAN", dev) != 0) 
+	if (request_irq(dev->irq, &wavelan_interrupt, SA_SAMPLE_NET_RANDOM,
+				"WaveLAN", dev) != 0) 
 	{
 #ifdef DEBUG_CONFIG_ERROR
 		printk(KERN_WARNING "%s: wavelan_open(): invalid IRQ\n",



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

Re: [PATCH] Optionally let Net Devices feed Entropy

[Francois Romieu]

Robert Love <rml@tech9.net> :
> (patches will be attached in subsequent emails.  there is a set for
> 2.4.9-pre4 and another for 2.4.8-ac5.  Patch #1 includes the core code
> changes, configure changes, etc.  Patch #2 includes some updated network
> drivers).

Please, add an '(EXPERIMENTAL)' label to the configuration thing.

-- 
Ueimor

Re: [PATCH] Optionally let Net Devices feed Entropy

[Robert Love]

On 16 Aug 2001 10:50:10 +0200, Francois Romieu wrote:
> Please, add an '(EXPERIMENTAL)' label to the configuration thing.

What is experimental about it?

Some devices already contributed to the pool, now its a configuration
setting.  It just toggles whether net devices can contribute.  Nothing
experimental there to me.

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

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

[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

Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[Alex Bligh - linux-kernel]

> 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 I looked at this a bit more. The stuff which increases entropy
is meant to be secure from non-root users.

However (standard debian install - headless machine), unpriveleged
account:

$ cat /proc/interrupts
           CPU0
  0: 1116302985          XT-PIC  timer
  1:          2          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          1          XT-PIC  rtc
  9:   28980016          XT-PIC  usb-uhci, eth0
 14:  698146587          XT-PIC  ide0
 15:          5          XT-PIC  ide1
NMI:          0
ERR:          0

Shock horror - I can continually poll this and spot
when an IRQ occurs.

So polling /proc/interrupts gives me a pretty good indication
of timing for ide0 interrupts (and, if I had one, keyboard
interrupts). The /proc reading routine is sufficiently fast
that by repeating reading (as a user) I should be able to
get the inter-IRQ timing down to a few tens of microseconds,
which I think is a few tens of possible values added to the
entropy pool. This tells me that actually keyboard and ide
interrupt timings are no less observable by non-root people than
network interrupts.

Now if you have an IR or radio keyboard, the situation is even worse.

So I don't think Robert's patch is any more flawed than using
k/b, mouse, ide IRQs.

--
Alex Bligh

Re: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[Alex Bligh - linux-kernel]

> that by repeating reading (as a user) I should be able to
> get the inter-IRQ timing down to a few tens of microseconds,

& (as per add_timer_randomness) on all non-i386's and some
i386's, I actually only need to get the time within one jiffy.
Do this on 4 successive IRQ's, and that's 12 bits of 'false'
entropy. But the point is, it's no worse for network than
for the rest.

--
Alex Bligh

RE: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[David Schwartz]

> $ cat /proc/interrupts
>            CPU0
>   0: 1116302985          XT-PIC  timer
>   1:          2          XT-PIC  keyboard
>   2:          0          XT-PIC  cascade
>   8:          1          XT-PIC  rtc
>   9:   28980016          XT-PIC  usb-uhci, eth0
>  14:  698146587          XT-PIC  ide0
>  15:          5          XT-PIC  ide1
> NMI:          0
> ERR:          0
>
> Shock horror - I can continually poll this and spot
> when an IRQ occurs.

	To what level of accuracy do you think you can measure when interrupts
occur? From my tests, you can (if you max the processor and do no math on
the results) read /proc/interrupts about once every 30,000 instruction
cycles. This would still leave about 14 bits of entropy in each interrupt.

	Overall, you're just making the system busier.

	DS

RE: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[Alex Bligh - linux-kernel]

> 	To what level of accuracy do you think you can measure when interrupts
> occur?

Better than the necessary 1 jiffie on non-i386 platforms and some
i386 platforms.

--
Alex Bligh

RE: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[David Schwartz]

> > To what level of accuracy do you think you can measure when
> > interrupts
> > occur?

> Better than the necessary 1 jiffie on non-i386 platforms and some
> i386 platforms.

	On those platforms, you simply can't have good entropy and still have user
accounts on the box with the default hardware. Sorry, the hardware just
doesn't permit it. You would have to set up some secure way to draw entropy
off an external pool, there's just nothing else you can do. (I believe there
are non-x87 platforms that have good timers, just not all of them.)

	DS

RE: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[Alex Bligh - linux-kernel]

>> Better than the necessary 1 jiffie on non-i386 platforms and some
>> i386 platforms.
>
> 	On those platforms, you simply can't have good entropy and still have
> user accounts on the box with the default hardware. Sorry, the hardware
> just doesn't permit it. You would have to set up some secure way to draw
> entropy off an external pool, there's just nothing else you can do. (I
> believe there are non-x87 platforms that have good timers, just not all
> of them.)

Many non-i386 platforms have more finely grained timers than 1 jiffie.
The problem is the code doesn't use them. So my point is, it seems
illogical to throw stones at (often) theoretical issues with Robert's
patch, when people's energy would be better diverted to help fix up
hole in the current implementation.

--
Alex Bligh

RE: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[David Schwartz]

Alex Bligh wrote:

> Many non-i386 platforms have more finely grained timers than 1 jiffie.
> The problem is the code doesn't use them. So my point is, it seems
> illogical to throw stones at (often) theoretical issues with Robert's
> patch, when people's energy would be better diverted to help fix up
> hole in the current implementation.

	I don't understand the connection. Either Robert's patch is good or it's
bad. If there are other problems, then we can address those too. But to say
that Robert's patch is bad because it doesn't fix the most important problem
that you can think of doesn't make any sense. Every problem should be fixed,
and if Robert has a patch to fix one of them, then that's one less.

	You can certainly advise people to work on the most serious problems. But
you most certainly can't say that someone shouldn't work on X because Y is
more important.

	DS

RE: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[Alex Bligh - linux-kernel]

David,
> Alex Bligh wrote:
>
>> Many non-i386 platforms have more finely grained timers than 1 jiffie.
>> The problem is the code doesn't use them. So my point is, it seems
>> illogical to throw stones at (often) theoretical issues with Robert's
>> patch, when people's energy would be better diverted to help fix up
>> hole in the current implementation.
>
> 	I don't understand the connection. Either Robert's patch is good or it's
> bad. If there are other problems, then we can address those too. But to
> say that Robert's patch is bad because it doesn't fix the most important
> problem that you can think of doesn't make any sense. Every problem
> should be fixed, and if Robert has a patch to fix one of them, then
> that's one less.
>
> 	You can certainly advise people to work on the most serious problems. But
> you most certainly can't say that someone shouldn't work on X because Y is
> more important.

For clarity, I'm saying Robert's patch is GOOD, and those who are trying
to point out what I consider to be extremely theoretical weakness it
introduces into /dev/random (and then, only when config'd on), should
instead spend their attention looking at miuch more serious issues
in the algorithm elsewhere if they are that worried, rather than
attacking something which is useful.

To make an analogy, Robert is suggesting changing the 9 cylinder
lock on the back door of a house to a 7 cylinder lock, which is much
easier to operate, but perhaps slightly less secure. (well,
to be precise, he's advocating giving the house own the
OPTION to do this). However, the front door is wide open, swinging
in the wind, with no lock on at all. And people are worried about
Robert's patch. Doesn't make much sense...

--
Alex Bligh

RE: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[David Lang]

so as I see this discussion it goes something like this.

1. the entropy pool is not large enough on headless machines.
2. you don't want to use urandom as there are theoretical attacks against
it

so as a result you propose adding an option to weaken random (network
traffic is not that random which is a large part of why it's not included
now)

you are trading one theoretical attack for another known attack (a
difficult attack to pull off yes, but still known)

that doesn't sound like a reasonable tradeoff to me.

as for the arguments that applications all use random and would have to be
changed to use urandom.

don't forget that it's not the names that matter to the kernel it's the
major/minor numbers. you can rename random to really.random and urandom to
random and your software will not know the difference.

if you were arguing that the network traffic was truly random and that it
should be added in as well that would be a different story, but you're not
saying that you just don't want the incomvienience of blocking while
waiting for truely random data but want to fool yourself into thinking
that you are.

David Lang

 On Tue, 21 Aug 2001, Alex Bligh - linux-kernel wrote:

> Date: Tue, 21 Aug 2001 09:50:52 +0100
> From: Alex Bligh - linux-kernel <linux-kernel@alex.org.uk>
> To: David Schwartz <davids@webmaster.com>,
>      Alex Bligh - linux-kernel <linux-kernel@alex.org.uk>
> Cc: linux-kernel@vger.kernel.org,
>      Alex Bligh - linux-kernel <linux-kernel@alex.org.uk>
> Subject: RE: Entropy from net devices - keyboard & IDE just as 'bad' [was
>     Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]
>
> David,
> > Alex Bligh wrote:
> >
> >> Many non-i386 platforms have more finely grained timers than 1 jiffie.
> >> The problem is the code doesn't use them. So my point is, it seems
> >> illogical to throw stones at (often) theoretical issues with Robert's
> >> patch, when people's energy would be better diverted to help fix up
> >> hole in the current implementation.
> >
> > 	I don't understand the connection. Either Robert's patch is good or it's
> > bad. If there are other problems, then we can address those too. But to
> > say that Robert's patch is bad because it doesn't fix the most important
> > problem that you can think of doesn't make any sense. Every problem
> > should be fixed, and if Robert has a patch to fix one of them, then
> > that's one less.
> >
> > 	You can certainly advise people to work on the most serious problems. But
> > you most certainly can't say that someone shouldn't work on X because Y is
> > more important.
>
> For clarity, I'm saying Robert's patch is GOOD, and those who are trying
> to point out what I consider to be extremely theoretical weakness it
> introduces into /dev/random (and then, only when config'd on), should
> instead spend their attention looking at miuch more serious issues
> in the algorithm elsewhere if they are that worried, rather than
> attacking something which is useful.
>
> To make an analogy, Robert is suggesting changing the 9 cylinder
> lock on the back door of a house to a 7 cylinder lock, which is much
> easier to operate, but perhaps slightly less secure. (well,
> to be precise, he's advocating giving the house own the
> OPTION to do this). However, the front door is wide open, swinging
> in the wind, with no lock on at all. And people are worried about
> Robert's patch. Doesn't make much sense...
>
> --
> 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/
>

RE: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[Alex Bligh - linux-kernel]

David,

> so as I see this discussion it goes something like this.
>
> 1. the entropy pool is not large enough on headless machines.
> 2. you don't want to use urandom as there are theoretical attacks against
> it
>
> so as a result you propose adding an option to weaken random (network
> traffic is not that random which is a large part of why it's not included
> now)

An option, yes.

> you are trading one theoretical attack for another known attack (a
> difficult attack to pull off yes, but still known)

Not exactly, because to break /dev/random (with the config option on)
you have to (a) do the work that would have broken /dev/urandom, and
(b) break the translation of network traffic into entropy. If you
were using /dev/urandom only, you'd have to just do (a). IE if the
two alternatives are /dev/urandom, and /dev/random with Robert's
patch, the latter is certainly more secure (i.e. it's not a tradeoff).

> as for the arguments that applications all use random and would have to be
> changed to use urandom.
>
> don't forget that it's not the names that matter to the kernel it's the
> major/minor numbers. you can rename random to really.random and urandom to
> random and your software will not know the difference.

This is a fair point, but doesn't take into account the 'waiting for
sufficient entropy' point - which of course relies on network traffic
timing being sufficiently unobservable that it constitutes valid entropy.

> if you were arguing that the network traffic was truly random and that it
> should be added in as well that would be a different story, but you're not
> saying that you just don't want the incomvienience of blocking while
> waiting for truely random data but want to fool yourself into thinking
> that you are.

Well, I was arguing that network traffic was sufficiently unobservable
that it constitutes valid entropy under some circumstances, until I went
and read the code. It is so (it seems to me) on some i386 versions, where
the cycle clock is used. It is definitely not (and neither are any of
the other interrupt timings) where jiffies are used, for a start
because /proc/interrupts gives you the jiffie count (timer interrupts)
and the other interrupt counters simultaneously. So my argument is
that in some situations (where you know are happy with the extent
to which there is no observation of your wire locally), net IRQs
are no worse than the other sources of entropy, and sometimes they
are better (consider keyboards connected by radio). Obviously, in
cases like 802.11, they are substantially worse (and, no doubt, we
could omit Robert's patch from things like 802.11 drivers which
are obvious 'don't do that' cases).

--
Alex Bligh

Re: Entropy from net devices - keyboard & IDE just as 'bad' (better timing in random.c)

[Johan Adolfsson]

Alex Bligh - linux-kernel <linux-kernel@alex.org.uk> wrote:

> Well, I was arguing that network traffic was sufficiently unobservable
> that it constitutes valid entropy under some circumstances, until I went
> and read the code. It is so (it seems to me) on some i386 versions, where
> the cycle clock is used. It is definitely not (and neither are any of
> the other interrupt timings) where jiffies are used, for a start
> because /proc/interrupts gives you the jiffie count (timer interrupts)
> and the other interrupt counters simultaneously. So my argument is
> that in some situations (where you know are happy with the extent
> to which there is no observation of your wire locally), net IRQs
> are no worse than the other sources of entropy, and sometimes they
> are better (consider keyboards connected by radio). Obviously, in
> cases like 802.11, they are substantially worse (and, no doubt, we
> could omit Robert's patch from things like 802.11 drivers which
> are obvious 'don't do that' cases).

How about improving that with something like this (not test compiled)

static void add_timer_randomness(struct timer_rand_state *state, unsigned
num)
{
 __u32  time;
 __s32  delta, delta2, delta3;
 int  entropy = 0;

#if defined (__i386__)
 if ( test_bit(X86_FEATURE_TSC, &boot_cpu_data.x86_capability) ) {
  __u32 high;
  __asm__(".byte 0x0f,0x31"
   :"=a" (time), "=d" (high));
  num ^= high;
 } else {
  time = jiffies;
 }
#else
+ struct timeval tv;
+ do_gettimeofday(&tv);
+ num ^= tv.tv_usec;
 time = jiffies;
#endif

Of course do_gettimeofday() is probably a little to heavyweigt for doing
this,
so how about adding an arch specific macro:
GET_JIFFIES_USEC()
that returns the number of microseconds in the current jiffie and simply
use that to modify the num?

/Johan

Re: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[David Wagner]

David Lang  wrote:
>so as I see this discussion it goes something like this.
>
>1. the entropy pool is not large enough on headless machines.
>2. you don't want to use urandom as there are theoretical attacks against
>it

If that's the concern, then I'm glad to say that I have very reassuring
news for you.  No attacks are known on /dev/urandom, not even theoretical
ones.

(And no attack is known on SHA-1, not even a theoretical one.)

(Don't confuse a remote risk that someone might discover a theoretical
attack on SHA-1 with knowledge that we already know of a theoretical
attack on SHA-1.)

Re: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[Robert Love]

On Tue, 2001-08-21 at 14:31, David Wagner wrote:
> David Lang  wrote:
> >so as I see this discussion it goes something like this.
> >
> >1. the entropy pool is not large enough on headless machines.
> >2. you don't want to use urandom as there are theoretical attacks against
> >it
> 
> If that's the concern, then I'm glad to say that I have very reassuring
> news for you.  No attacks are known on /dev/urandom, not even theoretical
> ones.

This is because there are no known attacks are SHA-1.

> (And no attack is known on SHA-1, not even a theoretical one.)

Right.

> (Don't confuse a remote risk that someone might discover a theoretical
> attack on SHA-1 with knowledge that we already know of a theoretical
> attack on SHA-1.)

Responding to David Lang, #1 is correct.  On a headless or diskless
machine, the entropy pool can be very small.  Net devices provide the
needed entropy.

Thus, since _you_ trust SHA-1, if you also feel the bits garnered from
your network interfaces is entropic, then the patch is useful for you.

If you don't, then don't enable it.  But, since you trust SHA-1,
/dev/random is of no difference to you than /dev/urandom, so its no
difference :)

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

Re: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[David Wagner]

Alex Bligh - linux-kernel  wrote:
>For clarity, I'm saying Robert's patch is GOOD, and those who are trying
>to point out what I consider to be extremely theoretical weakness it
>introduces into /dev/random (and then, only when config'd on), [...]

That's one place where we disagree.  Over-estimating entropy is not a
theoretical weakness: this is something that real cryptographers get real
worried about.  It's one of the easiest ways for a crypto system to fail.

Re: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[Robert Love]

On Tue, 2001-08-21 at 17:50, Robert Love wrote:
><snip>
> 
> In theory, we dont need both SHA-1 hash and the entropy count.  They
> exist to pacify a theoretical weakness in each.
> 
> Now, my net device patch should only be enabled in situations where both
> you trust SHA-1 (and I think most do) and you trust that reading net
> devices yields the full amount of entropy.

'lil typo on my part.  actually, if you trust SHA-1, it does not matter
if your net devices give zero entropy, because the SHA-1 hash of the
read from /dev/random is still unpredictable.

the problem is if you both _dont_ trust SHA-1 and _fear_ there is
less-than-estimated entropy from net devices on your network.

per Alex Bligh's suggestion, the Configure wording of the next patch
will explain this.
 
-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: Entropy from net devices - keyboard & IDE just as 'bad' [was Re: [PATCH] let Net Devices feed Entropy, updated (1/2)]

[Robert Love]

On Tue, 2001-08-21 at 14:29, David Wagner wrote:
> Alex Bligh - linux-kernel  wrote:
> >For clarity, I'm saying Robert's patch is GOOD, and those who are trying
> >to point out what I consider to be extremely theoretical weakness it
> >introduces into /dev/random (and then, only when config'd on), [...]
> 
> That's one place where we disagree.  Over-estimating entropy is not a
> theoretical weakness: this is something that real cryptographers get real
> worried about.  It's one of the easiest ways for a crypto system to fail.

Entirely agreed, but that is why we have SHA-1.  If we assume SHA-1 is
not crackable, then the entropy estimate is actually worthless.  It
exists because of the theoretical possibility of learning some state of
the pool from a given read.

In theory, we dont need both SHA-1 hash and the entropy count.  They
exist to pacify a theoretical weakness in each.

Now, my net device patch should only be enabled in situations where both
you trust SHA-1 (and I think most do) and you trust that reading net
devices yields the full amount of entropy.

-- 
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 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)

[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)

[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)

[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)

[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)

[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]

>> 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/

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

Re: [PATCH] Optionally let Net Devices feed Entropy

[Robert Love]

On 16 Aug 2001 20:28:41 +0100, Alex Bligh - linux-kernel wrote:
> 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?

amen, thank you :)

> If you mean that the option should be labelled 'not for
> the paranoid' I agree.

agreed.

now, we talked earlier about this patch, Alex -- what are your opinions
of it?  have you tried it?

i know it is not exactly what you want (although i am still open to your
way, too), but i made it due in no small part to our conversation and
would like your opinion.  i am using it now.

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

Re: [PATCH] Optionally let Net Devices feed Entropy

[Alex Bligh - linux-kernel]

> now, we talked earlier about this patch, Alex -- what are your opinions
> of it?  have you tried it?
>
> i know it is not exactly what you want (although i am still open to your
> way, too), but i made it due in no small part to our conversation and
> would like your opinion.  i am using it now.

Looks 'obviously correct' to me (famous last words). I can't try it
on the system that is otherwise entropy-short as I don't want to
touch the kernel on that box right now.

As I said to you by private email, I have a slight preference for
a /proc controlled version (just so vendor-distributed precompiled
kernels could work either way, with the vendor-dist rc script
chosing a default option based on the vendor config script) given
coding /proc entries is trivial (see manual patch :-). However, your
patch is many many times better than the status quo IMHO.

--
Alex Bligh

Re: [PATCH] Optionally let Net Devices feed Entropy

[Robert Love]

On 16 Aug 2001 19:02:55 +0200, Francois Romieu wrote:
> 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 ?

then mark the entropy generator experimental if you believe that.  its
irrelevant here.

this is just taking a behavior that is inconsistent (do NICs enable
SA_SAMPLE_RANDOM), making it consistent (SA_SAMPLE_NET_RANDOM), and
making it configurable.  Nothing is experimental.  This does not change
things; it makes things configurable.

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

Re: [PATCH] Optionally let Net Devices feed Entropy

[Francois Romieu]

Robert Love <rml@tech9.net> :
[...]
> making it configurable.  Nothing is experimental.  This does not change
> things; it makes things configurable.

I have checked again the patches and they allow a lot of drivers to feed 
the entropy pool that otherwise wouldn't had ever contributed to it. Thus 
it changes things and opens the question about the effects on entropy 
estimate. See the figures, three (3) nics to date reference SA_SAMPLE_RANDOM.
As the fact that 2.4 is supposed to be a stable serie, I assume it's
irrelevant.

-- 
Ueimor

Re: [PATCH] Optionally let Net Devices feed Entropy

[Alex Bligh - linux-kernel]

>> making it configurable.  Nothing is experimental.  This does not change
>> things; it makes things configurable.
>
> I have checked again the patches and they allow a lot of drivers to feed
> the entropy pool that otherwise wouldn't had ever contributed to it. Thus
> it changes things and opens the question about the effects on entropy
> estimate.

It only changes things if you configure it on, and you are correct that
many other drivers feed the entropy pool if so. That is, indeed, the whole
point of the patch.

> See the figures, three (3) nics to date reference
> SA_SAMPLE_RANDOM. As the fact that 2.4 is supposed to be a stable serie,
> I assume it's irrelevant.

There is a leap of logic in the last sentence I don't understand. Stable
(or rather release) kernels are supposed to behave predictably. Behaviour
dependent upon NIC is not predictable. Behaviour dependent upon a config
option (which does 'exactly what it says on the tin') is predictable.
Stable/release series are meant to have bugs fixed. Please tell me why
having 3 NIC cards behave one way, and the rest behaviour another is
/not/ a bug. Stable kernels are meant to be functional and secure. Robert's
patch allows the user both/either, in situations where the previous
kernel could be either dysfunctional (insufficient entropy) or arguably
potentially insecure (theoretical possibility of external manipulation
of entropy source).

--
Alex Bligh

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.