From: Sandy Harris Subject: Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random Date: Mon, 14 Oct 2013 11:18:16 -0400 Message-ID: References: <2579337.FPgJGgHYdz@tauon> <3593500.a7fOuGKlEX@tauon> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: "Theodore Ts'o" , LKML , linux-crypto@vger.kernel.org To: Stephan Mueller Return-path: Received: from mail-vb0-f47.google.com ([209.85.212.47]:38653 "EHLO mail-vb0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756081Ab3JNPSS (ORCPT ); Mon, 14 Oct 2013 11:18:18 -0400 In-Reply-To: <3593500.a7fOuGKlEX@tauon> Sender: linux-crypto-owner@vger.kernel.org List-ID: On Mon, Oct 14, 2013 at 10:40 AM, Stephan Mueller wrote: > Another thing: when you start adding whitening functions, other people > are starting (and did -- thus I added section 4.3 to my documentation) > to complain that you hide your weaknesses behind the whiteners. I simply > want to counter that argument and show that RNG produces white noise > without a whitener. Yes, you absolutely have to test the unwhitened input entropy, and provide a way for others to test it so they can have confidence in your code and it can be tested again if it is going to be used on some new host. You do a fine job of that; your paper has the most detailed analysis I have seen. Bravo. However, having done that, I see no reason not to add mixing. Using bit() for getting one bit of input and rotl(x) for rotating left one bit, your code is basically, with 64-bit x: for( i=0, x = 0 ; i < 64; i++, x =rotl(x) ) x |= bit() Why not declare some 64-bit constant C with a significant number of bits set and do this: for( i=0, x = 0 ; i < 64; i++, x =rotl(x) ) // same loop control if( bit() ) x ^= C ; This makes every output bit depend on many input bits and costs almost nothing extra. In the unlikely event that the overhead here matters, your deliberately inefficient parity calculation in bit() could easily be made faster to compensate.