From: Scott A Crosby <scrosby@cs.rice.edu>
To: linux-kernel@vger.kernel.org
Subject: Re: Route cache performance under stress
Date: 08 Apr 2003 01:14:55 -0500 [thread overview]
Message-ID: <oydr88do6qo.fsf@bert.cs.rice.edu> (raw)
Please CC me on any replies:
The suggested code here is problematic.
RND1 = random_generated_at_start_time() ;
RND2 = random_generated_at_start_time() ;
/* RND2 may be 0 or equal to RND1, all cases seem OK */
x = (RND1 - saddr) ^ (RND1 - daddr) ^ (RND2 + saddr + daddr);
reduce(x)
For instance, if the table is assumed to have size N, bucket
collisions can be generated by:
saddr=daddr= k*N for all k.
Or, a different attack, if I assume that reduce(x) determines the
bucket by masking off, say, the lowest 12 bits, then:
saddr=0xXXXXXAAA
daddr=0xYYYYYBBB
Where, XXX, YYY are anything, AAA, BBB are arbitrarily chosen.
Now, lets look at the various terms:
(RND1 - saddr) = 0xUUUUUCCC
(RND1 - daddr) = 0xUUUUUDDD
(RND2 + saddr + daddr) = 0xUUUUUEEE
The U's are all unknown, but the CCC, DDD, and EEE---the only thing
that we care about---are constant. Thus, the lowest 12 bits of x will
be constant. If those are the only bits that are used, then the
attacker has complete freedom to forge the highest 20 bits of saddr
and daddr.
With that function, you'd probably be better off masking off the high
order bits. At least there's a chance of a carry from the UUUU's
propagating into the bits you mask off.
I'm rusty with statistical analysis of cryptographic algorithms, but I
suspect demons may be lurking from that avenue too.
What might work better is to have a good universal hash function, h,
then do:
h_k(saddr) - h_k(daddr)
Perhaps the simplest is:
h_k(x) = x * k (mod P)
where P is a prime, and $ 0<= k < P$ is a random variable determined
at bootup.
Scott
next reply other threads:[~2003-04-08 6:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-08 6:14 Scott A Crosby [this message]
2003-04-08 8:07 ` Unsupported VGA card Pratyush Joshi
2003-04-08 8:06 ` John Bradford
2003-04-08 8:49 ` Sahara Workshop
-- strict thread matches above, loose matches on Subject: below --
2003-04-05 16:37 Route cache performance under stress Florian Weimer
2003-04-05 18:17 ` Martin Josefsson
2003-04-05 18:34 ` Willy Tarreau
2003-05-16 22:24 ` Simon Kirby
2003-05-16 23:16 ` Florian Weimer
2003-05-19 19:10 ` Simon Kirby
2003-05-17 2:35 ` David S. Miller
2003-05-17 7:31 ` Florian Weimer
2003-05-17 22:09 ` David S. Miller
2003-05-18 9:21 ` Florian Weimer
2003-05-18 9:31 ` David S. Miller
2003-05-19 17:36 ` Jamal Hadi
2003-05-19 19:18 ` Ralph Doncaster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=oydr88do6qo.fsf@bert.cs.rice.edu \
--to=scrosby@cs.rice.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox