[36362] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Hamiltonian path as protection against DOS.

daemon@ATHENA.MIT.EDU (mikeiscool)
Wed Aug 16 14:03:38 2006

X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Wed, 16 Aug 2006 14:28:59 +1000
From: mikeiscool <michaelslists@gmail.com>
Reply-To: michaelslists@gmail.com
To: "Bill Stewart" <bill.stewart@pobox.com>
Cc: "James A. Donald" <jamesd@echeque.com>, cryptography@metzdowd.com
In-Reply-To: <6.2.1.2.0.20060815101505.034b6088@pop.idiom.com>

Could this sort of system be something that is implemented way before
a HTTP connection even starts?

Say, implemented by OS vendors or API vendors of sockets. That is to
say, when you open a socket connection for the first time, for certain
protocols, you need to pay this fee. The socket lib would be adjusted
to do it, and then you are good to go.

It would mean that other services get the benefit of protection. But
is there legimate need to connect to many, or one, host many thousands
of times? I'd guess there is.

Take the discussed handshakes. Could something be incorporated there?

Maybe there could be a new low level protocol, kind of like SSL, but
less cost involved ... then you could tell your server to operate in
that mode only...

-- mic

On 8/16/06, Bill Stewart <bill.stewart@pobox.com> wrote:
> Crypto is usually about economics and scalability.
>
> If you're doing this for DOS/DDOS prevention,
> you don't need the NP-completeness perfection you get from
> Hamiltonian paths or similar problems - SHA is fine,
> or any other hash that's quick to verify and
> hard to reverse.  Even MD5 is probably still ok...
> Calculating any of the hashes probably takes less time than
> handling the packets does.
>
> It's almost certainly better for you if they harass you by
> sending you bogus SHA pieces that you can process quickly
> than bogus DH pieces that take you a while,
> and if it's not too distributed an attack,
> you can also blacklist senders IP addresses.
>
> At present I'm skeptical about the need for
> that kind of protection - a simple UDP or TCP handshake
> and maybe a Photuris cookie are enough to
> take care of most forgery attacks
> and let you blacklist hostile senders.
> But malware writers are tenacious bastards,
> and perhaps there are or will be applications where
> this sort of protection could be useful -
> merely insisting that attackers use _your_ protocol
> is probably enough to cut down on 99.99% of attacks
> unless you get the protocol widely adopted.
>
>

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

home help back first fref pref prev next nref lref last post