Re: [PATCH 0/2] Improve sequence number generation.

From: David Miller
Date: Sat Aug 20 2011 - 19:46:32 EST


From: "George Spelvin" <linux@xxxxxxxxxxx>
Date: 20 Aug 2011 19:39:51 -0400

> While the increase to 32 bits is definitely desirable, and defends
> against a much less sophisticated attack, I'm concerned that this is a
> case of robbing Peter to pay Paul.

I disagree, attacking this random number selection is much more theoretical
than the brute force attacks possible on 24-bits of entropy.

Show me a usable attack on a real system, then we can talk.

By comparison, real attacks against the 24-bit value have been
demonstrated.

> 2) Do *both*: Use a fixed 32-bit offset *plus* a time-varing one.
> They can be added together and provide the security advantages of
> both. The only cost is having to compute two hashes per SYN.
>
> The main problem here is coming up with a hash function fast enough
> that computing both hashes is no slower than one MD5 invocation.

Doubling the hashing cost is a non-starter. Going to MD5 itself was
a huge lose, and was right at the brink of acceptable performance loss.

This whole change was nearly nixed because of the cost introduced
merely by going to MD5.

> 3) Extend the 24-bit time-varying hash to a 28-bit one.
> This can cause the sequence numbers to wrap in 7/8 of the time
> they would with a fixed offset, but that doesn't seem too bad.
> (That's worst case; it's a triangular distribution centered
> on 15/16.)

I want to stay with a 32-bits of entropy, thank you very much.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/