From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756312AbcFTSdD (ORCPT ); Mon, 20 Jun 2016 14:33:03 -0400 Received: from mail.eperm.de ([89.247.134.16]:37424 "EHLO mail.eperm.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933090AbcFTScw (ORCPT ); Mon, 20 Jun 2016 14:32:52 -0400 From: Stephan Mueller To: "Austin S. Hemmelgarn" Cc: "Theodore Ts'o" , David =?utf-8?B?SmHFoWE=?= , Andi Kleen , sandyinchina@gmail.com, Jason Cooper , John Denker , "H. Peter Anvin" , Joe Perches , Pavel Machek , George Spelvin , 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 20:32:43 +0200 Message-ID: <8999970.pstTbGZv5G@positron.chronox.de> User-Agent: KMail/4.14.10 (Linux/4.5.5-201.fc23.x86_64; KDE/4.14.20; x86_64; ; ) In-Reply-To: References: <1466007463.20087.11.camel@redhat.com> <3381856.qSaz1KcX2Z@positron.chronox.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn: Hi Austin, > 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. It was on real hardware. As part of my Jitter RNG project, I tested all major CPUs from small to big -- see Appendix F [1]. For MIPS/ARM, see the trailing part of the big table. [1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf Ciao Stephan