linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Stephan Mueller <smueller@chronox.de>, "Theodore Ts'o" <tytso@mit.edu>
Cc: "David Jaša" <djasa@redhat.com>,
	"Andi Kleen" <andi@firstfloor.org>,
	sandyinchina@gmail.com,
	"Jason Cooper" <cryptography@lakedaemon.net>,
	"John Denker" <jsd@av8n.com>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	"Joe Perches" <joe@perches.com>, "Pavel Machek" <pavel@ucw.cz>,
	"George Spelvin" <linux@horizon.com>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/5] /dev/random - a new approach
Date: Mon, 20 Jun 2016 13:07:32 -0400	[thread overview]
Message-ID: <f22f4cd6-8198-71a0-9b79-9f10070758f3@gmail.com> (raw)
In-Reply-To: <3381856.qSaz1KcX2Z@positron.chronox.de>

On 2016-06-18 12:31, Stephan Mueller wrote:
> Am Samstag, 18. Juni 2016, 10:44:08 schrieb Theodore Ts'o:
>
> Hi Theodore,
>
>>
>> At the end of the day, with these devices you really badly need a
>> hardware RNG.  We can't generate randomness out of thin air.  The only
>> thing you really can do requires user space help, which is to generate
>> keys lazily, or as late as possible, so you can gather as much entropy
>> as you can --- and to feed in measurements from the WiFi (RSSI
>> measurements, MAC addresses seen, etc.)  This won't help much if you
>> have an FBI van parked outside your house trying to carry out a
>> TEMPEST attack, but hopefully it provides some protection against a
>> remote attacker who isn't try to carry out an on-premises attack.
>
> All my measurements on such small systems like MIPS or smaller/older ARMs do
> not seem to support that statement :-)
Was this on real hardware, or in a virtual machine/emulator?  Because if 
it's not on real hardware, you're harvesting entropy from the host 
system, not the emulated one.  While I haven't done this with MIPS or 
ARM systems, I've taken similar measurements on SPARC64, x86_64, and 
PPC64 systems comparing real hardware and emulated hardware, and the 
emulated hardware _always_ has higher entropy, even when running the 
emulator on an identical CPU to the one being emulated and using KVM 
acceleration and passing through all the devices possible.

Even if you were testing on real hardware, I'm still rather dubious, as 
every single test I've ever done on any hardware (SPARC, PPC, x86, ARM, 
and even PA-RISC) indicates that you can't harvest entropy as 
effectively from a smaller CPU compared to a large one, and this effect 
is significantly more pronounced on RISC systems.

  reply	other threads:[~2016-06-20 17:30 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31 18:37 [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller
2016-05-31 18:37 ` [PATCH v4 1/5] crypto: DRBG - externalize DRBG functions for LRNG Stephan Mueller
2016-05-31 18:38 ` [PATCH v4 2/5] random: conditionally compile code depending on LRNG Stephan Mueller
2016-05-31 18:39 ` [PATCH v4 3/5] crypto: Linux Random Number Generator Stephan Mueller
2016-05-31 18:39 ` [PATCH v4 4/5] crypto: LRNG - enable compile Stephan Mueller
2016-05-31 18:39 ` [PATCH v4 5/5] random: add interrupt callback to VMBus IRQ handler Stephan Mueller
2016-05-31 22:34 ` [PATCH v4 0/5] /dev/random - a new approach George Spelvin
2016-06-15 16:17 ` David Jaša
2016-06-15 16:58   ` Stephan Mueller
2016-06-17 13:56     ` David Jaša
2016-06-17 15:26       ` Sandy Harris
2016-06-18  8:22         ` Stephan Mueller
2016-06-18  8:21       ` Stephan Mueller
2016-06-18 14:44       ` Theodore Ts'o
2016-06-18 16:31         ` Stephan Mueller
2016-06-20 17:07           ` Austin S. Hemmelgarn [this message]
2016-06-20 18:32             ` Stephan Mueller
2016-06-21 13:05               ` Austin S. Hemmelgarn
2016-06-21 13:19                 ` Tomas Mraz
2016-06-21 17:18                   ` Austin S. Hemmelgarn
2016-06-21 17:23                     ` Stephan Mueller
2016-06-21 17:54                       ` Austin S. Hemmelgarn
2016-06-21 18:05                         ` Stephan Mueller
2016-06-21 13:20                 ` Stephan Mueller
2016-06-21 17:51                   ` Austin S. Hemmelgarn
2016-06-21 18:04                     ` Stephan Mueller
2016-06-21 19:31                       ` Austin S. Hemmelgarn
2016-06-22  5:16                         ` Stephan Mueller
2016-06-22 12:54                           ` Austin S. Hemmelgarn
2016-06-22 13:25                             ` Stephan Mueller
2016-06-21 13:42                 ` Pavel Machek
2016-06-21 17:17                   ` Austin S. Hemmelgarn
2016-06-21 12:25         ` David Jaša

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=f22f4cd6-8198-71a0-9b79-9f10070758f3@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=andi@firstfloor.org \
    --cc=cryptography@lakedaemon.net \
    --cc=djasa@redhat.com \
    --cc=hpa@linux.intel.com \
    --cc=joe@perches.com \
    --cc=jsd@av8n.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=pavel@ucw.cz \
    --cc=sandyinchina@gmail.com \
    --cc=smueller@chronox.de \
    --cc=tytso@mit.edu \
    /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).