RE: [LinkSec] Factoid: MIC size
Jesse:
You are right, I my message was nearly impossible to understand without a
lot of context that was in my head and not written in the message. Sorry.
I assumed that a replay mechanism is involved. In particular, I assumed a
counter as is used in IPsec ESP. Rekeying is needed to resent the counter.
As you point out, the probability that a randomly generated message will
have a valid MIC is 1/2^t, where t is the size of the MIC value in
bits. This is independent of the key that is in use.
Thus, there needs to be a balance between the MIC value size and the
communications overhead. In my opinion, 64 bits is the minimum. In my
earlier message, I pointed out that the IPsec community selected 96 bits as
the norm.
Similarly, a balance is needed for the replay counter. If it is too small,
then too much time is spent on key management. In my opinion, 32 bits is
the minimum. The IPsec community has an option to use a 64 bit counter to
support very high speed links. This is really only needed if the high
speed link is fully consumed by a single security association, which is
exactly the environment that LinkSec (or MACsec) is addressing.
I hope my recommendations and rationale are more clear this time.
Russ
At 03:04 PM 9/3/2003 -0700, Walker, Jesse wrote:
>Russ and Marcus,
>
>I am confused by this discussion. Let n be the size of the MIC in bits,
>and assume that the MIC has the standard properties. Then the probability
>that a randomly generated message will have a valid MIC is 1/2^n.
>
>To apply the birthday attack, the adversary must create and send
>O(2^(n/2)) different messages, i.e., the adversary must generate and send
>about 2^(n/2) random messages before there is a 50% probability for one to
>succeed. This does not imply you have to change keys frequently. Indeed,
>changing keys does not increase immunity to the attack. All it says is how
>often to expect a successful forgery, independent of the MIC key used.
>
>What am I missing?
>
>-- Jesse
>
>
> > -----Original Message-----
> > From: Russ Housley [mailto:housley@vigilsec.com]
> > Sent: Tuesday, September 02, 2003 12:36 PM
> > To: stds-802-linksec@ieee.org
> > Subject: Re: [LinkSec] Factoid: MIC size
> >
> >
> >
> > IPsec uses a MIC of 96 bits for similar reasons.
> >
> > Russ
> >
> > At 03:09 PM 9/2/2003 -0400, Leech, Marcus (EXCHANGE:FITZ:8M86) wrote:
> >
> > >Under the standard birthday attack collision assumptions,
> > the probability
> > > of collision becomes significant when the number of
> > messages under a given
> > > key approachs sqrt(2^size-of-mic).
> > >
> > >That means that for a 64-bit MIC, you need to change keys
> > before 2^32 messages
> > > have been sent under a key. For a 10gbit link, under
> > assumption of average
> > > 1000-bit messages, that's a key change every 7.15 minutes
> > or so. That
> > > impacts
> > > the efficiency of the key-exchange algorithm, and the
> > decision-point for
> > > key-change (if you algorithm for key-changing is slow,
> > you want to
> > > start trying
> > > to do a key-change rather early, so that there's NO
> > possibility of
> > > exceeding
> > > the collision limit).
> > >
> > >Since we seem to be in the "how many bits can we
> > realistically add to the
> > >header"
> > > phase, I'd vote for more MIC bits than 64.
> > >
> > >--
> > >-------------------------------------------------------------
> > ---------
> > >Marcus Leech Mail:
> > >Advisor Phone: (ESN)
> > 393-9145 +1 613 763
> > >9145
> > >Security Architecture and Planning Fax: (ESN)
> > 393-2754 +1 613 763
> > >2754
> > >Nortel Networks mleech@nortelnetworks.com
> > >-----------------Expressed opinions are my own, not my
> > employer's------
> >
> >