View source for Authenticated encryption

{{Short description|Encryption method}}
'''Authenticated Encryption''' (AE) is an [[encryption]] scheme which simultaneously assures the data confidentiality (also known as privacy: the encrypted message is impossible to understand without the knowledge of a secret [[Key (cryptography)|key]]{{sfn|Black |2005|p=1}}) and [[Message authentication|authenticity]] (in other words, it is unforgeable:{{sfn | Katz | Lindell | 2020 | p=116}} the encrypted message includes an authentication tag that the sender can calculate only while possessing the secret key{{sfn|Black|2005|p=1}}). Examples of [[encryption mode]]s that provide AE are [[Galois/Counter Mode|GCM]], [[CCM mode|CCM]].{{sfn|Black|2005|p=1}}

Many (but not all) AE schemes allow the message to contain "associated data" (AD) which is not made confidential, but its integrity is protected (i.e., it is readable, but tampering with it will be detected). A typical example is the [[Header (computing)|header]] of a [[network packet]] that contains its destination address. To properly [[Routing|route]] the packet, all intermediate nodes in the message path need to know the destination, but for security reasons they cannot possess the secret key.{{sfn|Black|2005|p=2}} Schemes that allow associated data provide [[#Authenticated encryption with associated data|authenticated encryption with associated data]], or '''AEAD'''.{{sfn|Black|2005|p=2}}

== History ==
The need for authenticated encryption emerged from the observation that securely combining separate ''confidentiality'' and ''authentication'' block cipher operation modes could be error prone and difficult.<ref name=":1">{{cite web |quote=people had been doing rather poorly when they tried to glue together a traditional (privacy-only) encryption scheme and a message authentication code (MAC) |url=http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/eax/eax-spec.pdf|title=A Conventional Authenticated-Encryption Mode|author1=M. Bellare|author2=P. Rogaway|publisher=NIST|access-date=March 12, 2013|author3=D. Wagner}}</ref><ref>{{cite web |quote=it is very easy to accidentally combine secure encryption schemes with secure MACs and still get insecure authenticated encryption schemes |url=http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/cwc/cwc-spec.pdf|title=The CWC Authenticated Encryption (Associated Data) Mode|author1=T. Kohno|author2=J. Viega|publisher=NIST|access-date=March 12, 2013|author3=D. Whiting|name-list-style=amp}}</ref> This was confirmed by a number of practical attacks introduced into production protocols and applications by incorrect implementation, or lack of authentication.<ref>{{cite web|url=https://cr.yp.to/talks/2013.03.12/slides.pdf|title=Failures of secret-key cryptography|publisher=Daniel J. Bernstein|archive-url=https://web.archive.org/web/20130418063008/http://cr.yp.to/talks/2013.03.12/slides.pdf|archive-date=April 18, 2013|access-date=March 12, 2013|url-status=dead}}</ref>

Around the year 2000, a number of efforts evolved around the notion of standardizing modes that ensured correct implementation. In particular, strong interest in possibly secure modes was sparked by the publication of [[Charanjit Jutla]]'s integrity-aware CBC and [[IAPM (mode)|integrity-aware parallelizable]], IAPM, modes<ref>{{cite web|url=https://eprint.iacr.org/2000/039|title=Encryption Modes with Almost Free Message Integrity|last=Jutl|first=Charanjit S.|date=2000-08-01|work=Cryptology ePrint Archive: Report 2000/039|publisher=[[International Association for Cryptologic Research|IACR]]|others=Proceedings IACR EUROCRYPT 2001|access-date=2013-03-16}}</ref> in 2000 (see [[OCB mode|OCB]] and chronology<ref>{{cite journal|url=https://web.cs.ucdavis.edu/~rogaway/papers/ae.pdf|title=The Software Performance of Authenticated-Encryption Modes|author1= T. Krovetz|author2=P. Rogaway|date=2011-03-01|journal=Fast Software Encryption 2011 (FSE 2011)|publisher=[[International Association for Cryptologic Research|IACR]]}}</ref>).
Six different authenticated encryption modes (namely [[OCB mode|offset codebook mode 2.0]], OCB{{nbsp}}2.0; [[Key Wrap]]; [[CCM mode|counter with CBC-MAC]], CCM; [[EAX mode|encrypt then authenticate then translate]], EAX; [[encrypt-then-MAC]], EtM; and [[Galois/counter mode]], GCM) have been standardized in ISO/IEC 19772:2009.<ref name="ISO19772">{{cite web|url=https://www.iso.org/iso/catalogue_detail.htm?csnumber=46345|title=Information technology -- Security techniques -- Authenticated encryption|work=19772:2009|publisher=ISO/IEC|access-date=March 12, 2013}}</ref> More authenticated encryption methods were developed in response to [[NIST]] solicitation.<ref>{{cite web|url=http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html|title=Encryption modes development|publisher=NIST|access-date=April 17, 2013}}</ref> [[Sponge function]]s can be used in duplex mode to provide authenticated encryption.<ref>{{cite web|url=http://sponge.noekeon.org/SpongeDuplex.pdf|title=Duplexing The Sponge|author=The Keccak Team}}</ref>

Bellare and Namprempre (2000) analyzed three compositions of encryption and MAC primitives, and demonstrated that encrypting a message and subsequently applying a MAC to the ciphertext (the [[#Encrypt-then-MAC|Encrypt-then-MAC]] approach) implies security against an [[adaptive chosen ciphertext attack]], provided that both functions meet minimum required properties. Katz and Yung investigated the notion under the name "unforgeable encryption" and proved it implies security against chosen ciphertext attacks.<ref>{{Cite book|last1=Katz|first1=J.|last2=Yung|first2=M.|title=Fast Software Encryption (FSE): 2000 Proceedings |chapter=Unforgeable Encryption and Chosen Ciphertext Secure Modes of Operation |series=Lecture Notes in Computer Science|volume=1978|pages=284–299|editor=B. Schneier|doi=10.1007/3-540-44706-7_20|year=2001|isbn=978-3-540-41728-6}}
</ref>

In 2013, the [[CAESAR Competition|CAESAR competition]] was announced to encourage design of authenticated encryption modes.<ref>{{cite web|url=https://competitions.cr.yp.to/caesar.html|title=CAESAR: Competition for Authenticated Encryption: Security, Applicability, and Robustness|access-date=March 12, 2013}}</ref>

In 2015, [[ChaCha20-Poly1305]] is added as an alternative AE construction to [[Galois/Counter Mode|GCM]] in [[Internet Engineering Task Force|IETF]] protocols.

== Variants ==
=== Authenticated encryption with associated data ===
Authenticated encryption with associated data (AEAD) is a variant of AE that allows the message to include "associated data" (AD, additional non-confidential information, a.k.a. "additional authenticated data", AAD). A recipient can check the integrity of both the associated data and the confidential information in a message. AD is useful, for example, in [[network packet]]s where the [[header (computing)|header]] should be visible for [[routing]], but the payload needs to be confidential, and both need [[data integrity|integrity]] and [[message authentication|authenticity]]. The notion of AEAD was formalized by [[Phillip Rogaway|Rogaway]] (2002).{{sfn|Black|2005|p=2}}

===Key-committing AEAD===
AE was originally designed primarily to provide the ciphertext integrity: successful validation of an authentication tag by [[Alice and Bob|Alice]] using her symmetric key K<sub>A</sub> indicates that the message was not tampered with by an adversary [[Alice and Bob|Mallory]] that does not possess the K<sub>A</sub>. The AE schemes usually do not provide the '''key commitment''', a guarantee that the decryption would fail for any other key.{{sfn|Albertini|Duong|Gueron|Kölbl|2020|pp=1-2}} As of 2021, most existing AE schemes (including the very popular GCM) allow some messages to be decrypted without an error using more than just the (correct) K<sub>A</sub>; while the plaintext decrypted using a second (wrong) key K<sub>M</sub> will be incorrect, the authentication tag would still match the new plaintext.<ref>{{Cite web |date=2024-09-10 |title=Invisible Salamanders Are Not What You Think |url=https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/ |access-date=2025-02-21 |website=Dhole Moments |language=en-US}}</ref> Since crafting a message with such property requires Mallory to already possess both K<sub>A</sub> and K<sub>M</sub>, the issue might appear to be one of a purely academic interest.{{sfn|Albertini|Duong|Gueron|Kölbl|2020|p=2}} However, under special circumstances, practical attacks can be mounted against vulnerable implementations. For example, if an [[identity authentication]] protocol is based on successful decryption of a message that uses a password-based key, Mallory's ability to craft a single message that would be successfully decrypted using 1000 different keys associated with [[weak password|weak]], and thus known to her, potential passwords, can speed up her search for passwords by a factor of almost 1000. For this [[dictionary attack]] to succeed, Mallory also needs an ability to distinguish successful decryption by Alice from an unsuccessful one, due, for example, to a poor protocol design or implementation turning Alice's side into an [[Oracle attack|oracle]]. Naturally, this attack cannot be mounted at all when the keys are generated randomly.<ref>{{cite conference |last1=Len |first1=Julia |last2=Grubbs |first2=Paul |last3=Ristenpart |first3=Thomas |title=Partitioning Oracle Attacks |url=https://www.usenix.org/conference/usenixsecurity21/presentation/len |pages=195–212 |language=en |date=2021|conference=USENET '21}}</ref>    

Key commitment was originally studied in the 2010s by Abdalla et al.{{sfn | Abdalla | Bellare | Neven | 2010 | pp=480–497}} and Farshim et al.{{sfn | Farshim | Libert | Paterson | Quaglia | 2013 | pp=352–368}} under the name "robust encryption".{{sfn|Albertini|Duong|Gueron|Kölbl|2020|p=2}}{{sfn|Bellare|Hoang|2022|p=5}}

To mitigate the attack described above without removing the "oracle", a ''key-committing AEAD'' that does not allow this type of crafted messages to exist can be used. AEGIS is an example of fast (if the [[AES instruction set]] is present), key-committing AEAD.<ref>{{cite web |last1=Denis |first1=Frank |title=The AEGIS Family of Authenticated Encryption Algorithms |url=https://cfrg.github.io/draft-irtf-cfrg-aegis-aead/draft-irtf-cfrg-aegis-aead.html |website=cfrg.github.io |language=en}}</ref> It is possible to add key-commitment to an existing AEAD scheme.<ref>{{cite web |last1=Gueron |first1=Shay |title=Key Committing AEADs |url=https://eprint.iacr.org/2020/1153.pdf |date=2020}}</ref><ref>{{cite web |last1=poncho |title=Key Committing AEADs |url=https://crypto.stackexchange.com/a/87776 |website=Cryptography Stack Exchange |access-date=21 February 2024 |language=en}} (See also the comment section discussing a revised [[libsodium]] recommendation for adding key-commitment.)</ref>

===Misuse-resistant authenticated encryption===
Misuse-resistant authenticated encryption (MRAE) has the additional property that reusing the same [[Cryptographic nonce|nonce]] for several messages does not allow an attacker to recover the plaintext. MRAE was formalized in 2006 by [[Phillip Rogaway]] and Thomas Shrimpton.<ref>{{cite conference |last1=Rogaway |first1=Phillip |author-link1=Phillip Rogaway |last2=Shrimpton |first2=Thomas |title=Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem |conference=[[EUROCRYPT]] |date=2006 |volume=4004 |pages=373-390 |doi=10.1007/11761679_23 |url=https://www.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf |access-date=2025-06-22 |series=[[Lecture Notes in Computer Science]] |publisher=[[Springer Science+Business Media|Springer]] |language=en |archive-url=https://web.archive.org/web/20241218124122/https://www.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf |archive-date=2024-12-18 |url-status=live}}</ref> One example of a MRAE algorithm is [[AES-GCM-SIV]].

==Approaches to authenticated encryption==

===Encrypt-then-MAC (EtM) {{anchor|Encrypt-then-MAC|EtM}}===
[[File:Authenticated Encryption EtM.png|thumb|right|EtM approach]]
The plaintext is first encrypted, then a MAC is produced based on the resulting ciphertext. The ciphertext and its MAC are sent together. ETM is the standard method according to ISO/IEC 19772:2009.<ref name=ISO19772/> It is the only method which can reach the highest definition of security in AE, but this can only be achieved when the MAC used is "strongly unforgeable".<ref name="BN">{{cite web|url=https://cseweb.ucsd.edu/~mihir/papers/oem.html|title=Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm|publisher=M. Bellare and C. Namprempre|access-date=April 13, 2013|archive-date=January 23, 2018|archive-url=https://web.archive.org/web/20180123062226/http://cseweb.ucsd.edu/~mihir/papers/oem.html|url-status=dead}}</ref>

[[IPsec|IPSec]] adopted EtM in 2005.<ref>{{cite journal|url=https://tools.ietf.org/html/rfc4303#section-3.3.2.1|title=Separate Confidentiality and Integrity Algorithms|journal=RFC 4303 - IP Encapsulating Security Payload (ESP) |date=December 2005 |publisher=Internet Engineering Task Force (IETF)|access-date=2018-09-12 |last1=Kent |first1=Stephen }}</ref> In November 2014, TLS and DTLS received extensions for EtM with {{IETF RFC|7366}}. Various EtM ciphersuites exist for SSHv2 as well (e.g., {{samp|hmac-sha1-etm@openssh.com}}).
{{clear}}

===Encrypt-and-MAC (E&M) {{anchor|Encrypt-and-MAC|E&M}}===
[[File:Authenticated Encryption EaM.png|thumb|right|E&M approach]]
A MAC is produced based on the plaintext, and the plaintext is encrypted without the MAC. The plaintext's MAC and the ciphertext are sent together. Used in, e.g., [[Secure Shell|SSH]].<ref>{{cite journal|url=https://tools.ietf.org/html/rfc4253#section-6.4|title=Data Integrity|journal=RFC 4253|date=January 2006 |publisher=Internet Engineering Task Force (IETF)|access-date=2018-09-12 |last1=Lonvick |first1=Chris M. |last2=Ylonen |first2=Tatu }}</ref> Even though the E&M approach has not been proved to be strongly unforgeable in itself,<ref name=BN/> it is possible to apply some minor modifications to [[Secure Shell|SSH]] to make it strongly unforgeable despite the approach.<ref>{{cite web |last1=Bellare |first1=Mihir |last2=Kohno |first2=Tadayoshi |last3=Namprempre |first3=Chanathip |title=Breaking and Provably Repairing the SSH Authenticated Encryption Scheme: A Case Study of the Encode-then-Encrypt-and-MAC Paradigm |url=https://homes.cs.washington.edu/~yoshi/papers/SSH/ssh.pdf |publisher=ACM Transactions on Information and System Security |access-date=30 August 2021}}</ref>
{{clear}}

===MAC-then-Encrypt (MtE) {{anchor|MAC-then-Encrypt|MtE}}===
[[File:Authenticated Encryption MtE.png|thumb|right|MtE approach]]
A MAC is produced based on the plaintext, then the plaintext and MAC are together encrypted to produce a ciphertext based on both. The ciphertext (containing an encrypted MAC) is sent. Until TLS 1.2, all available [[SSL/TLS]]  cipher suites were MtE.<ref>{{cite journal|url=https://tools.ietf.org/html/rfc5246#section-6.2.3|title=Record Payload Protection|journal=RFC 5246|date=August 2008 |publisher=Internet Engineering Task Force (IETF)|access-date=2018-09-12 |last1=Rescorla |first1=Eric |last2=Dierks |first2=Tim }}</ref>

MtE has not been proven to be strongly unforgeable in itself.<ref name=BN/> The [[SSL/TLS]] implementation has been proven to be strongly unforgeable by [[Hugo Krawczyk|Krawczyk]] who showed that SSL/TLS was, in fact, secure because of the encoding used alongside the MtE mechanism.<ref name=":0">{{cite web |url=https://www.iacr.org/archive/crypto2001/21390309.pdf |title=The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?) |publisher=H. Krawczyk |access-date=April 13, 2013}}</ref> However, Krawczyk's proof contains flawed assumptions about the randomness of the [[initialization vector]] (IV). The 2011 BEAST attack exploited the non-random chained IV and broke all CBC algorithms in TLS 1.0 and under.<ref>{{cite web |last1=Duong |first1=Thai |last2=Rizzo |first2=Juliano |title=Here Come The ⊕ Ninjas |url=https://tlseminar.github.io/docs/beast.pdf |date=May 13, 2011}} &ndash; BEAST attack whitepaper</ref>

In addition, deeper analysis of SSL/TLS modeled the protection as MAC-then-pad-then-encrypt, i.e. the plaintext is first padded to the block size of the encryption function. Padding errors often result in the detectable errors on the recipient's side, which in turn lead to [[padding oracle attack]]s, such as [[Lucky Thirteen attack|Lucky Thirteen]].
{{clear}}

==See also==
* [[Block cipher mode of operation]]
* [[CCM mode]]
* [[CWC mode]]
* [[OCB mode]]
* [[EAX mode]]
* [[Galois/Counter Mode|GCM]]
* [[AES-GCM-SIV|GCM-SIV]]
* [[ChaCha20-Poly1305]]
* [[Sophie Germain Counter Mode|SGCM]]
* [[Signcryption]]

==References==
{{reflist|35em}}

;General
* {{Citation 
 |url=https://link.springer.com/content/pdf/10.1007/3-540-44448-3_41.pdf
 |first1 = M. |last1 = Bellare |first2 = C. |last2 = Namprempre
 |title = Advances in Cryptology — ASIACRYPT 2000 |chapter = Authenticated Encryption: Relations among Notions and Analysis of the Generic Composition Paradigm
 |series = Lecture Notes in Computer Science |volume = 1976 |editor = T. Okamoto |publisher = Springer-Verlag |year = 2000
 |doi = 10.1007/3-540-44448-3_41
 |pages = 531–545
 |isbn = 978-3-540-41404-9
|doi-access = free}}

== Sources ==
* {{cite book | last1=Katz | first1=J. | last2=Lindell | first2=Y. | title=Introduction to Modern Cryptography | publisher=CRC Press | series=Chapman & Hall/CRC Cryptography and Network Security Series | year=2020 | isbn=978-1-351-13301-2 | url=https://books.google.com/books?id=RsoOEAAAQBAJ&pg=PT116 | access-date=2023-06-08}}
* {{cite book | last=Black | first=J. | title=Encyclopedia of Cryptography and Security | chapter=Authenticated encryption | publisher=Springer US | date = 2005 | pages=11–21 | doi=10.1007/0-387-23483-7_15 | isbn=978-0-387-23473-1 | chapter-url = https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=2628d946bda9f3d3b087e5c4846e76ae0fb07b6b}}
* {{cite web |last1=Albertini |first1=Ange |last2=Duong |first2=Thai |last3=Gueron |first3=Shay |last4=Kölbl |first4=Stefan |last5=Luykx |first5=Atul |last6=Schmieg |first6=Sophie |title=How to Abuse and Fix Authenticated Encryption Without Key Commitment | url = https://eprint.iacr.org/2020/1456.pdf | date=2020 | publisher=USENIX}}
* {{cite web |last1=Bellare |first1=Mihir |last2=Hoang |first2=Viet Tung |title= Efficient Schemes for Committing Authenticated Encryption | url = https://eprint.iacr.org/2022/268.pdf | date=2022 | publisher=EUROCRYPT 2022}}
* {{cite book | last1=Abdalla | first1=Michel | last2=Bellare | first2=Mihir | last3=Neven | first3=Gregory | title=Theory of Cryptography | chapter=Robust Encryption | publisher=Springer Berlin Heidelberg | publication-place=Berlin, Heidelberg | volume=5978 | date=2010 | isbn=978-3-642-11798-5 | doi=10.1007/978-3-642-11799-2_28}}
* {{cite book | last1=Farshim | first1=Pooya | last2=Libert | first2=Benoît | last3=Paterson | first3=Kenneth G. | last4=Quaglia | first4=Elizabeth A. | title=Public-Key Cryptography – PKC 2013 | chapter=Robust Encryption, Revisited | publisher=Springer Berlin Heidelberg | publication-place=Berlin, Heidelberg | volume=7778 | date=2013 | isbn=978-3-642-36361-0 | doi=10.1007/978-3-642-36362-7_22}}
* {{cite book | last1=Chan | first1=John | last2=Rogaway | first2=Phillip | title=Computer Security – ESORICS 2022 | chapter=On Committing Authenticated-Encryption | publisher=Springer Nature Switzerland | publication-place=Cham | volume=13555 | date=2022 | isbn=978-3-031-17145-1 | doi=10.1007/978-3-031-17146-8_14}}

{{Cryptography navbox | hash}}

[[Category:Symmetric-key cryptography]]
[[Category:Message authentication codes]]