Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sun, 8 Aug 2004 11:38:46 -0400 | From | Jean-Luc Cooke <> | Subject | Re: [PATCH] |
| |
Glad to have you join the discussion Ted!
On Sat, Aug 07, 2004 at 06:26:34PM -0400, Theodore Ts'o wrote: > On Fri, Aug 06, 2004 at 08:54:27AM -0400, Jean-Luc Cooke wrote: > > That and it's not endian-correct. 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!?!), > > This was deliberate becasue sequence number generation could not be > slow for some workloads. The sequence number attacks that MD4 > protects against are tcp hijacking attacks where the attacker is on > the network path ---- if you really want security you'd be using real > crypto for encryption and for integrity protection at the application > layer.
In our paper (I'm testing the patch now) we'll be proposing using the Fortuna PRNG inplace of the current design. It only uses SHA256 and AES256 (or any message digest & block cipher combo). The primary advantages of this design would be: - It's simpler - It's faster - It doesn't "rool your own" crypto
> > the use of LFSRs for "mixing" when they're linear, > > the polymonials used are not even primitive, > > The basic idea here is that you can mix in arbitrary amounts of zero > data without destroying the randomness of the pool. This is > important, and was an explicit design goal.
If you pass all input data into a Yarrow-type PRNG - like the Fortuna PRNG we're going to propose - you will never care about this since the current state of the pools are always based on all the previous input.
> > 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). > > Yawn. Root has access to /dev/mem. Your point?
I guess the point I was trying to make was: - You never want to wipe out the pool - You never want to let people (not even yourself) get access to the pool The closest thing you can do (and the paper will explain this) is hash a counter and the data from each of your pools though a message digest and concatenate it together.
I'm really putting the horse infront of the cart here. We'll put a paper up for lkml to read by the end of the month which will fully explain: - Our reasoning - Our goals - Our results
Cheers,
JLC - 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/
| ![\](/images/icornerr.gif) |