From: "Theodore Ts'o" <tytso@mit.edu>
To: Jean-Luc Cooke <jlcooke@certainkey.com>
Cc: linux@horizon.com, jmorris@redhat.com, cryptoapi@lists.logix.cz,
linux-kernel@vger.kernel.org
Subject: Re: [PROPOSAL/PATCH] Fortuna PRNG in /dev/random
Date: Sun, 26 Sep 2004 01:23:08 -0400 [thread overview]
Message-ID: <20040926052308.GB8314@thunk.org> (raw)
In-Reply-To: <20040926014218.GZ28317@certainkey.com>
On Sat, Sep 25, 2004 at 09:42:18PM -0400, Jean-Luc Cooke wrote:
> On Sat, Sep 25, 2004 at 02:43:52PM -0400, Theodore Ts'o wrote:
> > You still haven't shown the flaw in the logic. My point is that an
> > over-reliance on crypto primitives is dangerous, especially given
> > recent developments. Fortuna relies on the crypto primitives much
> > more than /dev/random does. Ergo, if you consider weaknesses in
> > crypto primitives to be a potential problem, then it might be
> > reasonable to take a somewhat more jaundiced view towards Fortuna
> > compared with other alternatives.
>
> Correct me if I'm wrong here.
>
> You claimed that the collision techniques found for the UFN design hashs
> (sha0, md5, md5, haval, ripemd) demonstrated the need to not rely on hash
> algorithms for a RNG. Right?
For Fortuna, correct. This is why I believe /dev/random's current
design to be superior.
> And I showed that the SHA-1 in random.c now can produce collisions. So, if
> your argument against the fallen UFN hashs above (SHA-1 is a UFN hash also
> btw. We can probably expect more annoucments from the crypto community in
> early 2005) should it not apply to SHA-1 in random.c?
(1) Your method of "producing collisions" assumed that /dev/random was
of the form HASH("a\0\0\0...") == HASH("a) --- i.e., you were
kvetching about the lack of padding. But we've already agreed that
the padding argument isn't applicable for /dev/random, since it only
hashes block-sizes at the same time. (2) Even if there were real
collisions demonstrated in SHA-1's cryptographic core at some point in
the future, it wouldn't harm the security of the algorithm, since
/dev/random doesn't depend on SHA-1 being resistant against
collisions. (Similarly, HMAC-MD5 is still safe for now since it also
is designed such that the ability to find collisions do not harm its
security. It's a matter of how you use the cryptographic primitives.)
> Or did I misunderstand you? Were you just mentioning the weakened algorithms
> as a "what if they were more serious discoveries? Wouldn't be be nice if we
> didn't rely on them?" ?
That's correct. It is my contention that Fortuna is brittle in this
regard, especially in comparison to /dev/random current design.
And you still haven't pointed out the logic flaw in any argument but
your own.
- Ted
next prev parent reply other threads:[~2004-09-26 5:25 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
2004-09-25 18:43 ` Theodore Ts'o
2004-09-26 1:42 ` Jean-Luc Cooke
2004-09-26 5:23 ` Theodore Ts'o [this message]
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=20040926052308.GB8314@thunk.org \
--to=tytso@mit.edu \
--cc=cryptoapi@lists.logix.cz \
--cc=jlcooke@certainkey.com \
--cc=jmorris@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.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 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.