linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Matt Mackall <mpm@selenic.com>
Cc: Denis Vlasenko <vda@ilport.com.ua>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 8/14] random: Remove SA_SAMPLE_RANDOM from USB gadget drivers
Date: Sat, 6 May 2006 11:16:16 -0700	[thread overview]
Message-ID: <200605061116.18274.david-b@pacbell.net> (raw)
In-Reply-To: <200605061407.02737.vda@ilport.com.ua>

On Saturday 06 May 2006 4:07 am, Denis Vlasenko wrote:
> On Friday 05 May 2006 19:42, Matt Mackall wrote:
> > Remove SA_SAMPLE_RANDOM from USB gadget drivers

It's conventional to post USB patches to linux-usb-devel, or at least
to CC that list.


> > There's no a priori reason to think that USB device interrupts will
> > contain "entropy" as defined/required by /dev/random. In fact, most
> > operations will be streaming and bandwidth- or CPU-limited.
> > /dev/random needs unpredictable inputs such as human interaction or
> > chaotic physical processes like turbulence manifested in disk seek
> > times.

And that'd be why you removed that SAMPLE_RANDOM from the Lubbock VBUS
irqs ... which come from users connecting (by hand!) a USB cable.  :)

You shouldn't add spaces before labels, or change indents from
pure-tab to tabs-plus-four-spaces.

Admittedly OMAP _now_ has access to the FIPS-certified hardware RNG,
so for that platform it's hard to justify needing other entropy sources.
But on the other hand, DMA completion IRQs aren't exactly predictable
either, and it doesn't necessarily hurt to salt a high entropy pool
with some less-high entropy inputs.



> Come on, let's get real. A few low bits of TSC are random enough
> (for just about any interrupt source).
> 
> Attackers will probably look for easier ways to hack your crypto
> than predicting /dev/random.

I'm not sure I'd go that far.  But I'd agree that this particular
patch should not be merged.

Reasonable people could have arguments about the quality of a given
entropy source ... and the SA_SAMPLE_RANDOM mechanism has no way to
indicate that quality, thereby wrongly implying that all interrupts
have the same entropy contribution.  A few Kbytes/second is very
different from a few bits per hour.

But I disagree with the blanket assertion that only high quality
crypto-ready RNG sources should ever be provided ... and that lower
quality sources are useless.  Sure it helps if attackers need extra
hours to make the attack, but extra minutes help too.

- Dave


  reply	other threads:[~2006-05-06 18:16 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05 16:42 [PATCH 1/14] random: Remove SA_SAMPLE_RANDOM from floppy driver Matt Mackall
2006-05-05 16:42 ` [PATCH 6/14] random: Remove redundant SA_SAMPLE_RANDOM from touchscreen drivers Matt Mackall
2006-05-05 16:42 ` [PATCH 4/14] random: Change cpqarray to use add_disk_randomness Matt Mackall
2006-05-05 16:42 ` [PATCH 2/14] random: Remove redundant SA_SAMPLE_RANDOM from NinjaSCSI Matt Mackall
2006-05-05 16:42 ` [PATCH 3/14] random: Make CCISS use add_disk_randomness Matt Mackall
2006-05-05 16:42 ` [PATCH 5/14] random: Remove bogus SA_SAMPLE_RANDOM from at91 compact flash driver Matt Mackall
2006-05-05 16:42 ` [PATCH 8/14] random: Remove SA_SAMPLE_RANDOM from USB gadget drivers Matt Mackall
2006-05-06 11:07   ` Denis Vlasenko
2006-05-06 18:16     ` David Brownell [this message]
2006-05-06 18:31       ` Matt Mackall
2006-05-05 16:42 ` [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers Matt Mackall
2006-05-05 17:13   ` Kyle Moffett
2006-05-05 17:24     ` Matt Mackall
2006-05-05 19:11       ` Theodore Tso
2006-05-05 20:30         ` Stephen Hemminger
2006-05-05 20:34         ` Matt Mackall
2006-05-06 11:55           ` Theodore Tso
2006-05-06 16:48             ` Matt Mackall
2006-05-06 17:29               ` Bernd Eckenfels
2006-05-06 18:05               ` Theodore Tso
2006-05-06 20:33                 ` Matt Mackall
2006-05-07  0:17                   ` David S. Miller
2006-05-07  1:22                   ` Theodore Tso
2006-05-07  5:07                     ` Matt Mackall
2006-05-08 21:58                     ` Sami Farin
2006-05-24 22:47                 ` Marcin Dalecki
2006-05-25  0:08                   ` Theodore Tso
2006-05-31 19:29                     ` Bill Davidsen
2006-05-07  0:08               ` David S. Miller
2006-05-07  4:59                 ` Matt Mackall
2006-05-07  5:46                   ` David S. Miller
2006-05-07 16:31                     ` Matt Mackall
2006-05-07 13:13                   ` Thiago Galesi
2006-05-07 16:00                     ` Matt Mackall
2006-05-07 17:00                       ` Thiago Galesi
2006-05-08  0:13                       ` Theodore Tso
2006-05-08  2:55                         ` Matt Mackall
2006-05-08  6:26                   ` Pavel Machek
2006-05-08  7:07                     ` David S. Miller
2006-05-08 14:05                       ` Matt Mackall
2006-05-08 17:21                         ` Pavel Machek
2006-05-08 17:27                           ` Matt Mackall
2006-05-09 11:23                             ` Pavel Machek
2006-05-11 10:05                           ` Ph. Marek
2006-05-24 22:35         ` Marcin Dalecki
2006-05-05 21:10   ` David S. Miller
2006-05-05 23:03     ` Matt Mackall
2006-05-05 23:19       ` David S. Miller
2006-05-06 14:08     ` Folkert van Heusden
2006-05-06 15:19       ` Lee Revell
2006-05-07 10:35         ` Folkert van Heusden
2006-05-07 16:33           ` Matt Mackall
2006-05-05 16:42 ` [PATCH 9/14] random: Remove SA_SAMPLE_RANDOM from i2c drivers Matt Mackall
2006-05-05 16:42 ` [PATCH 10/14] random: Remove bogus SA_SAMPLE_RANDOM from mpc52xx serial driver Matt Mackall
2006-05-05 16:42 ` [PATCH 11/14] random: Remove UML usage of SA_SAMPLE_RANDOM Matt Mackall
2006-05-05 16:42 ` [PATCH 13/14] random: Remove SA_SAMPLE_RANDOM from IRQ fastpath Matt Mackall
2006-05-05 16:42 ` [PATCH 12/14] random: Remove not very useful SA_SAMPLE_RANDOM from lubbock Matt Mackall
2006-05-05 16:42 ` [PATCH 14/14] random: Remove add_interrupt_randomness Matt Mackall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200605061116.18274.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=vda@ilport.com.ua \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).