From: "Thiago Galesi" <thiagogalesi@gmail.com>
To: "Matt Mackall" <mpm@selenic.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers
Date: Sun, 7 May 2006 10:13:50 -0300 [thread overview]
Message-ID: <82ecf08e0605070613o7b217a2bw4c71c3a8c33bed28@mail.gmail.com> (raw)
In-Reply-To: <20060507045920.GH15445@waste.org>
> Sure.
>
> First, since the existence of /dev/random's entropy accounting scheme
> is predicated on the assumption that we can break the hash function at
> will, I'll replace SHA1 with, oh, say, CRC-16. This'll be illustrative
> until someone has a nice preimage attack against SHA1.
>
> Then I'll run my test on one of the various arches where HZ=~100 and
> we don't have a TSC. Like Sparc?
>
> Now all the inputs are easily predictable from anywhere with <10ms
> ping, with the occassional need to guess between a pair of timer
> ticks. And since I can calculate preimages of CRC-16, I can now deduce
> the state of the pool if I can watch some subset of its output, say
> https session keys I request. And then I can start guessing future
> outputs and breaking into other people's https sessions.
>
> The point of /dev/random is to -survive- SHA1 being broken by never
> giving out more secrets than we take in.
OK, here goes...
1 - by eliminating feeding enthopy from network cards you are
eliminating all sources of enthropy for _lots_ of people (think
headless servers, embedded systems - even though there can be other
sources of enthropy there) Unfortunatelly, bad enthropy is still
better than no enthropy (just think - no ssh / https, etc, etc)
2 - some platforms have much better enthropy sources than ethernet (or
user input), just think hardware rngs, or even the sound card rng
thing mentioned above
3 - as people said, your example (CRC-16 on specific platfoms) is
(IMHO) an exxageration. Of course, /dev/random should try and protect
us from whatever protocol being broken. That being said, this
protection should be 'realistic'. In theory most things are broken if
we have enough equipment and computing power.
My conclusion, I have no problem removing SA_SAMPLE_RANDOM *IN
SPECIFIC CASES* (meaning, this should be user configurable). In a
secure environment / platform has rng, it could be turned off, and in
a headless server / embedded system / it could be left on.
Of course, that's just MHO...
Thiago
next prev parent reply other threads:[~2006-05-07 13:13 UTC|newest]
Thread overview: 60+ 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 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 6/14] random: Remove redundant SA_SAMPLE_RANDOM from touchscreen drivers 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 4/14] random: Change cpqarray to use add_disk_randomness 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 [this message]
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 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
2006-05-06 18:31 ` 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 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 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
2006-05-05 16:42 ` [PATCH 13/14] random: Remove SA_SAMPLE_RANDOM from IRQ fastpath Matt Mackall
2006-05-08 7:38 [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers linux
2006-05-12 6:09 ` linux
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=82ecf08e0605070613o7b217a2bw4c71c3a8c33bed28@mail.gmail.com \
--to=thiagogalesi@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
/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
Powered by JetHome