I have a short (32-bit) message that needs to be authenticated. Due to the constraints of my platform, I would like to use Speck32/64 (32-bit block, 64-bit key) with a Matyas-Meyer-Oseas one-way compression function (due to its ease of implementation and because the input sizes match what Speck generates).

compression function

(Here, $E$ is Speck32/64, $g$ is a no-op, $m_i$ is the entire short message, $H_i$ is the tag, and $H_{i-1}=H_0$ is secret.)

However, my message is short enough that there won't be more than one iteration of the compression function; essentially, I would merely be XORing the output of the cipher with the plaintext. (Obviously, $H_0$ should remain secret!) I also don't care about the secrecy of the message, only its unforgability. Therefore, I would transmit the message in plaintext along with its equally-sized MAC.

Is it secure to give a third party the plain text that goes with a MAC? In other words, does the fact that the third party always knows the plaintext to a given tag weaken the security of the tag? If so, what needs to be changed to secure the message?


1 Answer 1


A normal security notion for MAC's is that of unforgeability. So given some set of message,tag pairs $(m_0,t_0),\ldots,(m_k,t_k)$ is should be hard to create a tag for a new message not among the $\{m_0,\ldots,m_k\}$, stated informally.

In your case, you could just use $E_k(m_0)$ with the secret MAC key $k$ ($H_0$ in your notation); no need for the extra XOR (it does nothing for security; you know $m_0$ anyway, so we might as well use $E_k(m_0)$). This is just a standard use of a keyed random function (which we will suppose a block cipher is) as a MAC for short messages. It's construction 4.5 on page 117 in Katz and Lindell (second edition) book "an introduction to modern cryptography", which also has the (short) security proof for this construction for the above notion of security.

You do realise that your construction does allow for replay attacks, I suppose?

  • $\begingroup$ I realized that the XOR is pretty pointless right after posting; glad I'm right :). And yes, the messages include a nonce to prevent replays. So using a block cipher directly as a MAC is suitable in general? (Obviously it doubles the size of the data being sent and is undesirable for that reason.) $\endgroup$ Mar 26, 2015 at 8:55
  • 2
    $\begingroup$ So the nonce is authenticated as well, hopefully. Yes, for messages that fit into the domain of a block cipher this is quite a valid construction and a good reuse of primitives. In this case it's a doubling, in general, for longer messages, one would use CBC-MAC or HMAC and then the extra data is quite reasonable. $\endgroup$ Mar 26, 2015 at 9:01
  • $\begingroup$ Gotcha, makes sense. I'm going to go back and edit my question now that I know what I'm actually asking (which is what you answered). Thanks! $\endgroup$ Mar 26, 2015 at 9:04
  • $\begingroup$ Glad to be able to help $\endgroup$ Mar 26, 2015 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.