Jump to content

Authenticated encryption: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
+other IETF sources
Nakov (talk | contribs)
17 edits
minor improvement
Line 36: Line 36:
In 2013, a 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|last=|first=|date=|website=|archive-url=|archive-date=|dead-url=|accessdate=March 12, 2013}}</ref>
In 2013, a 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|last=|first=|date=|website=|archive-url=|archive-date=|dead-url=|accessdate=March 12, 2013}}</ref>


== Authenticated encryption with associated data ==
== Authenticated encryption with associated data (AEAD) ==
This is a variant of AE where the data to be encrypted needs both authentication and integrity as opposed to just integrity.
This is a variant of AE where the data to be encrypted needs both authentication and integrity as opposed to just integrity.


Revision as of 09:19, 24 October 2018

Authenticated encryption (AE) and authenticated encryption with associated data (AEAD) is a form of encryption which simultaneously provides confidentiality, integrity, and authenticity assurances on the data. These attributes are provided under a single, easy to use programming interface.

The need for AE emerged from the observation that securely combining separate confidentiality and authentication block cipher operation modes could be error prone and difficult.[1][2] This was confirmed by a number of practical attacks introduced into production protocols and applications by incorrect implementation, or lack of authentication (including SSL/TLS).[3]

Around the year 2000, a number of efforts evolved around the notion. In particular, strong interest in these modes was sparked by the publication of Charanjit Jutla's IACBC and IAPM modes[4] in 2000. Six different authenticated encryption modes (namely OCB 2.0, Key Wrap, CCM, EAX, Encrypt-then-MAC (EtM), and GCM) have been standardized in ISO/IEC 19772:2009.[5] More were developed in response to NIST solicitation.[6] Sponge functions can be used in duplex mode to provide authenticated encryption.[7]

A typical programming interface for AE mode implementation would provide the following functions:

  • Encryption
    • Input: plaintext, key, and optionally a header in plaintext that will not be encrypted, but will be covered by authenticity protection.
    • Output: ciphertext and authentication tag (message authentication code).
  • Decryption
    • Input: ciphertext, key, authentication tag, and optionally a header.
    • Output: plaintext, or an error if the authentication tag does not match the supplied ciphertext or header.

The header part is intended to provide authenticity and integrity protection for networking or storage metadata for which confidentiality is unnecessary, but authenticity is desired.

In addition to protecting message integrity and confidentiality, authenticated encryption can provide security against chosen ciphertext attack. In these attacks, an adversary attempts to gain an advantage against a cryptosystem (e.g., information about the secret decryption key) by submitting carefully chosen ciphertexts to some "decryption oracle" and analyzing the decrypted results. Authenticated encryption schemes can recognize improperly-constructed ciphertexts and refuse to decrypt them. This in turn prevents the attacker from requesting the decryption of any ciphertext unless he generated it correctly using the encryption algorithm, which would imply that he already knows the plaintext. Implemented correctly, this removes the usefulness of the decryption oracle, by preventing an attacker from gaining useful information that he does not already possess.

Many specialized authenticated encryption modes have been developed for use with symmetric block ciphers. However, authenticated encryption can be generically constructed by combining an encryption scheme and a message authentication code (MAC), provided that:

Bellare and Namprempre (2000) analyzed three compositions of these primitives, and demonstrated that encrypting a message and subsequently applying a MAC to the ciphertext (the Encrypt-then-MAC approach) implies security against an adaptive chosen ciphertext attack, provided that both functions meet the required properties. Katz and Yung investigated the notion under the name "unforgeable encryption" and proved it implies security against chosen ciphertext attacks.[8]

In 2013, a competition was announced to encourage design of authenticated encryption modes.[9]

Authenticated encryption with associated data (AEAD)

This is a variant of AE where the data to be encrypted needs both authentication and integrity as opposed to just integrity.

It is required, for example, by network packets. The header needs integrity, but must be visible; payload, instead, needs integrity and also confidentiality. Both need authenticity.

Approaches to authenticated encryption

Encrypt-then-MAC (EtM)

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. Used in, e.g., IPsec.[10] The standard method according to ISO/IEC 19772:2009.[5] This 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".[11] In November 2014, TLS and DTLS extension for EtM has been published as RFC 7366. Various EtM ciphersuites exist for SSHv2 as well (e.g. hmac-sha1-etm@openssh.com).

Encrypt-and-MAC (E&M)

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., SSH.[12] Even though the E&M approach has not been proved to be strongly unforgeable in itself,[11] it is possible to apply some minor modifications to SSH to make it strongly unforgeable despite the approach.[citation needed]

MAC-then-Encrypt (MtE)

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. Used in, e.g., SSL/TLS.[13] Even though the MtE approach has not been proven to be strongly unforgeable in itself,[11] the SSL/TLS implementation has been proven to be strongly unforgeable by Krawczyk who showed that SSL/TLS was in fact secure because of the encoding used alongside the MtE mechanism.[14][dubious – discuss] Despite the theoretical security, 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 attacks, such as Lucky Thirteen.

See also

References

  1. ^ "people had been doing rather poorly when they tried to glue together a traditional (privacy-only) encryption scheme and a message authentication code (MAC)", in: M. Bellare; P. Rogaway; D. Wagner. "A Conventional Authenticated-Encryption Mode" (PDF). NIST. Retrieved March 12, 2013.
  2. ^ "it is very easy to accidentally combine secure encryption schemes with secure MACs and still get insecure authenticated encryption schemes", in: T. Kohno; J. Viega; D. Whiting. "The CWC Authenticated Encryption (Associated Data) Mode" (PDF). NIST. Retrieved March 12, 2013. {{cite web}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)
  3. ^ "Failures of secret-key cryptography" (PDF). Daniel J. Bernstein. Retrieved March 12, 2013. {{cite web}}: Cite has empty unknown parameter: |dead-url= (help)
  4. ^ Jutl, Charanjit S. (2000-08-01). "Encryption Modes with Almost Free Message Integrity". Cryptology ePrint Archive: Report 2000/039. IACR. Retrieved 2013-03-16.
  5. ^ a b "Information technology -- Security techniques -- Authenticated encryption". 19772:2009. ISO/IEC. Retrieved March 12, 2013. {{cite web}}: Cite has empty unknown parameter: |dead-url= (help)
  6. ^ "Encryption modes development". NIST. Retrieved April 17, 2013.
  7. ^ The Keccak Team. "Duplexing The Sponge" (PDF).
  8. ^ Katz, J.; Yung, M. B. Schneier (ed.). "Unforgeable Encryption and Chosen Ciphertext Secure Modes of Operation". Fast Software Encryption (FSE): 2000 Proceedings;. Lecture Notes in Computer Science. 1978. Springer-Verlag: 284–299.{{cite journal}}: CS1 maint: extra punctuation (link)
  9. ^ "CAESAR: Competition for Authenticated Encryption: Security, Applicability, and Robustness". Retrieved March 12, 2013. {{cite web}}: Cite has empty unknown parameter: |dead-url= (help)
  10. ^ "Separate Confidentiality and Integrity Algorithms". RFC 4303. Internet Engineering Task Force (IETF). Retrieved 2018-09-12.
  11. ^ a b c "Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm". M. Bellare and C. Namprempre. Retrieved April 13, 2013. {{cite web}}: Cite has empty unknown parameter: |dead-url= (help)
  12. ^ "Data Integrity". RFC 4253. Internet Engineering Task Force (IETF). Retrieved 2018-09-12.
  13. ^ "Record Payload Protection". RFC 5246. Internet Engineering Task Force (IETF). Retrieved 2018-09-12.
  14. ^ "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?)" (PDF). H. Krawczyk. Retrieved April 13, 2013.
General
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Authenticated_encryption&oldid=865499160"