On Wed, 25 Jul 2001, Barney Wolff wrote:
> I have a few comments :)
>
> 1. Rekeying is completely unnecessary - talking of brute-forcing
> the MD5 of a 32-byte random secret is fantasy, for the forseeable future.
> Similarly, isn_offset adds nothing real to security.
>
> 2. By rekeying you risk violating the monotonicity of the isn across
> the rekeying, which is the whole point of not just doing random isn.
I'll go ahead and remove the isn_offset addition. I'm not really willing
to remove the rekeying, though; we can't say that a faster method of brute
force attack will not arise. Would a longer rekeying interval such as a
day or two suffice? I'm not concerned about rekeying breaking a few
connections given that it will only happen occasionally.
> 3. Unless I'm confused, hz is typically 100 or 1000, meaning that the
> signed-32 tick counters you're relying on to trigger rekeying will
> flip sign and overflow within the typical uptime of a server. You
> risk having the test fail for a long time, if isn_reseed_time is a
> large positive and ticks has become negative before you get to test it.
> Of course that's no loss, imo.
Doh! I'll fix that in the next rev of the patch.
> 4. As a nit, if you're going to do the rekeying check, do it only when
> you're actually going to do the md5 work, not before the test that
> may return arc4random.
Will do as well.
> 5. You seem to have ignored 1948's advice to include some configurable
> secret in the hash - are we really sure that read_random gives good
> bits right after reboot?
I didn't think second-guessing the random dev would be a worthwhile
endeavor, as it would probably just lead to less entropy. (Especially
given that noone would ever set the configureable secret.)
However, boot time randomness is a valid concern. We're slightly lucky in
that the initial keying doesn't occur until the first connection, which
isn't at a fixed time in the kernel startup, but is rather dependant on
usage of the box. I'll check with Mark Murray on this. (And in 4.x, I'll
use read_random_unlimited so that the entropy doesn't get truncated.)
Thanks for the comments,
Mike "Silby" Silbersack
>
> Regards,
> Barney Wolff
>
> On Tue, Jul 24, 2001 at 11:19:57PM -0500, Mike Silbersack wrote:
> >
> > Hello all, the RFC1948-like sequence number generation patch is ready for
> > testing. The patch included will apply cleanly to both a recent -current
> > and a recent -stable. I've spent a good deal of time looking at tcpdump
> > logs, and it looks good to me.
> >
> > Please test and review this if you feel comfortable doing so. If you do
> > not feel comfortable doing so, please simply test it instead. :)
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
