linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Jean-Luc Cooke <jlcooke@certainkey.com>
Cc: James Morris <jmorris@redhat.com>,
	"YOSHIFUJI Hideaki / ?$B5HF#1QL@" <yoshfuji@linux-ipv6.org>,
	mludvig@suse.cz, cryptoapi@lists.logix.cz,
	linux-kernel@vger.kernel.org, davem@redhat.com
Subject: Re: [PATCH]
Date: Mon, 9 Aug 2004 14:43:24 -0400	[thread overview]
Message-ID: <20040809184324.GA22741@thunk.org> (raw)
In-Reply-To: <20040808153846.GR23994@certainkey.com>

On Sun, Aug 08, 2004 at 11:38:46AM -0400, Jean-Luc Cooke wrote:
> In our paper (I'm testing the patch now) we'll be proposing using the Fortuna
> PRNG inplace of the current design.  It only uses SHA256 and AES256 (or any
> message digest & block cipher combo).  The primary advantages of this design
> would be:
>  - It's simpler
>  - It's faster
>  - It doesn't "rool your own" crypto

SHA is not going to be faster than the cut-down MD4 --- and you can't
use a pure random sequence number for the initial TCP sequence number,
lest a packet from a previous TCP connection get mistaken as belong to
the newly created TCP stream.  See Bellovin's recommendations for
secure TCP sequnce number genreation for a discussion of the
constraints.  

> If you pass all input data into a Yarrow-type PRNG - like the Fortuna PRNG
> we're going to propose - you will never care about this since the current
> state of the pools are always based on all the previous input.

The Yarrow-type PRNG suffers from the problem that the entropy pool is
pathetically small.  It fundamentally assumes that the crypto checksum
is secure, and it is really much more of a *P*RNG than anything else.
The scheme used in the current /dev/random design is much closer to
that used by GPG, and relies on a large pool so that we can collect as
much entropy as possible from the hardware sources available to the
kernel.  I'm not familiar with the Fortuna PRNG that you're going to
propose, but my guess is that it will have a similar, much heavier
dependence on the crypto algorithms in terms of its assumptions.

						- Ted

  reply	other threads:[~2004-08-09 18:51 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-05 13:51 [PATCH] Michal Ludvig
2004-08-05 14:11 ` [PATCH] James Morris
2004-08-05 19:49   ` [PATCH] Jean-Luc Cooke
2004-08-06  2:47     ` [PATCH] James Morris
2004-08-06  2:03       ` [PATCH] Michael Halcrow
2004-08-06  4:58         ` [PATCH] Linus Torvalds
2004-08-06 13:03           ` [PATCH] Jean-Luc Cooke
2004-08-06  3:36       ` [PATCH] YOSHIFUJI Hideaki / 吉藤英明
2004-08-06  4:21         ` [PATCH] David S. Miller
2004-08-06  4:28         ` [PATCH] Jean-Luc Cooke
2004-08-06  4:42           ` [PATCH] James Morris
2004-08-06 12:54             ` [PATCH] Jean-Luc Cooke
2004-08-06 18:26               ` [PATCH] David S. Miller
2004-08-06 18:36                 ` [PATCH] Jean-Luc Cooke
2004-08-06 23:24               ` [PATCH] Matt Mackall
2004-08-07  3:01                 ` [PATCH] Jean-Luc Cooke
2004-08-07 22:26               ` [PATCH] Theodore Ts'o
2004-08-08 15:38                 ` [PATCH] Jean-Luc Cooke
2004-08-09 18:43                   ` Theodore Ts'o [this message]
2004-08-09 18:49                     ` [PATCH] Jean-Luc Cooke
2004-08-10  0:22                       ` [PATCH] Theodore Ts'o
  -- strict thread matches above, loose matches on Subject: below --
2022-02-02 21:26 [PATCH] Sergey Shtylyov
2017-07-09 23:58 [PATCH] armetallica
2017-07-09 23:54 ` [PATCH] Kershner, David A
2017-07-09 23:35 [PATCH] armetallica
2017-07-20 15:06 ` [PATCH] Mauro Carvalho Chehab
2013-12-24 15:45 [PATCH] Evan Hosseini
2014-01-09 18:27 ` [PATCH] Greg KH
2012-03-04 20:34 [PATCH] Stefan Richter
2012-03-04 20:36 ` [PATCH] Stefan Richter
2011-08-11 21:29 [PATCH] Rafael J. Wysocki
2010-09-19  2:25 [PATCH] Junio C Hamano
2010-09-19  9:54 ` [PATCH] Sam Ravnborg
2010-09-19 18:21   ` [PATCH] Junio C Hamano
2010-09-19 19:31     ` [PATCH] Sam Ravnborg
2010-09-20 12:11     ` [PATCH] Michal Marek
2010-08-14 12:43 [PATCH] Sam Ravnborg
2009-04-07 16:20 [PATCH] Christoph Hellwig
2008-10-15  7:03 [PATCH] Tim Shimmin
2007-12-03 15:54 [PATCH] Andries E. Brouwer
2007-12-03 17:06 ` [PATCH] Alan Cox
2007-04-01 18:13 [PATCH 0/16] Assorted patches Jan Engelhardt
2007-04-01 18:15 ` [PATCH 07/16] kconfig-dynamic-frequency.diff Jan Engelhardt
2007-04-01 18:39   ` Kyle Moffett
2007-04-01 18:42     ` Jan Engelhardt
2007-04-01 18:52       ` Kyle Moffett
2007-04-01 19:01         ` Jan Engelhardt
2007-04-01 19:42           ` [PATCH] Kyle Moffett
2007-04-01 19:47             ` [PATCH] Jan Engelhardt
2007-04-01 20:07               ` [PATCH] Kyle Moffett
2007-04-01 23:03             ` [PATCH] Andi Kleen
2007-02-21 21:23 [PATCH] James Simmons
2006-07-15 18:43 [PATCH] Chris Boot
2006-03-24 23:07 [PATCH] Daniel Walker
2006-03-24 23:19 ` [PATCH] john stultz
2006-03-24 23:22   ` [PATCH] Daniel Walker
2006-03-10 14:47 [PATCH] Kumar Gala
2006-03-10 15:05 ` [PATCH] Kumar Gala
2005-06-15 11:41 [PATCH] Jan Beulich
2004-11-18 20:17 [PATCH] Colin Leroy
2004-08-10  2:49 [PATCH] Roland McGrath
2003-08-11 13:40 [PATCH] davej
2003-07-30 16:31 [patch] Adrian Bunk
2002-08-06 23:04 [PATCH] Paul Mackerras
2002-04-15 18:39 [PATCH] Andre Hedrick
2002-04-15 19:09 ` [PATCH] Josh McKinney
2002-04-15 19:16   ` [PATCH] Andre Hedrick
2002-04-15 19:59   ` [PATCH] Andre Hedrick
2002-04-16  3:11     ` [PATCH] Josh McKinney
2002-04-16  4:11       ` [PATCH] Andre Hedrick
2002-04-16  5:53 ` [PATCH] Jens Axboe
2002-04-16  6:51   ` [PATCH] Andre Hedrick
2002-04-16  6:54     ` [PATCH] Jens Axboe
2002-04-16  7:04       ` [PATCH] Andre Hedrick
2001-10-25 17:24 [PATCH] Christoph Hellwig
2000-11-07 23:20 [PATCH] Bartlomiej Zolnierkiewicz
2000-11-07 23:09 [PATCH] Bartlomiej Zolnierkiewicz
2000-11-07 23:30 ` [PATCH] Bartlomiej Zolnierkiewicz

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=20040809184324.GA22741@thunk.org \
    --to=tytso@mit.edu \
    --cc=cryptoapi@lists.logix.cz \
    --cc=davem@redhat.com \
    --cc=jlcooke@certainkey.com \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mludvig@suse.cz \
    --cc=yoshfuji@linux-ipv6.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;
as well as URLs for NNTP newsgroup(s).