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

[John Mattsson <[e-mail]>]

> So what do these extra 8 bytes actually do?

8 byte tags provide 64-bit security against online brute force attacks. 16 byte tags provides 128-bit security against offline brute force attacks. To break 64-bit security against online brute force an attacker would on average have to send 4.3 billion messages per second for 68 years, which is infeasible in constrained IoT radio technologies. A forgery against a 64-bit MAC in EDHOC breaks the security of all future application data, while a forgery against a 64-bit MAC in the subsequent application protocol (e.g., OSCORE typically only breaks the security of the data in the forged packet.

I don’t understand exactly what attack you are talking about but the following types of attacks has been discussed:

- For most MAC algorithms, a forgery only breaks the security of that single packet and the complexity of key recovery is equal to the key length. For GCM, the complexity of authentication key recovery is equal to the tag length. But the complexities of multi-forgeries for most other MAC algorithms are not well understood.

- If the MAC length is not integrity protected and the receiver accepts different length, an attacker can perform forgeries on 32 bit MAC even if the sender only uses 128 bit MACs.

John



From: Lake <[e-mail]> on behalf of Michael Richardson <[e-mail]>
Date: Tuesday, 25 January 2022 at 17:49
To: [e-mail] <[e-mail]>
Subject: Re: [Lake] Ways forward on MTI cipher suite text

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