Can a secret message be securely transmitted within a MAC tag?

Question

A sender wants to transmit an ultra secret code $M$ which could be either 'go', 'stop' or 'wait'. This could be any selection of code words really and adopted for any use such as transmitting short commands or short status messages. The code list could also be specific or relevant to a current mission/objective. A limited number of code words will make things a lot faster for the recipient however. I will try explain:

• Both sender and recipient know the valid code list $L$ and share a random 256 bit key $K$ beforehand. This exchange is out of scope.

• Let $H$ be a secure hash function with an output of 256 bits which also claims to be a secure MAC in the format of $H$($K$ | $M$). Skein and possibly a few others fit this criteria.

• Sender generates a random 256 bit nonce $N$ per transmission.

• Sender generates a MAC tag $T$ by calculating $H$($K$ | $N$ | $M$);

• Sender sends $N$ | $T$ in the clear to the recipient.

The recipient tries each message in the code list with the nonce and key to try get a match with the sent MAC tag and thus decipher the message:

function(K, L, N, T) {
   foreach M in L {
      if (T equals H(K | N | M)) {
         return M
      }
   }
   return invalid
}

You will note there is no separate MAC tag sent to authenticate the nonce and MAC tag sent in the clear. Because there are only 3 valid codes, there are only 3 possible MACs considered valid by the recipient. This increases the attacker's chance of a creating a forgery to 2^256 / 3 = 2^254 but this is still comfortably secure. You could in fact have 1000 code words and the security would still be adequate at 2^246. However shorter code lists would be better to prevent a DOS type attack when an attacker sends fake transmissions causing excess MAC validation work for the receiver. For longer code lists, perhaps a separate MAC of the $N$ and $T$ would fix that.

From what I can ascertain, only the recipient should know the true message. An attacker can if they do a brute force of the key space (2^256 difficulty) or break the hash function. There is practically no chance of the receiver interpreting the transmitted code incorrectly because the odds of a valid code word producing the same MAC tag is extremely unlikely due to the collision resistance of the hash function.

Can a secret message be securely transmitted, authenticated and read like this?

Answer 1

There are two parts to this proposal: the use of a code book and a scheme to send short confidential and authenticated messages utilising an existing shared symmetric key.

A code book can be used alone to provide a degree of confidentiality, or can be used to ascribe specific pre-agreed meanings to short messages, in combination with any scheme for sending those short messages. The rest of this answer focuses on the use of a MAC for sending such short messages.

Short answer: yes, this scheme preserves confidentiality and integrity of messages.

Pre-image resistance of the secure hash function ensures confidentiality of the message (in conjunction with an appropriately strong key).

The use of a nonce ensures that an eavesdropper can't tell whether a genuine message is the same as any previous messages.

The properties of a MAC prevent forgeries or manipulated messages being accepted.

Note that this system does not protect against replay attacks or message re-ordering attacks, i.e. it can't be used as a generic secure channel. Once an attacker has observed a message, they can replay the message and the recipient cannot differentiate between a replayed message and a fresh message. If the recipient were to record all valid nonce-message pairs they could detect replays, but not out-of-order messages.

This use of a MAC isn't a standard way to build a secure messaging system, so shouldn't be used for production systems. Practically, it has very large message expansion (256 bit ciphertext + 256 bit nonce per ~10 bit data transferred = ~500bit overhead per 10 bit message). An example of a standardised alternative is GCM, which is more size-efficient (96bit nonce + up to 128bit tag = up to 224bit fixed overhead per any length of message) as well as supporting very long messages.

Answer 2

Yes, I don't see why this scheme would not be secure. It uses a MAC over known data - protected against replay. If that data is received or calculated locally shouldn't matter.

But as you already showed yourself, you bring down the security of the tag with the amount of bits required to calculate the options. So in the end you could as well just CTR-encrypt the $m$ bits of the message $M$ and create a tag value $t$ that is $m$ bits shorter in size.

There is already have a nonce (which is unnecessarily large) and shared secret in the protocol, so there is nothing preventing the use of AES-CTR within the scheme. The only disadvantage of this scheme is that you may loose one bit of space (as you will require two bits to encode a value with 3 possibilities).