Re: a more detailed analysis of "known IV" vulnerability.

[nisse%lysator.liu.se@localhost (Niels Möller)]

Wei Dai <weidai%eskimo.com@localhost> writes:

> On Thu, Mar 14, 2002 at 11:58:55AM +0100, Niels Möller wrote:
> > Do implementations allow that? My implementation has an arbitrary
> > limit of 2^17 channels per connection. (And channel numbers are
> > allocated sequentially).
> 
> The attacker does not need to keep all of the channels open. He can open
> and close 2^24 channels to iterate through the channel numbers, and just
> keep 2^8 channels, each with a different id mod 2^16, open for the attack.

That depends on how channel numbers are allocated. I think a typical
implementation uses a linear channel table indexed by its local
channel numbers, and it will not allocate large local channel numbers
as long as small numbers are available (as that would imply growing
the tables). E.g., my implementation will never allocate a channel
number larger than 2^17, and it always allocates the smallest
available number. ("sequentially" above was perhaps not the right
word, sorry about that).

But an implementation has control only over its *local* numbers, the
numbers it transmits over the wire are chosen by the remote peer. If
the attacker has control over the peer, he gets full control over the
channel numbers I send. I don't know how likely that is; if the
attacker has control over the software at the remote peer, we may well
have bigger problems.

/Niels