Re: [PATCH]

[Matt Mackall]

On Fri, Aug 06, 2004 at 08:54:27AM -0400, Jean-Luc Cooke wrote:
> On Fri, Aug 06, 2004 at 12:42:38AM -0400, James Morris wrote:
> > On Fri, 6 Aug 2004, Jean-Luc Cooke wrote:
> > 
> > > James,
> > >   Back to your question:
> > >     I want to replace the legacy MD5 and the incorrectly implemented SHA-1
> > >     implementations from driver/char/random.c
> > 
> > Incorrectly implemented?  Do you mean not appending the bit count?
> 
> That and it's not endian-correct.

Are you saying that it's hashing incorrectly or that the final form is
not in the standard bit-order? For the purposes of a random number
generator, the latter isn't terribly important. Nor is it particularly
important for GUIDs.

> There are other issues with random.c (lack
> for forward secrecy in the case of seed discovery, use of the insecure MD4 in
> creating syn and seq# for tcp, the use of halfMD4 and twothridsMD4 is
> madness
> (what is 2/3's of 16!?!), the use of LFSRs for "mixing" when they're linear,
> the polymonials used are not even primitive, the ability for root to wipe-out
> the random pool, the ability for root to access the random seed directly, the
> paper I'm co-authoring will explain all of this).
> 
> Basically, the paper will be describing about 12 security problems with the
> current random.c and propose (with patch included) a new design that solves
> all of these, uses crypto-api, uses known crypto primitives, is simpler to
> read
> and analyse and for a bonus is 2x to 4x faster in adding and retrieving data
> from the pool.

Last time I proposed a cryptoapi-based version, I couldn't get any
buy-off on making cryptoapi a non-optional part of the kernel. Looking
forward to your patch/paper.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/