Subject: Re: Calculations of ISN for new TCP sessions

From: Vernon Schryver <[email-masked]>
Date: Sat, 16 Sep 2000 07:22:33 -0600 (MDT)

> From: Alan Cox <[email-masked]>

> Im not a cryptographer but Im being told MD5 should not be used by people
> who are, and that people have found MD5 weaknesses that are not (yet) apparent
> in SHA

You should check the credentials of your cryptographers or your
understanding of what they said.  Even more than "computer expert,"
people like to affect cryptographic expertise based on their need
to be respected by their fellows down at the pub, or to sell
"computer security" snake oil to people affecting computer expertise.

I don't claim to be a cryptographer, but my understanding is that the
known weakness (singular, not plural) in MD5 would not be useful for a
bad guy in this situation, where the bad guy does not know the value that
is being hashed.  Even in situations where in theory the weakness matters,
when the bad guy is trying to construct a second message that has the same
MD5 hash value as a known, first message, it is completely useless in
practice.  The known weakness only makes people worry that someone might
know a secret way to compute a second message with the given MD5 hash
value of another message, thereby forging a digital signature to the
second message.

Note also that MD5 is not MD4, MD2, CRC-32, or other hashes that 
have bad reputations for cryptographic applications.

> Are people still using MD5 ?

Yes, for PPP CHAP and many other things with vastly stronger requirements
than merely making it impractical to guess initial TCP sequence numbers.

That's not to say that if you need a digital signature, SHA is not
a good and perhaps better choice.  However, we are not talking
about digital signatures.

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 17 Sep 2000 18:53:35 -0600 (MDT)

> From: Andi Kleen <[email-masked]>

> ...
> When you can open a connection to the server you get as many guesses as you
> want for a secret refresh period (a few minutes). You know one ISN, the 
> algorithm to generate it and a lot of the input parameters (your IP, your
> port, etc.). Unknown is just the secret.  When there are not too many 
> possibilities for the secret you can brute force it, checking it against 
> your single ISN. When you can make the brute force attack quicker than
> the secret refresh you win. When the server is handicaped in its secret
> generation (e.g. diskless or no disk io during normal operation, no 
> hardware rnd, no user keyboard input) like most servers you'll likely win 
> for a much longer time and you can extend the brute force attack over
> longer times.

What's that about a "secret refresh period" for the secret used to
generate ISN's?  When I've implemented RFC 1948 and other anti-ISN-guessing
schemes, I've never built such a thing.  It sounds like a bad idea.

If the secret includes the microsecond or nanosecond tick when the SYN
arrived, how does the attacker benefit from discovering the secret in use
when that ISN was chosen?  I guess with enough such brute force efforts,
the bad guy might learn about the addresses in your buffer pool and the
distribution of your interrupt latency.  However, that your interrupt latency
is between 50 and 500 usec is not likely to be much of a secret.  If your
system vendor is serious, it's in the manual.  The secret is for each ISN
is how many nanoseconds your clock thinks elapsed, which not even you
clock knows in advance.  (again, see NTP discussions)  And which buffer
was used that time, which depends on other traffic.

That your clock might contribute 10 or 20 instead of 30 and your
buffer pool only 3 to 10 bits of entropy does not imply that you
have the 0 bits of entropy of a constant secret.

> ...
> entropy pools are usually not only used for ISNs, but for a lot of other
> things (like SSL or PGP session keys). For these I would worry even on my
> LAN. Splitting the entropy pool into less security critical (like ISNs) 
> and more security critical (like session keys) is probably not practical,
> so you have to design the entropy pool input for the worst case.

Yes, but I thought we were talking about ISN's instead of cryptographically
secure random numbers for such as SSL, PGP, and IPSec.

If I were to implement RFC 1948 support in a system with an "entropy
pool" such as is commonly used for /dev/random, I would only use
the entropy pool as part of the secret for generating an ISN.
I would also add other sources of entropy such as the microsecond
tick of the SYN's arrival and the buffer address of the SYN.

By the way, if you do use the familiar MD5 in the RFC, I think it's
much faster to concentrate all of the bits and reduce once.
MD5Update() has noticeable fixed overhead.

And yes, I was wrong about the Birthday Paradox.  If 16 bits of the ISN
are randomized (e.g. if you like the BSD clocking defense against
overlapping windows), then each attack has a 1 in 2**16 chance of success.
The attacker must send about 50,000 probes to have a 50% chance of
success.  If you follow RFC 1948 to the letter and give up the BSD
robustness, the bad guy must send about 1,000,000,000 probes for a 50%
probability of success.
(ok--did I mess that up too?  (1-1/(2^16))^50000 is about 0.5)

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 19 Sep 2000 22:11:24 -0600 (MDT)

> From: stanislav shalunov <[email-masked]>

> ...
> > You must assume that the attacker has a current copy of the source
> > to your TCP code and local hardware for private experiments.
>
> Of course, I'm assuming that  

Until now, you consistently and repeatedly said otherwise.

>                                You, on the other hand, appear to be
> alternating between threat model where the attacker is not motivated
> to do anything (even forge a Received line in an email) and threat
> model where the adversary is a resourceful determined enemy.

No, as I said, spammers are motivated but incredibly stupid.
People who predict ISN's are also motivated, and if there is any chance
they'll predict even a simple counter of an ISN generator, not stupid
(or at least not as spammers are stupid).

But enough of this.  You keep making statements whose literal meanings
are inconsistent with my understandings.  When contradicted, you
reinterpret your statements and we suddenly seem to have agreed all along.
Then you say new things that are surprising, but are often modified
summaries of recent statements here or statements common elsewhere. 
I feel as I'm arguing with a creative echo of a mixture words from this
thread, accepted sci.crypt wisdom, and executive summaries from
counterpane.com.  Although I disagree with many of your most recent
statements, I can't find anything strictly relevant to implementing ISN
generators compliant with RFC 1948 and/or resistent to guessing.

So let's just leave it at this,
and agree to disagree on whatever the issue is.