Re: [Lake] Ways forward on MTI cipher suite text

[Michael Richardson <[e-mail]>]

Let me go back.

The threat we are dealing with is where an attacker has captured a packet
that they feel does something interesting ("open flood gates now"), or which
they think they know the layout of, and think they can via XOR, flip one of
the plaintext bits by flipping a ciphertext bit.

In order to do that, the attacker has to create a packet that has the same
MAC as the captured packet.  They need some number of extra (irrelevant) bits
which they can permute in order to create such a thing.

Why?

If they knew the authentication/integrity key, they could just create their
own packet, but of course, they might be limited to encrypted packets they
had captured, if they didn't also know the encryption key.
The discussion about 64-bit or 128-bit MACs is how about hard it becomes to
guess a combination that works out.   Fewer bits visible leads to fewer
combinations.  It is unclear to me in such a pre-image attack, if attacker
does not recover the integrity key.   I don't see how they mount such an
attack without it though.

My understanding from the 1990 days of IPsec, and the 96-bit truncated MAC,
was that by truncating it, we open the possibility that when doing this
attack, that the attacker might find a key which leads to the same lower
96-bits, but which isn't actually the correct key.  So one packet works,
but others do not.

A keyed HMAC is very different than a pure pre-image attack on SHAxx.

So what do these extra 8 bytes actually do?

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide