public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Stephan Mueller <smueller@chronox.de>
Cc: Pavel Machek <pavel@ucw.cz>,
	sandy harris <sandyinchina@gmail.com>,
	linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
	Nicholas Mc Guire <der.herr@hofr.at>
Subject: Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random
Date: Wed, 6 Nov 2013 08:04:32 -0500	[thread overview]
Message-ID: <20131106130432.GK14235@thunk.org> (raw)
In-Reply-To: <9172761.DO0L6FkY0c@tauon>

On Wed, Nov 06, 2013 at 01:51:17PM +0100, Stephan Mueller wrote:
> >That's unfortunate, since it leaves open the question of whether this
> >jitter is something that could be at least somewhat predictable if you
> >had a lot more information about the internal works of the CPU or
> >not....
> 
> I do not understand that answer: I thought we are talking about the 
> search of non-predictable noise sources. If you cannot predict the 
> sequence even if you have the state of the CPU, that is what we are 
> looking for, is it not?

I was asking the question about whether someone who knew more about
the internal _workings_ of the CPU, note of the state of the CPU.
This is not necessarily "the NSA guy", but someone who knows more
about the internal workings of the Intel CPU (such as an Intel
engineer --- and I've had Intel express misgivings about approaches
which depend on "CPU jitter" approaches), or just someone who has
spent a lot more time trying to examine the black box of the Intel CPU
from the outside.

I remember making my own home-grown encryption algorithm before I
entered college, secure in my arrogance that I had created something
so complicated that no one could crack it.  Of course, as I got older
and wiser, I realized that it just meant it was just something *I*
couldn't yet anaylze and crack.  The argument "the internal state of
the CPU is sooooo large, and the state transitions ar sooooo complex
that it *must* be unpredictable, because *I* can't predict them" seems
to be a very similar mistake that I made many years ago when I was in
high school.

Of course, some of the state in the CPU may not be unknown to the
attacker, if it is derived by external events that are not visible to
the attacker, such as a network interrupt.  But if that's the case,
why not measure network interrupts directly?  We're much less likely
to overestimate the amount of entropy we can extract the system in
that case.

> Also, does your answer mean you would disregard radioactive decay that 
> is not predictable due to quantum physics and Heisenberg?

No, because that's uncertainty that we can tie to a physical source.
My concern about CPU state is that we haven't yet tied that to a
physical source of entropy, or to exactly what external inputs that
are not available to an external attacker.  We know that quantum
events are not predictable.  We also know that digital circuits in
general are very carefully designed to *be* predictable.

Regards,

						- Ted

  reply	other threads:[~2013-11-06 13:04 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-11 18:38 [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random Stephan Mueller
2013-10-12  1:45 ` Sandy Harris
2013-10-12  3:28   ` Theodore Ts'o
2013-10-12 19:04     ` Stephan Mueller
2013-10-12 20:12   ` Stephan Mueller
     [not found]     ` <CACXcFm=_jmeKe2YYbHDi-jTGX-23hDsDeu_weWQkr2F_FpE_6g@mail.gmail.com>
2013-10-14 13:38       ` Fwd: " Sandy Harris
2013-10-14 14:12         ` Stephan Mueller
2013-10-14 14:26           ` Stephan Mueller
2013-10-14 14:14         ` Sandy Harris
2013-10-14 14:40           ` Stephan Mueller
2013-10-14 15:18             ` Sandy Harris
2013-10-14 15:26               ` Stephan Mueller
2013-10-14 15:46                 ` Sandy Harris
2013-10-14 21:33                 ` Sandy Harris
2013-10-15  6:23               ` Stephan Mueller
2013-10-28 15:40 ` Stephan Mueller
2013-10-28 16:06   ` Henrique de Moraes Holschuh
2013-10-28 16:15     ` Stephan Mueller
2013-10-28 21:45   ` Theodore Ts'o
2013-10-29  8:42     ` Stephan Mueller
2013-10-29 13:24       ` Theodore Ts'o
2013-10-29 14:00         ` Stephan Mueller
2013-10-29 22:25           ` Stephan Mueller
2013-11-02 11:01           ` Pavel Machek
2013-11-02 11:12             ` Pavel Machek
2013-11-03  7:20             ` Stephan Mueller
2013-11-03 12:41               ` Theodore Ts'o
2013-11-05 12:20                 ` Stephan Mueller
2013-11-06 11:49                   ` Stephan Mueller
2013-11-06 12:43                     ` Theodore Ts'o
2013-11-06 12:51                       ` Stephan Mueller
2013-11-06 13:04                         ` Theodore Ts'o [this message]
2013-11-06 13:24                           ` Pavel Machek
2013-11-07  0:36                             ` Nicholas Mc Guire
2013-11-07  5:21                           ` Stephan Mueller
2013-11-09 22:04                             ` Clemens Ladisch
2013-11-10  1:10                               ` Stephan Mueller
2013-11-10 16:31                                 ` Clemens Ladisch
2013-11-10 17:21                                   ` Stephan Mueller
2013-11-10 20:28                                     ` Clemens Ladisch
2013-11-13  3:12                                       ` Stephan Mueller
2013-11-13 11:51                                         ` Clemens Ladisch
2013-11-13 15:15                                           ` Stephan Mueller
2013-11-13 17:14                                             ` Pavel Machek
2013-11-14 10:51                                             ` Clemens Ladisch
2013-11-14 18:01                                               ` Stephan Mueller
2013-11-14 18:30                                                 ` Clemens Ladisch
2013-11-14 18:34                                                   ` Stephan Mueller
2013-11-11  2:58                                     ` H. Peter Anvin
2013-11-07  1:03                         ` Nicholas Mc Guire
2013-11-07  5:26                           ` Stephan Mueller
2013-11-09 22:04                             ` Clemens Ladisch
2013-11-10  1:16                               ` Stephan Mueller
2013-11-03 23:32               ` Pavel Machek
2013-11-05 12:25                 ` Stephan Mueller
2013-11-05 13:45                   ` Stephan Mueller
2013-11-06 11:42                     ` Stephan Mueller
2013-11-06 13:26                       ` Pavel Machek
2013-11-07  3:12                         ` Stephan Mueller
2013-11-13  3:37         ` [PATCH] CPU Jitter RNG: Executing time variation tests on bare metal Stephan Mueller
2013-10-30 12:59     ` [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random 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=20131106130432.GK14235@thunk.org \
    --to=tytso@mit.edu \
    --cc=der.herr@hofr.at \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=sandyinchina@gmail.com \
    --cc=smueller@chronox.de \
    /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