mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: linux@horizon.com
To: jlcooke@certainkey.com
Cc: cryptoapi@lists.logix.cz, jmorris@redhat.com,
	linux-kernel@vger.kernel.org, linux@horizon.com, tytso@mit.edu
Subject: Re: [PROPOSAL/PATCH] Fortuna PRNG in /dev/random
Date: 27 Sep 2004 00:50:33 -0000	[thread overview]
Message-ID: <20040927005033.14622.qmail@science.horizon.com> (raw)
In-Reply-To: <20040926052308.GB8314@thunk.org>

>> This, I do not recall.  I must have missed it.  Will you please show me
>> two inputs that, when fed to the SHA-1 in random.c, will produce
>> identical output?

> SHA-1 without padding, sure.

> hash("a") = hash("a\0") = hash("a\0\0") = ...
> hash("b") = hash("b\0") = hash("b\0\0") = ...
> hash("c") = hash("c\0") = hash("c\0\0") = ...

And how do I hash one byte with SHA-1 *without padding*?  The only
hashing code I can find in random.c works 64 bytes at a time.
What are the other 63 bytes?

(I agree that that *naive* padding leads to collisions, but random.c
doesn't do ANY padding.)

> I see.  And in the -mm examples, is the code easily readable for other
> os-MemMgt types?  If no, then I guess random.c is not the exception and I
> apologize.

The Linux core -mm code is a fairly legendary piece of Heavy Wizardry.
To paraphrase, "do not meddle in the affairs of /usr/src/linux/mm/, for
it is subtle and quick to anger."  There *are* people who understand it,
and it *is* designed (not a decaying pile of old hacks that *nobody*
understands how it works like some software), but it's also a remarkably
steep learning curve.  A basic overview isn't so hard to acquire, but the
locking rules have subtle details.  There are places where someone very good
noticed that a given lock doesn't have to be taken on a fast path if you
avoid doing certain things anywhere else that you'd think would be legal.

And so if someone tries to add code to do the "obvious" thing, the
lock-free fast path develops a race condition.  And we all know what
fun race conditions are to debug.

Fortunately, some people see this as a challenge and Linux is blessed with
some extremely skilled VM hackers.  And some of them even write and publish
books on the subject.  But while a working VM system can be clear, making it
go fast leads to a certain amount of tension with the clarity goal.

> And the ring-buffer system which delays the expensive mixing stages untill a
> a sort interrupt does a great job (current and my fortuna-patch).  Difference
> being, fortuna-patch appears to be 2x faster.

Ooh, cool!  Must play with to steal the speed benefits.  Thank you!

  reply	other threads:[~2004-09-27  0:50 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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-29 17:10 ` [PROPOSAL/PATCH 2] " Jean-Luc Cooke
2004-09-29 19:31   ` Theodore Ts'o
2004-09-29 20:27     ` Jean-Luc Cooke
2004-09-29 21:40       ` Theodore Ts'o
2004-09-29 21:53       ` Theodore Ts'o
2004-09-29 23:24         ` Jean-Luc Cooke
2004-09-30  0:21         ` Jean-Luc Cooke
2004-09-30  4:23           ` Jean-Luc Cooke
2004-09-30  6:50             ` James Morris
2004-09-30  9:03             ` Felipe Alfaro Solana
2004-09-30 13:36               ` Jean-Luc Cooke
2004-10-01 12:56                 ` Jean-Luc Cooke
2004-09-30 10:46             ` Jan-Benedict Glaw
  -- strict thread matches above, loose matches on Subject: below --
2004-09-27 18:53 [PROPOSAL/PATCH] " Manfred Spraul
2004-09-27 19:45 ` Jean-Luc Cooke
2004-09-28  0:07   ` Theodore Ts'o
2004-09-28  2:24     ` Jean-Luc Cooke
2004-09-28 13:46       ` Herbert Poetzl
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=20040927005033.14622.qmail@science.horizon.com \
    --to=linux@horizon.com \
    --cc=cryptoapi@lists.logix.cz \
    --cc=jlcooke@certainkey.com \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --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®