linux> It's easy to make a smaller hash by just thowing bits away,
linux> but a block cipher is a permutation, and has to be
linux> invertible.
linux> For example, if I take a k-bit counter and encrypt it with
linux> a k-bit block cipher, the output is guaranteed not to
linux> It's easy to make a smaller hash by just thowing bits away,
linux> but a block cipher is a permutation, and has to be
linux> invertible.
linux> For example, if I take a k-bit counter and encrypt it with
linux> a k-bit block cipher, the output is guaranteed not to
> [EMAIL PROTECTED] writes:
>> (The homebrew 15-bit block cipher in this code does show how much the
>> world needs a small block cipher for some of these applications.)
>
> Doesn't TEA fill this niche? It's certainly used for this in the Linux
> kernel, e.g. in reiserfs (although I have my doubts
[EMAIL PROTECTED] writes:
>
> (The homebrew 15-bit block cipher in this code does show how much the
> world needs a small block cipher for some of these applications.)
Doesn't TEA fill this niche? It's certainly used for this in the Linux
kernel, e.g. in reiserfs (although I have my doubts it is
linux It's easy to make a smaller hash by just thowing bits away,
linux but a block cipher is a permutation, and has to be
linux invertible.
linux For example, if I take a k-bit counter and encrypt it with
linux a k-bit block cipher, the output is guaranteed not to
linux
[EMAIL PROTECTED] writes:
(The homebrew 15-bit block cipher in this code does show how much the
world needs a small block cipher for some of these applications.)
Doesn't TEA fill this niche? It's certainly used for this in the Linux
kernel, e.g. in reiserfs (although I have my doubts it is
[EMAIL PROTECTED] writes:
(The homebrew 15-bit block cipher in this code does show how much the
world needs a small block cipher for some of these applications.)
Doesn't TEA fill this niche? It's certainly used for this in the Linux
kernel, e.g. in reiserfs (although I have my doubts it is
linux It's easy to make a smaller hash by just thowing bits away,
linux but a block cipher is a permutation, and has to be
linux invertible.
linux For example, if I take a k-bit counter and encrypt it with
linux a k-bit block cipher, the output is guaranteed not to
linux
On Thu, Feb 03, 2005 at 11:51:27AM -0800, Stephen Hemminger wrote:
> Recent 2.6 does a more advanced form of port randomization already
> using address hash at connect time. tcp_v4_get_port is only used for
> the case of applications that explicitly bind to port zero to find a
> free port.
Is
On Wed, 02 Feb 2005 18:38:37 +0100
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> wrote:
> El mié, 02-02-2005 a las 17:17 +, [EMAIL PROTECTED] escribió:
> > There *are* things in OpenBSD, like randomized port assignment (as opposed
> > to the linear scan in tcp_v4_get_port()) that would
On Wed, 02 Feb 2005 18:38:37 +0100
Lorenzo Hernández García-Hierro [EMAIL PROTECTED] wrote:
El mié, 02-02-2005 a las 17:17 +, [EMAIL PROTECTED] escribió:
There *are* things in OpenBSD, like randomized port assignment (as opposed
to the linear scan in tcp_v4_get_port()) that would be
On Thu, Feb 03, 2005 at 11:51:27AM -0800, Stephen Hemminger wrote:
Recent 2.6 does a more advanced form of port randomization already
using address hash at connect time. tcp_v4_get_port is only used for
the case of applications that explicitly bind to port zero to find a
free port.
Is any
El mié, 02-02-2005 a las 17:17 +, [EMAIL PROTECTED] escribió:
> There *are* things in OpenBSD, like randomized port assignment (as opposed
> to the linear scan in tcp_v4_get_port()) that would be worth emulating.
> Maybe worry about that first?
>
Completely agreed with you, I was just trying
*Sigh*. This thread is heading into the weeds.
I have things I should be doing instead, but since nobody seems to
actually be looking at what the patch *does*, I guess I'll have
to dig into it a bit more...
Yes, licensing issues need to be resolved before a patch can go in.
Yes, code style
*Sigh*. This thread is heading into the weeds.
I have things I should be doing instead, but since nobody seems to
actually be looking at what the patch *does*, I guess I'll have
to dig into it a bit more...
Yes, licensing issues need to be resolved before a patch can go in.
Yes, code style
El mié, 02-02-2005 a las 17:17 +, [EMAIL PROTECTED] escribió:
There *are* things in OpenBSD, like randomized port assignment (as opposed
to the linear scan in tcp_v4_get_port()) that would be worth emulating.
Maybe worry about that first?
Completely agreed with you, I was just trying to
On Mon, Jan 31, 2005 at 09:03:19PM +0100, Lorenzo Hern?ndez Garc?a-Hierro wrote:
> Arjan, I will give it a further look, is there anything you want to
> comment about it before I start?
>
> I will re-code it to put the helper functions in random.c.
Do it against -mm, please, there are something
Arjan van de Ven wrote:
On Fri, 2005-01-28 at 18:17 +0100, Lorenzo HernÃndez GarcÃa-Hierro
wrote:
Hi,
Attached you can find a split up patch ported from grSecurity [1], as
Linus commented that he wouldn't get a whole-sale patch, I was working
on it and also studying what features of grSecurity can
Arjan van de Ven wrote:
On Fri, 2005-01-28 at 18:17 +0100, Lorenzo Hernndez Garca-Hierro
wrote:
Hi,
Attached you can find a split up patch ported from grSecurity [1], as
Linus commented that he wouldn't get a whole-sale patch, I was working
on it and also studying what features of grSecurity can
On Mon, Jan 31, 2005 at 09:03:19PM +0100, Lorenzo Hern?ndez Garc?a-Hierro wrote:
Arjan, I will give it a further look, is there anything you want to
comment about it before I start?
I will re-code it to put the helper functions in random.c.
Do it against -mm, please, there are something like
> could you please also react to this feedback:
>
> http://marc.theaimsgroup.com/?l=linux-kernel=110698371131630=2
>
> to quote a couple of key points from that very detailed security
> analysis:
>
> " I'm not sure how the OpenBSD code is better in any way. (Notice that
> it uses the same
* Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> wrote:
> > At least the three clause BSD license is GPL compatible.
>
> Yes, AFAIK :)
>
> I will try to follow Arjan's recommendations on using his functions
> instead of obsd ones, even if I think it should be alone in the
> current file.
El lun, 31-01-2005 a las 14:42 -0500, [EMAIL PROTECTED] escribió:
> On Mon, 31 Jan 2005 17:50:25 +0100, Adrian Bunk said:
> > On Sat, Jan 29, 2005 at 04:15:43AM -0500, [EMAIL PROTECTED] wrote:
>
> > > Note that obsd_rand.c started off life as a BSD-licensed file - I was told
> > > that was a
On Mon, 31 Jan 2005 17:50:25 +0100, Adrian Bunk said:
> On Sat, Jan 29, 2005 at 04:15:43AM -0500, [EMAIL PROTECTED] wrote:
> > Note that obsd_rand.c started off life as a BSD-licensed file - I was told
> > that was a show-stopper when I submitted basically the same patch a while
> > back.
> >...
El lun, 31-01-2005 a las 17:50 +0100, Adrian Bunk escribió:
> On Sat, Jan 29, 2005 at 04:15:43AM -0500, [EMAIL PROTECTED] wrote:
> > On Fri, 28 Jan 2005 21:47:45 +0100, Arjan van de Ven said:
> >
> > > as for obsd_get_random_long().. would it be possible to use the
> > > get_random_int() function
On Sat, Jan 29, 2005 at 04:15:43AM -0500, [EMAIL PROTECTED] wrote:
> On Fri, 28 Jan 2005 21:47:45 +0100, Arjan van de Ven said:
>
> > as for obsd_get_random_long().. would it be possible to use the
> > get_random_int() function from the patches I posted the other day? They
> > use the existing
On Mon, 31 Jan 2005 17:50:25 +0100, Adrian Bunk said:
On Sat, Jan 29, 2005 at 04:15:43AM -0500, [EMAIL PROTECTED] wrote:
Note that obsd_rand.c started off life as a BSD-licensed file - I was told
that was a show-stopper when I submitted basically the same patch a while
back.
...
At
El lun, 31-01-2005 a las 14:42 -0500, [EMAIL PROTECTED] escribió:
On Mon, 31 Jan 2005 17:50:25 +0100, Adrian Bunk said:
On Sat, Jan 29, 2005 at 04:15:43AM -0500, [EMAIL PROTECTED] wrote:
Note that obsd_rand.c started off life as a BSD-licensed file - I was told
that was a show-stopper
could you please also react to this feedback:
http://marc.theaimsgroup.com/?l=linux-kernelm=110698371131630w=2
to quote a couple of key points from that very detailed security
analysis:
I'm not sure how the OpenBSD code is better in any way. (Notice that
it uses the same
* Lorenzo Hernández García-Hierro [EMAIL PROTECTED] wrote:
At least the three clause BSD license is GPL compatible.
Yes, AFAIK :)
I will try to follow Arjan's recommendations on using his functions
instead of obsd ones, even if I think it should be alone in the
current file. Also I
El lun, 31-01-2005 a las 17:50 +0100, Adrian Bunk escribió:
On Sat, Jan 29, 2005 at 04:15:43AM -0500, [EMAIL PROTECTED] wrote:
On Fri, 28 Jan 2005 21:47:45 +0100, Arjan van de Ven said:
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the
Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?=
=?ISO-8859-1?Q?Garc=EDa-Hierro?= <[EMAIL PROTECTED]> said:
> Attached you can find a split up patch ported from grSecurity [1], as
> Linus commented that he wouldn't get a whole-sale patch, I was working
> on it and also studying what features of
* Lorenzo Hernández García-Hierro:
> As it's impact is minimal (in performance and development/maintenance
> terms), I recommend to merge it, as it gives a basic prevention for the
> so-called system fingerprinting (which is used most by "kids" to know
> how old and insecure could be a target
On Fri, 28 Jan 2005 21:47:45 +0100, Arjan van de Ven said:
> as for obsd_get_random_long().. would it be possible to use the
> get_random_int() function from the patches I posted the other day? They
> use the existing random.c infrastructure instead of making a copy...
>
> I still don't
On Fri, 2005-01-28 at 23:12 +0100, Lorenzo HernÃndez GarcÃa-Hierro
wrote:
> El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribiÃ:
> > as for obsd_get_random_long().. would it be possible to use the
> > get_random_int() function from the patches I posted the other day? They
> > use the
On Fri, 2005-01-28 at 23:12 +0100, Lorenzo HernÃndez GarcÃa-Hierro
wrote:
> El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribiÃ:
> > as for obsd_get_random_long().. would it be possible to use the
> > get_random_int() function from the patches I posted the other day? They
> > use the
On Fri, 2005-01-28 at 23:12 +0100, Lorenzo Hernndez Garca-Hierro
wrote:
El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribi:
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the patches I posted the other day? They
use the existing
On Fri, 2005-01-28 at 23:12 +0100, Lorenzo Hernndez Garca-Hierro
wrote:
El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribi:
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the patches I posted the other day? They
use the existing
On Fri, 28 Jan 2005 21:47:45 +0100, Arjan van de Ven said:
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the patches I posted the other day? They
use the existing random.c infrastructure instead of making a copy...
I still don't understand
* Lorenzo Hernández García-Hierro:
As it's impact is minimal (in performance and development/maintenance
terms), I recommend to merge it, as it gives a basic prevention for the
so-called system fingerprinting (which is used most by kids to know
how old and insecure could be a target system,
Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?=
=?ISO-8859-1?Q?Garc=EDa-Hierro?= [EMAIL PROTECTED] said:
Attached you can find a split up patch ported from grSecurity [1], as
Linus commented that he wouldn't get a whole-sale patch, I was working
on it and also studying what features of
> It adds support for advanced networking-related randomization, in
> concrete it adds support for TCP ISNs randomization
Er... did you read the existing Linux TCP ISN generation code?
Which is quite thoroughly randomized already?
I'm not sure how the OpenBSD code is better in any way. (Notice
Stephen Hemminger <[EMAIL PROTECTED]> writes:
> On Fri, 28 Jan 2005 12:45:17 -0800
> "David S. Miller" <[EMAIL PROTECTED]> wrote:
>
>> On Fri, 28 Jan 2005 21:34:52 +0100
>> Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> wrote:
>>
>> > Attached the new patch following Arjan's
El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribió:
> as for obsd_get_random_long().. would it be possible to use the
> get_random_int() function from the patches I posted the other day? They
> use the existing random.c infrastructure instead of making a copy...
As seen at
On Fri, 28 Jan 2005 13:34:08 -0800
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> per-cpu would be the way to go here.
Does the sbox get somehow seeded from use to use?
If not, then yes that's the thing to do.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Fri, 28 Jan 2005 12:45:17 -0800
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> On Fri, 28 Jan 2005 21:34:52 +0100
> Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> wrote:
>
> > Attached the new patch following Arjan's recommendations.
>
> No SMP protection on the SBOX, better look into
On Fri, 28 Jan 2005 21:34:52 +0100
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> wrote:
> Attached the new patch following Arjan's recommendations.
No SMP protection on the SBOX, better look into that.
The locking you'll likely need to add will make this
routine serialize many networking
On Fri, 2005-01-28 at 21:34 +0100, Lorenzo HernÃndez GarcÃa-Hierro
wrote:
> Hi,
>
> Attached the new patch following Arjan's recommendations.
> I'm sorry about not making it "inlined", but my mail agent messes up the
> diffs if I do so.
> Still waiting for the OSDL STP tests results, they will
Hi,
Attached the new patch following Arjan's recommendations.
I'm sorry about not making it "inlined", but my mail agent messes up the
diffs if I do so.
Still waiting for the OSDL STP tests results, they will take a while to
finish.
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
On Fri, Jan 28, 2005 at 06:47:55PM +0100, Lorenzo Hernández García-Hierro wrote:
> El vie, 28-01-2005 a las 18:40 +0100, Adrian Bunk escribió:
> > On Fri, Jan 28, 2005 at 06:17:17PM +0100, Lorenzo Hernández García-Hierro
> > wrote:
> > >...
> > > As it's impact is minimal (in performance and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2005-01-28, Stephen Hemminger said on linux-kernel:
> "Randomized IP IDs hinders OS fingerprinting and will keep your
> machine from being a bounce for an untraceable portscan."
>
> References: [1]:
>
El vie, 28-01-2005 a las 10:52 -0800, Stephen Hemminger escribió:
> On Fri, 28 Jan 2005 19:31:50 +0100
> When I did the port randomization patch the benchmark that was most impacted
> was LMBENCH. The biggest change was in the communications latency results.
>
> If you want, you can sign up for
On Fri, 28 Jan 2005 19:31:50 +0100
L
> > Okay, but:
> > * Need to give better explanation of why this is required,
> > existing randomization code in network is compromise between
> > performance and security. So you need to quantify the performance
> > impact of this, and the security
El vie, 28-01-2005 a las 10:18 -0800, Stephen Hemminger escribió:
> This is a very transitory effect, it works only because your machine
> is then different from the typical Linux machine; therefore the scanner
> will go on to the next obvious ones. But if this gets incorporated widely
> then the
El vie, 28-01-2005 a las 19:07 +0100, Arjan van de Ven escribió:
> On Fri, 2005-01-28 at 18:17 +0100, Lorenzo Hernández García-Hierro
> wrote:
> > Hi,
> >
> > Attached you can find a split up patch ported from grSecurity [1], as
> > Linus commented that he wouldn't get a whole-sale patch, I was
El vie, 28-01-2005 a las 10:02 -0800, Stephen Hemminger escribió:
> > Attached you can find a split up patch ported from grSecurity [1], as
> > Linus commented that he wouldn't get a whole-sale patch, I was working
> > on it and also studying what features of grSecurity can be implemented
> >
On Fri, 28 Jan 2005 18:47:55 +0100
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> wrote:
> El vie, 28-01-2005 a las 18:40 +0100, Adrian Bunk escribió:
> > On Fri, Jan 28, 2005 at 06:17:17PM +0100, Lorenzo Hernández García-Hierro
> > wrote:
> > >...
> > > As it's impact is minimal (in
On Fri, 2005-01-28 at 18:17 +0100, Lorenzo HernÃndez GarcÃa-Hierro
wrote:
> Hi,
>
> Attached you can find a split up patch ported from grSecurity [1], as
> Linus commented that he wouldn't get a whole-sale patch, I was working
> on it and also studying what features of grSecurity can be
> Attached you can find a split up patch ported from grSecurity [1], as
> Linus commented that he wouldn't get a whole-sale patch, I was working
> on it and also studying what features of grSecurity can be implemented
> without a development or maintenance overhead, aka less-invasive
>
On Fri, 28 January 2005 18:17:17 +0100, Lorenzo Hernández García-Hierro wrote:
>
> Attached you can find a split up patch ported from grSecurity [1], as
> Linus commented that he wouldn't get a whole-sale patch, I was working
> on it and also studying what features of grSecurity can be
El vie, 28-01-2005 a las 18:40 +0100, Adrian Bunk escribió:
> On Fri, Jan 28, 2005 at 06:17:17PM +0100, Lorenzo Hernández García-Hierro
> wrote:
> >...
> > As it's impact is minimal (in performance and development/maintenance
> > terms), I recommend to merge it, as it gives a basic prevention for
On Fri, Jan 28, 2005 at 06:17:17PM +0100, Lorenzo Hernández García-Hierro wrote:
>...
> As it's impact is minimal (in performance and development/maintenance
> terms), I recommend to merge it, as it gives a basic prevention for the
> so-called system fingerprinting (which is used most by "kids" to
On Fri, Jan 28, 2005 at 06:17:17PM +0100, Lorenzo Hernández García-Hierro wrote:
...
As it's impact is minimal (in performance and development/maintenance
terms), I recommend to merge it, as it gives a basic prevention for the
so-called system fingerprinting (which is used most by kids to know
El vie, 28-01-2005 a las 18:40 +0100, Adrian Bunk escribió:
On Fri, Jan 28, 2005 at 06:17:17PM +0100, Lorenzo Hernández García-Hierro
wrote:
...
As it's impact is minimal (in performance and development/maintenance
terms), I recommend to merge it, as it gives a basic prevention for the
On Fri, 28 January 2005 18:17:17 +0100, Lorenzo Hernández García-Hierro wrote:
Attached you can find a split up patch ported from grSecurity [1], as
Linus commented that he wouldn't get a whole-sale patch, I was working
on it and also studying what features of grSecurity can be implemented
On Fri, 2005-01-28 at 18:17 +0100, Lorenzo Hernndez Garca-Hierro
wrote:
Hi,
Attached you can find a split up patch ported from grSecurity [1], as
Linus commented that he wouldn't get a whole-sale patch, I was working
on it and also studying what features of grSecurity can be implemented
Attached you can find a split up patch ported from grSecurity [1], as
Linus commented that he wouldn't get a whole-sale patch, I was working
on it and also studying what features of grSecurity can be implemented
without a development or maintenance overhead, aka less-invasive
implementations.
On Fri, 28 Jan 2005 18:47:55 +0100
Lorenzo Hernández García-Hierro [EMAIL PROTECTED] wrote:
El vie, 28-01-2005 a las 18:40 +0100, Adrian Bunk escribió:
On Fri, Jan 28, 2005 at 06:17:17PM +0100, Lorenzo Hernández García-Hierro
wrote:
...
As it's impact is minimal (in performance and
El vie, 28-01-2005 a las 10:02 -0800, Stephen Hemminger escribió:
Attached you can find a split up patch ported from grSecurity [1], as
Linus commented that he wouldn't get a whole-sale patch, I was working
on it and also studying what features of grSecurity can be implemented
without a
El vie, 28-01-2005 a las 19:07 +0100, Arjan van de Ven escribió:
On Fri, 2005-01-28 at 18:17 +0100, Lorenzo Hernández García-Hierro
wrote:
Hi,
Attached you can find a split up patch ported from grSecurity [1], as
Linus commented that he wouldn't get a whole-sale patch, I was working
El vie, 28-01-2005 a las 10:18 -0800, Stephen Hemminger escribió:
This is a very transitory effect, it works only because your machine
is then different from the typical Linux machine; therefore the scanner
will go on to the next obvious ones. But if this gets incorporated widely
then the
On Fri, 28 Jan 2005 19:31:50 +0100
L
Okay, but:
* Need to give better explanation of why this is required,
existing randomization code in network is compromise between
performance and security. So you need to quantify the performance
impact of this, and the security threat
El vie, 28-01-2005 a las 10:52 -0800, Stephen Hemminger escribió:
On Fri, 28 Jan 2005 19:31:50 +0100
When I did the port randomization patch the benchmark that was most impacted
was LMBENCH. The biggest change was in the communications latency results.
If you want, you can sign up for a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2005-01-28, Stephen Hemminger said on linux-kernel:
Randomized IP IDs hinders OS fingerprinting and will keep your
machine from being a bounce for an untraceable portscan.
References: [1]:
http://www.gentoo.org/proj/en/hardened/grsecurity.xml
On Fri, Jan 28, 2005 at 06:47:55PM +0100, Lorenzo Hernández García-Hierro wrote:
El vie, 28-01-2005 a las 18:40 +0100, Adrian Bunk escribió:
On Fri, Jan 28, 2005 at 06:17:17PM +0100, Lorenzo Hernández García-Hierro
wrote:
...
As it's impact is minimal (in performance and
Hi,
Attached the new patch following Arjan's recommendations.
I'm sorry about not making it inlined, but my mail agent messes up the
diffs if I do so.
Still waiting for the OSDL STP tests results, they will take a while to
finish.
Cheers,
--
Lorenzo Hernández García-Hierro [EMAIL PROTECTED]
On Fri, 2005-01-28 at 21:34 +0100, Lorenzo Hernndez Garca-Hierro
wrote:
Hi,
Attached the new patch following Arjan's recommendations.
I'm sorry about not making it inlined, but my mail agent messes up the
diffs if I do so.
Still waiting for the OSDL STP tests results, they will take a while
On Fri, 28 Jan 2005 21:34:52 +0100
Lorenzo Hernández García-Hierro [EMAIL PROTECTED] wrote:
Attached the new patch following Arjan's recommendations.
No SMP protection on the SBOX, better look into that.
The locking you'll likely need to add will make this
routine serialize many networking
On Fri, 28 Jan 2005 12:45:17 -0800
David S. Miller [EMAIL PROTECTED] wrote:
On Fri, 28 Jan 2005 21:34:52 +0100
Lorenzo Hernández García-Hierro [EMAIL PROTECTED] wrote:
Attached the new patch following Arjan's recommendations.
No SMP protection on the SBOX, better look into that.
The
On Fri, 28 Jan 2005 13:34:08 -0800
Stephen Hemminger [EMAIL PROTECTED] wrote:
per-cpu would be the way to go here.
Does the sbox get somehow seeded from use to use?
If not, then yes that's the thing to do.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
El vie, 28-01-2005 a las 21:47 +0100, Arjan van de Ven escribió:
as for obsd_get_random_long().. would it be possible to use the
get_random_int() function from the patches I posted the other day? They
use the existing random.c infrastructure instead of making a copy...
As seen at
Stephen Hemminger [EMAIL PROTECTED] writes:
On Fri, 28 Jan 2005 12:45:17 -0800
David S. Miller [EMAIL PROTECTED] wrote:
On Fri, 28 Jan 2005 21:34:52 +0100
Lorenzo Hernández García-Hierro [EMAIL PROTECTED] wrote:
Attached the new patch following Arjan's recommendations.
No SMP
It adds support for advanced networking-related randomization, in
concrete it adds support for TCP ISNs randomization
Er... did you read the existing Linux TCP ISN generation code?
Which is quite thoroughly randomized already?
I'm not sure how the OpenBSD code is better in any way. (Notice
83 matches
Mail list logo
