All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Luc Cooke <jlcooke@certainkey.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PROPOSAL/PATCH] Fortuna PRNG in /dev/random
Date: Mon, 27 Sep 2004 15:45:02 -0400	[thread overview]
Message-ID: <20040927194502.GO28317@certainkey.com> (raw)
In-Reply-To: <415861C4.4030604@colorfullife.com>

On Mon, Sep 27, 2004 at 08:53:56PM +0200, Manfred Spraul wrote:
> On Mon, Sep 27, 2004 at 10:55:55AM -0400, Theodore Ts'o wrote:
> >
> >While you're at it, please re-read RFC 793 and RFC 1185.  You still
> >don't have TCP sequence generation done right.
> 
> Actually trying to replace the partial MD4 might be worth an attempt: 
> I'm certain that the partial MD4 is not the best/fastest way to generate 
> sequence numbers.

It infact uses two full SHA1 hashs for tcp sequence numbers (endian and
padding issues aside).  my patch aims to do this in 1 AES256 Encrypt or 2
AES256 encrypts for ipv6.

> >The only real way to settle this would be to ask Jamal and some of the
> >other networking hackers to repeat their benchmarks and see if the AES
> >encryption for every TCP SYN is a problem or not.
> >
> It would be unfair: The proposed implementation is not optimized - e.g. 
> the sequence number generation runs under a global spinlock. On large 
> SMP systems this will kill the performance, regardless of the internal 
> implementation.

This would be nice to have in both RNG implementations.

> For the Linux-variant of RFC 1948, the sequence number generation can be 
> described as:
> A hash function that generates 24 bit output from 96 bit input. Some of 
> the input bits can be chosen by the attacker, all of these bits are 
> known to the attacker. The attacker can query the output of the hash for 
> some inputs - realistically less than 2^16 to 2^20 inputs. A successful 
> attack means guessing the output of the hash function for one of the 
> inputs that the attacker can't query.
> 
> Current implementation:
> Set the MD4 initialization vector to the 96 bit input plus 32 secret, 
> random bits.
> Perform an MD4 hash over 256 secret, random bits.
> Take the lowest 24 bits from one of the MD4 state words.
> Every 5 minutes the secret bits are reset.
> 
> For IPV6, the requirements are similiar, except that the input is 288 
> bits long.
> 
> --
>    Manfred

  reply	other threads:[~2004-09-27 19:46 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-27 18:53 [PROPOSAL/PATCH] Fortuna PRNG in /dev/random Manfred Spraul
2004-09-27 19:45 ` Jean-Luc Cooke [this message]
2004-09-28  0:07   ` Theodore Ts'o
2004-09-28  2:24     ` Jean-Luc Cooke
2004-09-28 13:46       ` Herbert Poetzl
  -- strict thread matches above, loose matches on Subject: below --
2004-09-24  0:59 linux
2004-09-24  2:34 ` Jean-Luc Cooke
2004-09-24  6:19   ` linux
2004-09-24 21:42   ` linux
2004-09-25 14:54     ` Jean-Luc Cooke
2004-09-25 18:43       ` Theodore Ts'o
2004-09-26  1:42         ` Jean-Luc Cooke
2004-09-26  5:23           ` Theodore Ts'o
2004-09-27  0:50             ` linux
2004-09-27 13:07               ` Jean-Luc Cooke
2004-09-27 14:23               ` Theodore Ts'o
2004-09-27 14:42                 ` Jean-Luc Cooke
2004-09-26  6:46           ` linux
2004-09-26 16:32             ` Jean-Luc Cooke
2004-09-26  2:31       ` linux
2004-09-23 23:43 Jean-Luc Cooke
2004-09-24  4:38 ` Theodore Ts'o
2004-09-24 12:54   ` Jean-Luc Cooke
2004-09-24 17:43     ` Theodore Ts'o
2004-09-24 17:59       ` Jean-Luc Cooke
2004-09-24 20:44         ` Scott Robert Ladd
2004-09-24 21:34         ` Theodore Ts'o
2004-09-25 14:51           ` Jean-Luc Cooke
2004-09-24 18:43       ` James Morris
2004-09-24 19:09         ` Matt Mackall
2004-09-24 20:03         ` Lee Revell
2004-09-24 13:44   ` Jean-Luc Cooke
2004-09-27  4:58 ` Theodore Ts'o
     [not found]   ` <20040927133203.GF28317@certainkey.com>
2004-09-27 14:55     ` Theodore Ts'o
2004-09-27 15:19       ` Jean-Luc Cooke

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=20040927194502.GO28317@certainkey.com \
    --to=jlcooke@certainkey.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.