1

CMAC is defined for AES for authentication. My question is pretty simple: is it possible to extend CMAC for ChaCha? Does it even make sense? I cannot find anything related and I am wondering if I am missing something trivial.

When compared to AES, there are algorithms for AEAD with AES, in addition to CMAC for AES. CMAC, as read in the RFC 4493, is an OMAC1 function that is combined with AES. Looking in Fig. 2.1 I am wondering if the AES block could be switched by a ChaCha20 block or this is something that definitively presents security concerns.

AEAD are good for providing encryption and data integrity at the same time, but AES-CMAC is good for providing data integrity, like a signature. AES has AEAD variants and CMAC, but ChaCha20 only has AEAD variants, like ChaChaPoly, but not ChaCha20-CMAC for instance.

Pol Henarejos
  • 13
  • 3
  • 1
    Not at all. The debate is more on "why poly1305 and not others for AEAD" and mine is more like "if AES has AEAD (i.e., GCM) and CMAC, why ChaCha20 only has AEAD (i.e., Poly1305) but not CMAC or similar". – Pol Henarejos Nov 07 '22 at 14:42
  • fair enough, please edit the main text of the question to clarify. right now there are votes to close this question since it is missing details. the question should stand on its own. – kodlu Nov 07 '22 at 15:01
  • As indicated, the question has been edited to ask why CMAC could not be used with ChaCha20. If it is to be closed, possibly as duplicate of this earlier indicated question then please provide a clear comment why it answers the question. – Maarten Bodewes Nov 08 '22 at 18:19

1 Answers1

3

It is possible to use ChaCha20 in a CMAC construction. Abstractly, we can view CMAC as a generic construction to build variable input length pseudo-random functions. It is well-known that a secure PRF is also a secure MAC. So technically, one could also directly use Chacha20 as a MAC by first applying a collision-resistance hash, producing outputs whose size is equal to the size of ChaCha20 inputs.

So, let's look somewhat closely at the CMAC construction. It is built out of (1) a variable-length prefix-free secure pseudo-random function and (2) a randomized prefix-free encoding (with high probability). Condition (1) means that we have a primitive that is a secure PRF as long as none of its possible inputs are prefixing each other. For 2), I'll just mention that this is achieved with the subkeys and XORing the last blocks in CMAC. How do we build such variable-length prefix-free PRF? A possibility that is also the one used in CMAC is the CBC mode of operation. Although usually used with a block cipher for decryption, CBC can also be used with a PRF (recalling that a block cipher can be used as a secure PRF).

As for security, there are no concerns since ChaCha20 is conjectured to be a PRF. You may get a better security bound than shown in this answer since AES-based CMAC introduces a factor due to the PRP-PRF switching lemma. A full security argument for CMAC based on a PRF is presented in Boneh&Shoup's book (section 6.3).

The comparison between AES and ChaCha20 above is probably unfair since AES has a smaller output size, but for the same output-size an actually PRF is desirable.

Marc Ilunga
  • 3,188
  • 1
  • 9
  • 22
  • Having (X)ChaCha20Poly1305, do you identify a use case where ChaCha20-CMAC may be more interesting than ChachaPoly? I am trying to figure out why AES has lots of variants and schemes, and ChaCha20 is almost limitted to ChaChaPoly. – Pol Henarejos Nov 09 '22 at 08:03
  • 1
    @PolHenarejos, I don't do optimized implementations, so I can't give a definitive answer, but my understanding is that ChaCha20-CMAC only brings marginal benefit. It's probably more efficient in software thanks to ChaCha20, but Poly1305 is like much faster. And as an AEAD, the name ChaCha20-ChaCha20-CMAC is a bit of a mouthful ;). I think there are many modes for AES that evolved along as our understanding of security for cryptography evolved overall. But it is perfectly fine to have a few very good tools for the job and not too many alternatives. – Marc Ilunga Nov 09 '22 at 10:06