public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: daw@taverner.cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: Fortuna
Date: Sun, 17 Apr 2005 00:36:29 +0000 (UTC)	[thread overview]
Message-ID: <d3sb2d$sbg$1@abraham.cs.berkeley.edu> (raw)
In-Reply-To: 20050416111033.28308.qmail@science.horizon.com

linux wrote:
>Thank you for pointing out the paper; Appendix A is particularly
>interesting.  And the [BST03] reference looks *really* nice!  I haven't
>finished it yet, but based on what I've read so far, I'd like to
>*strongly* recommnd that any would-be /dev/random hackers read it
>carefully.  It can be found at
>http://www.wisdom.weizmann.ac.il/~tromer/papers/rng.pdf

Yeah, [BST03] seems worth reading.  It has a reasonable survey of some
previous work, and is well-written.

However, I'm pretty skeptical about [BST03] as a basis for a real-world
randomness generator.  It assumes that there are only 2^t possible
distributions for the source, and the set of possible distributions has
been fixed in advance (before the design of your randomness generator
is revealed).  Consequently, it fails to defend against adaptive attacks.

If the attacker can feed in maliciously chosen inputs (chosen after the
attacker learns which randomness extraction algorithm you are using),
then the BST03 scheme promises nothing.  For instance, if you feed in
timings of network packets, then even if you don't count them as providing
any entropy, the mere act of feeding them into your randomness generator
causes their theorems to be clearly inapplicable (since no matter what
value of t you pick, the adversary can arrange to get more than t bits
of freedom in the network packets he sends you).

So I'm not sure [BST03]'s theorems actually promise what you'd want.

On the other hand, if you want to take their constructions as providing
some intuition or ideas about how one might build a randomness generator,
while realizing that their theorems don't apply and there may be no
useful guarantees that can be proven about such an approach, I don't
have any objections to that view.

By the way, another example of work along these lines is
http://theory.lcs.mit.edu/~yevgen/ps/2-ext.ps
That paper is more technical and theoretically-oriented, so it might
be harder to read and less immediately useful.  It makes a strong
assumption (that you have two sources that are independent -- i.e.,
totally uncorrelated), but the construction at the heart of their paper
is pretty simple, which might be of interest.

>Happily, it *appears* to confirm the value of the LFSR-based input
>mixing function.  Although the suggested construction in section 4.1 is
>different, and I haven't seen if the proof can be extended.

Well, I don't know.  I don't think I agree with that interpretation.

Let me give a little background about 2-universal hashing.  There is a
basic result about use of 2-universal hash functions, which says that
if you choose the seed K truly at random, then you can use h_K(X) to
extract uniform random bits from a non-uniform source X.  (Indeed, you
can even reveal K without harming the randomness of h_K(X).)  The proof
of this fact is usually known as the Leftover Hashing Lemma.

One of the standard constructions of a 2-universal hash function is
as a LFSR-like scheme, where the seed K is used to select the feedback
polynomial.  But notice that it is critical that the feedback polynomial
be chosen uniformly at random, in a way that is unpredictable to the
attacker, and kept secret until you receive data from the source.

What /dev/random does is quite different from the idea of 2-universal
hashing developed in the theory literature and recounted in [BST03].
/dev/random fixes a single feedback polynomial in advance, and publishes
it for the world to see.  The theorems about 2-universal hashing promise
nothing about use of a LFSR with a fixed feedback polynomial.

  parent reply	other threads:[~2005-04-17  0:38 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-16 11:10 Fortuna linux
2005-04-16 15:06 ` Fortuna Jean-Luc Cooke
2005-04-16 16:30   ` Fortuna linux
2005-04-17  0:37   ` Fortuna David Wagner
2005-04-16 23:40 ` Fortuna David Wagner
2005-04-17  0:36 ` David Wagner [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-04-17  9:21 Fortuna linux
2005-04-16 11:44 Fortuna linux
2005-04-14 14:15 Fortuna linux
2005-04-14 13:33 ` Fortuna Theodore Ts'o
2005-04-15  1:34   ` Fortuna linux
2005-04-15 14:42     ` Fortuna Theodore Ts'o
2005-04-15 15:38       ` Fortuna linux
2005-04-15 18:23         ` Fortuna Theodore Ts'o
2005-04-15 16:22       ` Fortuna Jean-Luc Cooke
2005-04-15 16:50         ` Fortuna linux
2005-04-15 17:04           ` Fortuna Jean-Luc Cooke
2005-04-16 10:05             ` Fortuna linux
2005-04-16 15:46               ` Fortuna Jean-Luc Cooke
2005-04-16 17:16                 ` Fortuna linux
2005-04-16 19:22                   ` Fortuna Matt Mackall
2005-04-16 19:00               ` Fortuna Matt Mackall
2005-04-17  0:19               ` Fortuna David Wagner
2005-04-16  1:28           ` Fortuna David Wagner
2005-04-15 19:34         ` Fortuna Matt Mackall
2005-04-16  1:25   ` Fortuna David Wagner
2005-04-19 19:27   ` Fortuna Patrick J. LoPresti
2005-04-14 14:52 ` Fortuna Jean-Luc Cooke
2005-04-15  0:52   ` Fortuna linux
2005-04-16  1:19   ` Fortuna David Wagner
2005-04-16  1:08 ` Fortuna David Wagner
2005-04-18 19:13   ` Fortuna Matt Mackall
2005-04-18 21:40     ` Fortuna David Wagner
2005-04-19  4:01       ` Fortuna Theodore Ts'o
2005-04-19  4:31         ` Fortuna David Wagner
2005-04-20  7:06           ` Fortuna Theodore Ts'o
2005-04-13 23:43 Fortuna Jean-Luc Cooke
2005-04-14  0:09 ` Fortuna Matt Mackall
2005-04-14  0:26   ` Fortuna Jean-Luc Cooke
2005-04-14  0:44     ` Fortuna Matt Mackall
2005-04-16  1:02       ` Fortuna David Wagner

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='d3sb2d$sbg$1@abraham.cs.berkeley.edu' \
    --to=daw@taverner.cs.berkeley.edu \
    --cc=daw-usenet@taverner.cs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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