From: Jean-Luc Cooke <jlcooke@certainkey.com>
To: linux@horizon.com
Cc: jmorris@redhat.com, cryptoapi@lists.logix.cz, tytso@mit.edu,
linux-kernel@vger.kernel.org
Subject: Re: [PROPOSAL/PATCH] Fortuna PRNG in /dev/random
Date: Sat, 25 Sep 2004 10:54:44 -0400 [thread overview]
Message-ID: <20040925145444.GW28317@certainkey.com> (raw)
In-Reply-To: <20040924214230.3926.qmail@science.horizon.com>
On Fri, Sep 24, 2004 at 09:42:30PM -0000, linux@horizon.com wrote:
> > What if I told the SHA-1 implementation in random.c right now is weaker
> > than those hashs in terms of collisions? The lack of padding in the
> > implementation is the cause. HASH("a\0\0\0\0...") == HASH("a") There
> > are billions of other examples.
>
> EXCUSE me?
...
> I could argue it's a design flaw to *include* the padding.
I was trying to point out a flaw in Ted's logic. He said "we've recently
discoverd these hashs are weak because we found collsions. Current
/dev/random doesn't care about this."
I certainly wasn't saying padding was a requirment. But I was trying to
point out that the SHA-1 implementaion crrently in /dev/random by design is
collision vulnerable. Collision resistance isn't a requirment for it's
purposes obviously.
Guess my pointing this out is a lost cause.
JLC
next prev parent reply other threads:[~2004-09-25 14:55 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-24 0:59 [PROPOSAL/PATCH] Fortuna PRNG in /dev/random 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 [this message]
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-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=20040925145444.GW28317@certainkey.com \
--to=jlcooke@certainkey.com \
--cc=cryptoapi@lists.logix.cz \
--cc=jmorris@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.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.