From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Jeff Garzik <jgarzik@pobox.com>,
David McCullough <davidm@snapgear.com>,
cryptoapi@lists.logix.cz, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
James Morris <jmorris@redhat.com>
Subject: Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Date: Fri, 25 Mar 2005 10:58:16 +0300 [thread overview]
Message-ID: <1111737496.20797.59.camel@uganda> (raw)
In-Reply-To: <20050325072531.GA416@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]
On Fri, 2005-03-25 at 18:25 +1100, Herbert Xu wrote:
> On Fri, Mar 25, 2005 at 10:19:55AM +0300, Evgeniy Polyakov wrote:
> >
> > Noone will complain on Linux if NIC is broken and produces wrong
> > checksum
> > and HW checksum offloading is enabled using ethtools.
>
> This is completely different. The worst that can happen with checksum
> offloading is that the packet is dropped. That's something people deal
> with on a daily basis since the Internet as a whole does not guarantee
> the delivery of packets.
It will just completely stop network dataflow.
It is of course not as catastrophic as removing strong random numbers
from system.
But nevertheless - write cahce in disks may corrupt data on power-down,
but people do not turn it off, crypto HW can be broken and does not
encrypt dataflow, but people want it, broken NIC can corrupt data with
various sg/offload combinations, but it can be enabled.
It is a feature, that _may_ broke thing badly.
But if all is ok - it is extremly usefull.
And as I said there may be other [HW/driver] validating techniques,
not only userspace daemon.
> On the other hand, /dev/random is something that has always promised
> to deliver random numbers that are totally unpredictable. People out
> there *depend* on this.
>
> If that assumption is violated the result could be catastrophic.
>
> That's why it's OK to have hardware RNG spit out unverified numbers
> in /dev/hw_random, but it's absolutely unaccpetable for the same
> numbers to add entropy to /dev/random without verification.
Userspace daemon can read data from /dev/random and validate it
in background, if it fells it is broken - turn feature off.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-03-25 7:52 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-15 13:36 ocf-linux-20050315 - Asynchronous Crypto support for linux David McCullough
2005-03-24 4:27 ` [PATCH] API for true Random Number Generators to add entropy (2.6.11) David McCullough
2005-03-24 4:30 ` [PATCH] API for true Random Number Generators to add entropy (2.4.29) David McCullough
2005-03-24 4:33 ` [PATCH] API for true Random Number Generators to add entropy (2.6.11) Jeff Garzik
2005-03-24 4:46 ` David McCullough
2005-03-24 4:49 ` Michal Ludvig
2005-03-24 5:13 ` Jeff Garzik
2005-03-24 12:37 ` Folkert van Heusden
2005-03-24 12:52 ` David McCullough
2005-03-24 20:51 ` Jeff Garzik
2005-03-24 7:18 ` Jan Engelhardt
2005-03-24 7:37 ` Dave Jones
2005-03-24 4:38 ` [PATCH] " Andrew Morton
2005-03-24 5:17 ` Jeff Garzik
2005-03-24 5:32 ` Andrew Morton
2005-03-29 1:33 ` Matt Mackall
2005-03-24 5:43 ` Randy.Dunlap
2005-03-24 12:21 ` Evgeniy Polyakov
2005-03-24 20:39 ` Jeff Garzik
2005-03-25 4:25 ` Evgeniy Polyakov
2005-03-25 4:45 ` Jeff Garzik
2005-03-25 5:46 ` Herbert Xu
2005-03-31 3:52 ` David McCullough
2005-03-31 13:58 ` [PATCH] API for TRNG (2.6.11) [Fortuna] Jean-Luc Cooke
2005-04-13 15:36 ` Jean-Luc Cooke
2005-03-24 12:28 ` [PATCH 2.6.12-rc1] API for true Random Number Generators to add entropy David McCullough
2005-03-24 12:38 ` [PATCH] API for true Random Number Generators to add entropy (2.6.11) David McCullough
2005-03-24 18:51 ` Andi Kleen
2005-03-24 20:37 ` Jeff Garzik
2005-03-27 17:19 ` Andi Kleen
2005-03-27 18:55 ` folkert
2005-03-28 15:20 ` Andi Kleen
2005-03-28 15:24 ` folkert
2005-03-29 7:17 ` Jeff Garzik
2005-03-29 15:03 ` Andi Kleen
2005-03-29 7:16 ` Jeff Garzik
2005-03-29 15:07 ` Andi Kleen
2005-03-29 7:15 ` Jeff Garzik
2005-03-24 11:59 ` Evgeniy Polyakov
2005-03-24 12:48 ` Jeff Garzik
2005-03-24 13:08 ` Evgeniy Polyakov
2005-03-24 20:53 ` Jeff Garzik
2005-03-24 13:23 ` David McCullough
2005-03-24 13:46 ` Evgeniy Polyakov
2005-03-24 20:56 ` Jeff Garzik
2005-03-25 4:34 ` Evgeniy Polyakov
2005-03-25 4:48 ` Jeff Garzik
2005-03-25 5:33 ` Evgeniy Polyakov
2005-03-25 5:58 ` Jeff Garzik
2005-03-25 6:16 ` Evgeniy Polyakov
2005-03-25 6:13 ` Herbert Xu
2005-03-25 6:34 ` Evgeniy Polyakov
2005-03-25 6:33 ` Herbert Xu
2005-03-25 6:59 ` Evgeniy Polyakov
2005-03-25 6:56 ` Herbert Xu
2005-03-25 7:19 ` Evgeniy Polyakov
2005-03-25 7:19 ` Jeff Garzik
2005-03-25 7:38 ` Evgeniy Polyakov
2005-03-25 7:25 ` Herbert Xu
2005-03-25 7:58 ` Evgeniy Polyakov [this message]
[not found] ` <424495A8.40804@freescale.com>
2005-03-25 23:43 ` Jeff Garzik
2005-03-25 23:47 ` Herbert Xu
2005-03-26 0:47 ` Evgeniy Polyakov
2005-03-26 0:36 ` Herbert Xu
2005-03-26 8:52 ` Evgeniy Polyakov
2005-03-28 13:45 ` Jean-Luc Cooke
2005-03-28 21:30 ` Herbert Xu
2005-03-29 10:23 ` Pavel Machek
2005-03-29 10:21 ` Pavel Machek
2005-03-29 10:30 ` Herbert Xu
2005-03-29 10:38 ` Pavel Machek
2005-03-29 10:45 ` Herbert Xu
2005-03-29 10:50 ` Evgeniy Polyakov
2005-03-29 10:46 ` Herbert Xu
2005-03-29 11:42 ` Evgeniy Polyakov
2005-03-29 11:39 ` Herbert Xu
2005-03-29 12:15 ` Evgeniy Polyakov
2005-03-29 12:13 ` Pavel Machek
2005-03-29 12:43 ` Herbert Xu
2005-03-29 13:11 ` Evgeniy Polyakov
2005-03-29 14:38 ` Evgeniy Polyakov
2005-03-29 13:48 ` Jean-Luc Cooke
2005-03-29 23:36 ` Andrew James Wade
2005-03-29 22:02 ` Bill Davidsen
2005-03-29 22:24 ` Kyle Moffett
2005-03-29 22:46 ` Jeff Garzik
2005-03-30 21:22 ` Bill Davidsen
2005-03-30 21:49 ` Jeff Garzik
2005-03-30 22:27 ` Paul Jackson
2005-03-29 10:18 ` Pavel Machek
2005-03-29 10:25 ` Herbert Xu
2005-03-29 10:53 ` Martin Mares
2005-03-24 20:54 ` Jeff Garzik
2005-03-24 14:25 ` Jean-Luc Cooke
2005-03-24 20:57 ` Jeff Garzik
2005-03-24 21:20 ` Herbert Xu
2005-03-25 5:52 ` Evgeniy Polyakov
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=1111737496.20797.59.camel@uganda \
--to=johnpol@2ka.mipt.ru \
--cc=akpm@osdl.org \
--cc=cryptoapi@lists.logix.cz \
--cc=davidm@snapgear.com \
--cc=herbert@gondor.apana.org.au \
--cc=jgarzik@pobox.com \
--cc=jmorris@redhat.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.