Messages in this thread | | | Date | Fri, 6 Aug 2004 18:24:52 -0500 | From | Matt Mackall <> | Subject | Re: [PATCH] |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |