public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: linux@horizon.com
Cc: jlcooke@certainkey.com, linux-kernel@vger.kernel.org, mpm@selenic.com
Subject: Re: Fortuna
Date: Fri, 15 Apr 2005 10:42:16 -0400	[thread overview]
Message-ID: <20050415144216.GA9352@thunk.org> (raw)
In-Reply-To: <20050415013417.3536.qmail@science.horizon.com>

On Fri, Apr 15, 2005 at 01:34:17AM -0000, linux@horizon.com wrote:
> (Speaking of which, perhaps it's time, in light of the breaking of MD5,
> to revisit the cut-down MD4 routine used in the TCP ISN selection?
> I haven't read the MD5 & SHA1 papers in enough detail to understand the
> flaw, but perhaps some defenses could be erected?)

The ISN selection is there only to make it harder to accomplish TCP
hijacking attacks from people who are on networking path between the
source and destination.  And you have to guess the ISI before the
3-way TCP handshake has been negotiated (or if you can stop the SYN
packet in flight, before the other side times out the attempted TCP
connection); and we also rekey every few minutes, so even if you do
figure out the seed that we are using to generate the ISI (which is
harder than just merely finding a hash collision; find the preimage
that we are using as a seed given the only a portion of the crypto
hash output), it becomes useless and you have to start all over again
within a few minutes.

Furthermore, if you really cared about preventing TCP hijacks, the
only real way to do this is to use Real Crypto.  And these days, Cisco
boxes support Kerberized telnets and ssh connections, which is the
real Right Answer.

It might be possible to use a more expensive crypto primitive here,
since CPU's have gotten so much faster, but the reason why we moved to
MD4, and then cut it down, was because otherwise it was causing a
noticeable difference in the speed we could establish TCP connections,
and hence for certain network-based benchmarks.

> Just to be clear, I don't remember it ever throwing entropy away, but
> it hoards some for years, thereby making it effectively unavailable.
> Any catastrophic reseeding solution has to hold back entropy for some
> time.

It depends on how often you reseed, but my recollection was that it
was far more than years; it was *centuries*.  And as far as I'm
concerned, that's equivalent to throwing it away, especially given the
pathetically small size of the Fortuna pools.

							- Ted

  reply	other threads:[~2005-04-15 14:42 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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     ` Theodore Ts'o [this message]
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
  -- 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-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 ` Fortuna David Wagner
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=20050415144216.GA9352@thunk.org \
    --to=tytso@mit.edu \
    --cc=jlcooke@certainkey.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=mpm@selenic.com \
    /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