4
$\begingroup$

I learned from Wikipedia that authenticated encryption modes include OCB, CCM, EAX, GCM, and so on. Does this mean that when we want to use authenticated encryption we shall use these modes? But these modes don't use public-key encryption or a hash-based MAC, which may be more advanced. So when shall we use an authenticated encryption mode, and when shall we use other MACs such as HMAC-SHA-256?

$\endgroup$
4
$\begingroup$

OCB, CCM, EAX, and GCM, being modes of operation, only work with block ciphers. Some of them, like GCM, are only defined for block ciphers with a particular block size. Note that these authenticated block modes do use MACs (GCM for example is essentially CTR mode with GMAC). Other MACs like HMAC and Poly1305 work with any symmetric cipher, including stream ciphers. So for example if you wanted to use ChaCha20 or were stuck with AES in CBC mode, you could use HMAC-SHA-256 or Poly1305.

These modes all work differently, and in fact are not always even based on the same concept. The only similarity they have is that they can all be used to turn an unauthenticated symmetric cryptosystem into an authenticated one. Internally, each construct is different. GCM for example is an authenticated cipher mode of operation, HMAC is a keyed pseudorandom function, and Poly1305 is a universal hashing one-time MAC. They are quite different, but they all happen to be useful for authenticated encryption.

Although the specific modes you provided all provide effective authentication, they're not always suitable for use everywhere. They are each based on completely different concepts, and they can each be used for only specific purposes. Their only similarity is that they can all be used to authenticate a symmetric cipher. Here is a quick summary of the various modes and where you might use them:

  • OCB, an authenticated mode of operation for cryptographic block ciphers, is fast and lightweight, but is patented so might not be legally viable for everyone.

  • CCM, an authenticated mode of operation for cryptographic block ciphers, was written as a non-patented alternative to OCB for use in 802.11, but is very slow.

  • EAX, an authenticated mode of operation for cryptographic block ciphers, was written to address several criticisms of CCM mode, but is just as slow as it is.

  • GCM, an authenticated mode of operation for cryptographic block ciphers, is fast and widely supported in hardware, but can be vulnerable to side-channel attacks.

  • HMAC, a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret key, in ETM (Encrypt-Then-MAC) mode is easy to plug in to any cipher, but is not fast.

  • Poly1305, a universal hashing one-time MAC, is extremely fast and almost always a good choice. It's only recently gotten popular.

In general, you should not need to think about the specific authentication mode you use. You should be using a simple and friendly library that does all this for you, like NaCl (which I believe uses Poly1305).

$\endgroup$
  • $\begingroup$ I would strongly advise against writing a parallel sentence structure for very much non-parallel concepts. For instance, GCM, HMAC, and Poly1305 are all different types of concepts, and as such incommensurate: an authenticated cipher construction, a pseudorandom function family construction, and a specific universal hashing one-time MAC. But putting them side by side in a table makes it seem like they are commensurate concepts. $\endgroup$ – Squeamish Ossifrage May 21 at 7:19
  • $\begingroup$ @SqueamishOssifrage Alright, I'll make edits to explain that. $\endgroup$ – forest May 21 at 7:20
  • $\begingroup$ GCM/GHASH was first published at INDOCRYPT 2004, and Poly1305 at FSE 2005 about two months later. While it may be technically true that Poly1305 is newer by two months, does that difference matter fifteen years later? $\endgroup$ – Squeamish Ossifrage May 21 at 7:27
  • $\begingroup$ @SqueamishOssifrage Good point. While it really isn't that new, it's only recently been gaining traction. $\endgroup$ – forest May 21 at 7:28
  • 1
    $\begingroup$ Not really the fault of AES-GCM: exactly the same mistake could have been made with ChaCha/Poly1305, but wasn't. (The mistake was to let the sender choose the nonce arbitrarily, rather than requiring it to be the TLS record sequence number.) $\endgroup$ – Squeamish Ossifrage May 21 at 7:57
2
$\begingroup$

When you want to exchange messages with someone who shares a secret key with you, and you want to ensure that nobody else can forge or eavesdrop on the messages, you should use an authenticated cipher, like crypto_secretbox_xsalsa20poly1305 or AES-GCM.

You should forget that ‘block ciphers’ and ‘modes of operation’ exist. Internally, any authenticated cipher will have some mechanism for authentication, and often in principle it can be separated out—e.g., crypto_secretbox_xsalsa20poly1305 uses Poly1305, and AES-GCM uses GHASH, which are both one-time MACs based on polynomial evaluation universal hashes. But these are implementation details that don't need to concern you when you're just using an authenticated cipher.

If you need only prevent forgery, and not eavesdropping, then you can just use a MAC instead of an authenticated cipher.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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