On Sun, 10 Jun 2001, Barney Wolff wrote:
> 1. It is a misnomer to refer to "shared secret" in RFC 1948. The
> secret is not shared with any entity.
Point taken, I should have worded that differently. I'm not sure what the
correct term is, in this case.
> 2. Implying that because DES can be
1. It is a misnomer to refer to "shared secret" in RFC 1948. The
secret is not shared with any entity.
2. Implying that because DES can be brute-forced that MD5 can be
brute-forced is just silly. Yes, in another 100 years, if Moore's
Law continues to hold, which is unlikely.
Suggestion - writ
Ruslan Ermilov wrote:
>
> On Fri, Jun 08, 2001 at 02:51:42AM -0700, Terry Lambert wrote:
> [...]
> >
> > 6)This adds per-connection state, which is evil
> > when you want a lot of connections: the way to
> > get a lot of connections is to remove as much
> > per-connection st
Mike Silbersack wrote:
>
> On Fri, 8 Jun 2001, Don Lewis wrote:
>
> > Why not combine the two schemes and feed the random
> > per-host data from the cloned route entry into the
> > RFC1948 algorithm? This doesn't solve Terry's objection,
> > though.
>
> That thought had occured to me, but I'm
On Fri, Jun 08, 2001 at 09:37:15AM -0500, Mike Silbersack wrote:
>
> On Fri, 8 Jun 2001, Terry Lambert wrote:
>
> > OK, I read the code. Not to poop the party, but off the top
> > of my head, I have several major objections:
> >
> > 1) You stole the space reserved for the cache status
> >
On Fri, Jun 08, 2001 at 02:51:42AM -0700, Terry Lambert wrote:
[...]
>
> 6)This adds per-connection state, which is evil
> when you want a lot of connections: the way to
> get a lot of connections is to remove as much
> per-connection state as possible, which in turn
>
On Fri, 8 Jun 2001, Don Lewis wrote:
> Why not combine the two schemes and feed the random per-host data from
> the cloned route entry into the RFC1948 algorithm? This doesn't solve
> Terry's objection, though.
That thought had occured to me, but I'm not sure it would actually add any
security
On Jun 8, 12:56am, Mike Silbersack wrote:
} Subject: New TCP sequence number generation algorithm; review needed
[ snip ]
} Q: How does this new patch generate sequence numbers?
}
} A: In short, the patch provides a seperate sequence number space for each
} host. These sequence spaces have
For those interested, I've put up a patch which will show you the ISNs
used for outgoing connections with the new generation method at:
http://www.silby.com/patches/silby_isn_generation_debug.patch
Mike "Silby" Silbersack
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freeb
On Fri, 8 Jun 2001, Terry Lambert wrote:
> OK, I read the code. Not to poop the party, but off the top
> of my head, I have several major objections:
>
> 1)You stole the space reserved for the cache status
> flags; calling it 'tao_flags' would have been more
> honest.
rmx_fille
Mike Silbersack wrote:
> Q: How does this new patch generate sequence numbers?
>
> A: In short, the patch provides a seperate sequence number
> space for each host. These sequence spaces have no
> relation to the sequence spaces of other hosts, and
> are re-randomized whenever a ho
Those who were unable to use the attached patch for whatever reason may
also access it at:
http://www.silby.com/patches/silby_isn_generation.patch
Thanks,
Mike "Silby" Silbersack
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
The included patch implements what I believe to be a superior tcp sequence
number generation algorithm. I'd appreciate comments on all aspects of
the patch. If no objections are raised, I'd like to commit the patch to
-current in a week or so, with -stable following two weeks after.
I'm provid
13 matches
Mail list logo
