From: linux@horizon.com
To: jlcooke@certainkey.com
Cc: daw@taverner.cs.berkeley.edu, linux-kernel@vger.kernel.org,
mpm@selenic.com, tytso@mit.edu
Subject: Re: Fortuna
Date: 16 Apr 2005 16:30:25 -0000 [thread overview]
Message-ID: <20050416163025.10962.qmail@science.horizon.com> (raw)
In-Reply-To: <20050416150609.GC17029@certainkey.com>
> Correct me if I'm wrong here, but uniformity of the linear function isn't
> sufficent even if we implemented like this (right now it's more a+X than
> a <dot> X).
>
> The part which suggests choosing an irreducible poly and a value "a" in the
> preprocessing stage ... last I checked the value for a and the poly need to
> be secret. How do you generate poly and a, Catch-22? Perhaps I'm missing
> something and someone can point it out.
No, the value (the parameter pi) are specifically described as "the public
parameter". See the "Preprocessing" paragraph at the end of section 1.2
on page 3. "This string is then hardwired into the implementation and
need not be kept secret."
All that's required is that the adversary can't tailor his limited
control over the input based on knowing pi.
There's a simple proof in all the papers that if an adversary knows
*everything* about the randomness extraction function, and has total
control over the input distribution, you're screwed.
Basically, suppose you have a 1024-bit input block, the attacker
is required to choose a distribution with at least 1023 bits of entropy,
and you only want 1 bit out. Should be easy, right?
Well, with any *fixed* function, the possible inputs are divided into
those that hash to 0, and those that hash to 1. One of those sets
must have at least 2^1023 members. Suppose it's 0. The attacker can
choose the input distribution to be "uniformly at random from the
>= 2^1023 inputs that hash to 0" and keep the promise while totally
breaking your extraction function.
But this paper says that if the attacker has to choose 2^t possible
input distributions (based on t bits of control over the input)
*before* the random parameter pi is chosen, then they're locked out.
*After* learning pi, they can choose *which* of the 2^t input
distributions to use.
The thing is, you need a parameterized family of hash functions.
They choose a random multiplier mod GF(2^n). Their construction
is based on the well-known 2-universal family of hash functions
hash(x) = (a*x+b) mod p.
The /dev/random input mix is based on choosing a "random" polynomial
(since there was a lot of efficiency pressure, it isn't actually very
random; the question is, is it non-random enough to help an attacker).
Remiander modulo a uniformly chosen random irreducible polynomial is a
well-known ("division hash") family of universal hash functions, but
it's a little bit weaker than the above, and I have to figure out of
the proof extends.
next prev parent reply other threads:[~2005-04-16 16:30 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 ` linux [this message]
2005-04-17 0:37 ` Fortuna David Wagner
2005-04-16 23:40 ` Fortuna David Wagner
2005-04-17 0:36 ` Fortuna David Wagner
-- 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=20050416163025.10962.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=daw@taverner.cs.berkeley.edu \
--cc=jlcooke@certainkey.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®