Date: 24 Sep 2004 21:42:30 -0000
Message-ID: <20040924214230.3926.qmail@science.horizon.com>
From: linux@horizon.com
To: jlcooke@certainkey.com
Subject: Re: [PROPOSAL/PATCH] Fortuna PRNG in /dev/random
Cc: cryptoapi@lists.logix.cz, jmorris@redhat.com, linux-kernel@vger.kernel.org,
       tytso@mit.edu
In-Reply-To: <20040924023413.GH28317@certainkey.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1513
Lines: 30

> 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?  You're a little unclear, so I don't want to be attacking strawmen
of my own devising, but are you claiming the failure to do Merkle-Damgaard
padding in the output mixing operation of /dev/random is a WEAKNESS?

If true, this is a level of cluelessness incompatible with being trusted
to design decent crypto.

The entire purpose of Merkle-Damgaard padding (also know as
Merkle-Damgaard strengthening) is to include the length in the data
hashed, to make hashing variable-sized messages as secure as fixed-size
messages.  If what you are hashing is, by design, always fixed-length,
this is completely unnecessary.

If I were designing a protocol for message interchange, I might add
the padding anyway, just to use pre-existing primitives easily, but
for a 100% internal use like a PRNG, let's see... I can reduce code
size AND implementation complexity AND run time without ANY security
consequences, and there are no interoperability issues...

I could argue it's a design flaw to *include* the padding.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/