From: "George Spelvin" <linux@horizon.com>
To: linux@horizon.com, smueller@chronox.de
Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, sandyinchina@gmail.com,
tytso@mit.edu
Subject: Re: random(4) changes
Date: 29 Apr 2016 07:04:24 -0400 [thread overview]
Message-ID: <20160429110424.641.qmail@ns.horizon.com> (raw)
In-Reply-To: <4528395.Mi7xQggM5z@tauon.atsec.com>
> 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.
To give a specific example, suppose that an attacker can predict that the
counter will be either x or x+1 on the upcoming sample. For simplicity,
assume the probabilites are exactly 50%, so there is one full bit of
entropy in the lsbit.
But if x ends in ..01, then x+1 ends in ..10, and they have the same
XOR, and the attacker knows (0 bits if entropy) the XOR of the bottom
two bits even though they know nothing about the bottom bit in isolation.
>>> There is absolutely no limit to the 32 bits. We easily can take the high
>>> bits too. But we know (as you mention below), an attacker has more and
>>> more knowledge about the selected bits the higher the bit is as he can
>>> predict an event with a certain degree of probability.
>> Yes, an attacker has more information about higher bits.
>>
>> This is the defintion of NOT identically distributed!
> So, you are saying that by looking at data, you change their statistical
> distribution?
Yes.
For example, if I have seen the previous sample and it is 0x00000000,
I know that the distribution of the msbit of the following sample
is heavily biased toward 0.
If I have seen the previous sample and it is 0x7fffffff, I know that the
distribution of the msbit is heavily biased toward 1.
If I had not looked at the preceding samples, I would not be able
to draw those conclusions.
Remember, the following sample doesn't have a distribution; it is a
future fact. The only thing that has a distribution is my advance
knowledge (prediction) of that fact.
>> *If* they were identically distributed, a suggestion I'm pointing
>> out the ridiculous implications of, then an attacker's knowledge
>> of each of them would be identical.
> Not at all, you mix the attackers knowledge again with a pure statistical
> property.
I don't understand what a "pure statistical property" means.
The distribution of a single independent bit can be described
completely by giving the probability of it being 1.
In the absence of correlations (dependencies), this single number
completely describes the attacker's knowledge of the bit.
Several bits have identical distributions if and only if the
probability of their being 1 is identical.
This is the same as saying that the attacker's knowledge of the
bits is identical.
next prev parent reply other threads:[~2016-04-29 11:04 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5279345.Lo7T948V4W@positron.chronox.de>
2016-04-26 20:43 ` random(4) changes George Spelvin
2016-04-26 21:01 ` Stephan Mueller
2016-04-27 0:23 ` George Spelvin
2016-04-27 18:03 ` George Spelvin
2016-04-28 20:15 ` Stephan Mueller
2016-04-29 7:29 ` George Spelvin
2016-04-29 8:02 ` Stephan Mueller
2016-04-29 9:34 ` George Spelvin
2016-04-29 9:53 ` Stephan Mueller
2016-04-29 11:04 ` George Spelvin [this message]
2016-04-29 11:18 ` Stephan Mueller
2016-04-29 18:02 ` George Spelvin
2016-04-29 18:41 ` Stephan Mueller
2016-04-29 20:08 ` George Spelvin
2016-04-29 21:54 ` Stephan Mueller
2016-04-29 22:32 ` George Spelvin
2016-04-29 0:47 ` George Spelvin
2016-04-22 22:27 Sandy Harris
2016-04-23 7:52 ` Stephan Mueller
2016-04-24 2:03 ` Theodore Ts'o
2016-04-24 8:03 ` Stephan Mueller
2016-04-26 3:07 ` Theodore Ts'o
2016-04-26 11:04 ` Herbert Xu
2016-04-26 20:47 ` Andi Kleen
2016-04-27 4:23 ` Herbert Xu
2016-04-26 18:24 ` Stephan Mueller
2016-04-26 18:44 ` Pavel Machek
2016-04-26 18:55 ` Stephan Mueller
2016-04-26 19:41 ` Pavel Machek
2016-04-25 16:06 ` Andi Kleen
2016-04-25 17:25 ` Stephan Mueller
2016-04-25 17:38 ` Andi Kleen
2016-04-25 17:56 ` Stephan Mueller
2016-04-25 19:35 ` Andi Kleen
2016-04-26 12:01 ` Stephan Mueller
2016-04-27 17:47 ` Stephan Mueller
2016-04-26 1:00 ` Theodore Ts'o
2016-04-26 12:42 ` Sandy Harris
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=20160429110424.641.qmail@ns.horizon.com \
--to=linux@horizon.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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