linux-kernel - Re: random(4) changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4191223.qhyOqInRhP@tauon.atsec.com>
Date:	Fri, 29 Apr 2016 13:18:09 +0200
From:	Stephan Mueller <smueller@...onox.de>
To:	George Spelvin <linux@...izon.com>
Cc:	herbert@...dor.apana.org.au, linux-crypto@...r.kernel.org,
	linux-kernel@...r.kernel.org, sandyinchina@...il.com, tytso@....edu
Subject: Re: random(4) changes

Am Freitag, 29. April 2016, 07:04:24 schrieb George Spelvin:

Hi George,

> > I think there is a slight mixup: IID is not related to an attacker
> > predicting things. IID is simply a statistical measure, it is either there
> > or not. It does not depend on an attacker (assuming that the attacker
> > cannot change the data). Note, the IID is only needed to claim that the
> > XOR will be entropy preserving.
> 
> 1. It DOES depend on the attacker.  Any statement about independence
>    depends on the available knowledge.
> 2. XOR being entropy preserving depends on independence ONLY, it does
>    NOT depend on identical distribution.  The latter is a red herring.
>    (An English metaphor for "irrelevant distraction.")
> 3. Precisely because the bits are not independent, XOR is not
>    guaranteed to be entropy-preserving (your sense) on real data.

It seems we talk past each other. Your entire explanation refers to individual 
bits that come in sequentially where the attacker inbetween can analyze it and 
potentially modify his attack. Sure, in this case they are not independent and 
I am not claiming that.

But one single time stamp is one value where the entire 32 bits are generated 
in an atomic fashion to any observer -- there is no sequential obtaining of 
its bits, analyzing it and then reacting on it. Each of those bits are set 
independently from the others. So, when an attacker looks at it, the entire 32 
bits are already there. Hence there is no changing in a distribution by simply 
looking at it.

So, take one RDTSC value and slice it into the individual bits. You cannot 
predict the 32nd bit when known the first 31 bits. You can only predict the 
32nd bit if you know the previous time stamps.

Again, I know that when seeing two or more time stamps, they are depending on 
each other. And for processing these multiple time stamps I use concatenation 
which is not affected by dependencies.

Ciao
Stephan