On Wed, Mar 28, 2007 at 04:52:55PM +0200, Andi Kleen ([EMAIL PROTECTED]) wrote:
> > 3) We dont want to be 'totally secure'. We only want to raise the level,
> > and eventually see if we have to spend more time on this next year(s).
> > AFAIK we had two different reports from people being hit by t
> In my patch the random seed is initialized when the first TCP or DCCP
> socket is created, at which point we'll have sufficient entropy.
See my discussion of this case in a later mail to Evgeniy
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 28 Mar 2007 16:14:17 +0200
> Evgeniy Polyakov <[EMAIL PROTECTED]> writes:
> >
> > Jenkins hash is far from being simple to crack, although with some
> > knowledge it can be done faster.
>
> TCP tends to be initialized early before there is anything
> go
On Wed, Mar 28, 2007 at 03:50:47PM +0200, Eric Dumazet wrote:
> 1) We can now use "struct timespec" to get more bits in init_std_data()
That would be a good change, but i don't think it would help that much.
If you know the hardware (e.g. webhost farms tend to have quite
predictive kit) and the ke
On 28 Mar 2007 16:14:17 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> TCP tends to be initialized early before there is anything
> good in the entropy pool.
>
> static void init_std_data(struct entropy_store *r)
> {
> struct timeval tv;
> unsigned long flags;
>
> spin_lock
Andi Kleen <[EMAIL PROTECTED]> writes:
> The only truly variable thing is the
> boot time, which can be guessed
Actually you don't need to guess it. It's in any TCP timestamp.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED
Evgeniy Polyakov <[EMAIL PROTECTED]> writes:
>
> Jenkins hash is far from being simple to crack, although with some
> knowledge it can be done faster.
TCP tends to be initialized early before there is anything
good in the entropy pool.
static void init_std_data(struct entropy_store *r)
{
On Wed, Mar 28, 2007 at 11:29:43AM +0200, Andi Kleen ([EMAIL PROTECTED]) wrote:
> > > But I think it can be mostly ignored.
> >
> > With all due respect, it cannot. An attacker with a small-sized botnet
> > (which is ~250 hosts) can create chains that contain well in excess of 3000
> > items
>
> > But I think it can be mostly ignored.
>
> With all due respect, it cannot. An attacker with a small-sized botnet
> (which is ~250 hosts) can create chains that contain well in excess of 3000
> items.
Most likely they can also easily generate enough latency data to crack any
simple
From: "Nikolaos D. Bougalis" <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 22:01:38 -0700
> What this boils down to is, yes, we can keep patching our own kernels to
> use tagged jenkins hashing if this affects us, waiting for something better
> to come along.
You don't have to patch, I put jen
"Andi Kleen" ([EMAIL PROTECTED]) wrote:
To truly defend against this you would likely need a cryptographic
hash, which would be likely too slow.
I do not think that a cryptographically secure hash is necessary for
this. Using a better hash function (i.e. one which does a good job of
thror
"Nikolaos D. Bougalis" <[EMAIL PROTECTED]> writes:
>
> I will be more than happy to provide a patch for this, but I figured I
> would solicit some input first.
To truly defend against this you would likely need a cryptographic
hash, which would be likely too slow.
If it's a real problem the
On Sat, Mar 24, 2007 at 08:26:58AM -0400, [EMAIL PROTECTED] ([EMAIL PROTECTED])
wrote:
> > Result with jenkins:
> > 1 23880
> > 2 12108
> > 3 4040
> > 4 1019
> > 5 200
> > 6 30
> > 7 8
> > 8 1
> >
> > Xor:
> > 1 65536
>
> Precisely. This means that the Xor hash SUCKS, because its output is
> c
> Result with jenkins:
> 1 23880
> 2 12108
> 3 4040
> 4 1019
> 5 200
> 6 30
> 7 8
> 8 1
>
> Xor:
> 1 65536
Precisely. This means that the Xor hash SUCKS, because its output is
conspicuously
non-random.
What you expect is a Poisson distribution, where the chance that a chain will
contain
k ele
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Fri, 23 Mar 2007 09:00:08 +0100
> I dont consider this new hash as bug fix at all, ie your patch might enter
> 2.6.22 normal dev cycle.
Ok, I checked the patch into net-2.6.22
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
So, briefly saying, jhash_2/3words have safe distribution, but have
higher-number of elements waves as a result of folding which is
unavoidable for general-purpose hash.
Thanks for the analysis.
-n
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a me
Let me start off by saying that I hope I didn't come across as
condenscending in my previous posts. If I did, then it wasn't intended. Now,
on to more important things :)
jhash_2words(const, const, ((const << 16) | $sport) ^ $random)
where $sport is 1-65535 in a loop, and $random is pseud
> Please, do not apply patch as is, I will devote this day to find where
> jenkins has problems and try to fix distribution. If I will fail, then
> it is up to you to decide that above results are bad or good.
I need to admit that I was partially wrong in my analysis of the Jenkins
hash distributi
On Fri, Mar 23, 2007 at 11:33:32AM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> Eric, I agree, that XOR hash is not perfect, and it should be changed,
> but not blindly.
Attached case of how broken can be xor in botnet scenario.
--
Evgeniy Polyakov
jhash_good.png
Description:
On Fri, Mar 23, 2007 at 09:17:19AM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> You have a machine somewhere that allows 65536 concurrent connections
> coming from the same IP address ?
Attached png file of botnet scenario:
1000 addresses from the same network (class B for example),
each one
Evgeniy Polyakov a ecrit :
Call me a loooser which mail will be deleted on arrival, but...
jhash_2words(const, const, ((const << 16) | $sport) ^ $random)
where $sport is 1-65535 in a loop, and $random is pseudo-random number
obtained on start.
Which is exactly the case of web server and attack
On Thu, Mar 22, 2007 at 01:58:34PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: "Nikolaos D. Bougalis" <[EMAIL PROTECTED]>
> Date: Thu, 22 Mar 2007 12:44:09 -0700
>
> > People _have_ had problems. _I_ have had problems. And when
> > someone with a few thousand drones under his contr
David Miller a écrit :
From: Eric Dumazet <[EMAIL PROTECTED]>
Welcome to the club :)
Ok, how about we put something like the following into 2.6.21?
2.6.21 really ?
Just to be clear : I had an attack two years ago, I applied your patch,
rebooted the machine, and since then the attackers h
On Thu, Mar 22, 2007 at 01:53:03PM -0700, Nikolaos D. Bougalis ([EMAIL
PROTECTED]) wrote:
> >Grrr, I think I pointed several times already, that properly distributed
> >values do not change distribution after folding. And it can be seen in
> >all tests (and in that you pointed too).
>
>Yes, I
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Thu, 22 Mar 2007 23:03:04 +0100
> David Miller a écrit :
> > From: "Nikolaos D. Bougalis" <[EMAIL PROTECTED]>
> > Date: Thu, 22 Mar 2007 12:44:09 -0700
> >
> >> People _have_ had problems. _I_ have had problems. And when
> >> someone with a few tho
David Miller a écrit :
From: "Nikolaos D. Bougalis" <[EMAIL PROTECTED]>
Date: Thu, 22 Mar 2007 12:44:09 -0700
People _have_ had problems. _I_ have had problems. And when
someone with a few thousand drones under his control hoses your
servers because he can do math and he leaves you with 200
From: "Nikolaos D. Bougalis" <[EMAIL PROTECTED]>
Date: Thu, 22 Mar 2007 12:44:09 -0700
> People _have_ had problems. _I_ have had problems. And when
> someone with a few thousand drones under his control hoses your
> servers because he can do math and he leaves you with 2-item
> long chain
We started our discussion a bit wrong - let's start it again, ok? :)
Fair enough.
You do not want to read what was written - _if_ we use artificial data,
then attacker can use it too, so if it is possible to break the system
with artificial data, then it is possible it will be broken in
On Thu, Mar 22, 2007 at 12:44:09PM -0700, Nikolaos D. Bougalis ([EMAIL
PROTECTED]) wrote:
> On Thu, Mar 22, 2007 11:21 AM, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> >> Utterly broken? Nonsense. I have tested the actual function I proposed
> >>(sans the __force and __u32 stuff, which weren
On Thu, Mar 22, 2007 11:21 AM, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
Utterly broken? Nonsense. I have tested the actual function I proposed
(sans the __force and __u32 stuff, which weren't necessary in my test
program), against real data, collected from various servers in real-time.
It
On Thu, Mar 22, 2007 at 10:32:44AM -0700, Nikolaos D. Bougalis ([EMAIL
PROTECTED]) wrote:
>Utterly broken? Nonsense. I have tested the actual function I proposed
> (sans the __force and __u32 stuff, which weren't necessary in my test
> program), against real data, collected from various serv
On Thu, March 22, 2007 at 8:52 AM, Evgeniy Polyakov <[EMAIL PROTECTED]>
wrote:
It seems you do not know a history...
I know a lot about history. I may not know the specific history you had
in mind though.
I do see now that this has been brought up before. Before posting, I did
searc
On Thu, Mar 22, 2007 at 08:39:04AM -0700, Nikolaos D. Bougalis ([EMAIL
PROTECTED]) wrote:
>This particular hash seems to be the odd-man out, since most other
> network related hashes in the kernel seem to be Jenkins-based, and some use
> tagged hashing to defeat algorithmic complexity attacks.
Hello,
I have noticed that the hash function that the kernel uses for
established TCP/IP connections is rather simplistic, specifically:
h = (local address ^ local_port) ^ (remote_address ^ remote_port);
h ^= h >> 16;
h ^= h >> 8;
Now, simple is great, but this has a number of
34 matches
Mail list logo
