All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller@chronox.de>
To: George Spelvin <linux@horizon.com>
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: Fri, 29 Apr 2016 11:53:32 +0200	[thread overview]
Message-ID: <4528395.Mi7xQggM5z@tauon.atsec.com> (raw)
In-Reply-To: <20160429093418.14458.qmail@ns.horizon.com>

Am Freitag, 29. April 2016, 05:34:18 schrieb George Spelvin:

Hi George,

> (Note that we have two chains of e-mails crossing mid-stream.  I'm in
> the middle of working on a much longer reply to your previous e-mail.)
> 
> >> They're not independent, nor are they identically distributed.
> > 
> > That is an interesting statement: you say that the time stamp has holes
> > in it, i.e. some values have zero probability of being selected!
> 
> That's not at all what I said.  It may be true, depending on Intel's
> TSC implementation, but I didn't say or imply it.
> 
> > Second, you imply that when bit x of a given time stamp has some
> > particular value, bit y can be deduced from bit x.
> 
> Yes.  For example, bit 30 can be deduced from bit 31, given our
> assumption that the attacker has knowledge of previous timestamps, and
> likely inter-interrupt times.  If bit 31 has changed, bit 30 is almost
> certainly zero.  The bits are not independent.

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.

The reason that the IID on a statistical level is preserved is due to the fact 
that that an attacker can only observe the values, but not manipulate them 
(i.e. set the bits in a time stamp depending on other bits in that very time 
stamp).

Hence, the attacker may cause that some bits have zero or little entropy, but 
he cannot change the statistical pattern of the bits. This is the key 
requirement why the XOR can be applied here: statistical independent bits, 
where some bits may not have any entropy.

The relativity of an attacker comes in when you want to determine how much 
entropy a particular bit has. And here, the higher the bit is the lower the 
entropy as the attacker has more and more likelihood to guess the bit 
correctly.
> 
> The distribution of bit 31 is, with very high probability, equal to that
> in the previous timestamp.  Bit 0, not so much.
> 
> In other words, bits 31 and 0 have different distributions.  They are
> not identically distributed.
> 
> I gave this example in my previous e-mail
> Message-ID: <20160429004748.9422.qmail@ns.horizon.com>
> 
> >> If they were identically distributed, they'd all have identical
> >> entropy.  And there's be no reason to stop at 32 bits.  If the high
> >> 32 bits have the same entropy as the low
> >> entropy too?.
> > 
> > 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?
> 
> *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.


Ciao
Stephan

  reply	other threads:[~2016-04-29  9:53 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-26  1:59 random(4) changes George Spelvin
2016-04-26 18:43 ` Stephan Mueller
2016-04-26 20:43   ` 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 [this message]
2016-04-29 11:04                   ` George Spelvin
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
  -- strict thread matches above, loose matches on Subject: below --
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=4528395.Mi7xQggM5z@tauon.atsec.com \
    --to=smueller@chronox.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=sandyinchina@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.