ISO/IEC 19772:2020
(Main)Information security - Authenticated encryption
Information security - Authenticated encryption
This document specifies five methods for authenticated encryption, i.e. defined ways of processing a data string with the following security objectives: - data confidentiality, i.e. protection against unauthorized disclosure of data; - data integrity, i.e. protection that enables the recipient of data to verify that it has not been modified; - data origin authentication, i.e. protection that enables the recipient of data to verify the identity of the data originator. All five methods specified in this document are based on a block cipher algorithm, and require the originator and the recipient of the protected data to share a secret key for this block cipher. Key management is outside the scope of this document. Key management techniques are defined in ISO/IEC 11770 (all parts). Four of the mechanisms in this document, namely mechanisms 3, 4, 5 (AAD variant only) and 6, allow data to be authenticated which is not encrypted. That is, these mechanisms allow a data string that is to be protected to be divided into two parts, D, the data string that is to be encrypted and integrity-protected, and A (the additional authenticated data) that is integrity-protected but not encrypted. In all cases, the string A can be empty. NOTE Examples of types of data that can need to be sent in unencrypted form, but whose integrity is to be protected, include addresses, port numbers, sequence numbers, protocol version numbers and other network protocol fields that indicate how the plaintext is to be handled, forwarded or processed.
Sécurité de l'information — Chiffrement authentifié
General Information
Relations
Overview
ISO/IEC 19772:2020 - Information security - Authenticated encryption - specifies five authenticated encryption methods based on a block cipher. The standard defines how to process data to achieve three core security objectives: data confidentiality, data integrity, and data origin authentication. It replaces the 2009 edition, removes the deprecated mechanism 1 (OCB 2.0) and formalizes mechanisms including key wrap, CCM, EAX, encrypt‑then‑MAC, and GCM. Key management is explicitly outside the scope (see ISO/IEC 11770).
Key topics and requirements
- Authenticated encryption methods: Detailed definitions and procedures for five mechanisms that combine encryption and authentication to protect data.
- Block cipher basis: All mechanisms require a shared secret key for a block cipher; the document prescribes how to use that primitive securely.
- Additional authenticated data (AAD): Mechanisms 3 (CCM), 4 (EAX), 5 (AAD variant only) and 6 (GCM) support AAD - data that is integrity‑protected but not encrypted (e.g., headers, sequence numbers, addresses).
- Encryption and decryption procedures: Step‑by‑step algorithms for encryption and verification/decryption for each mechanism.
- Security objectives: Clear focus on preventing unauthorized disclosure (confidentiality), detecting modification (integrity), and authenticating origin (origin authentication).
- Normative cross‑references: Integrates with ISO/IEC standards for MACs, block cipher modes, and block ciphers (ISO/IEC 9797, 10116, 18033-3).
- Guidance and examples: Informative annexes provide practical guidance and numerical examples to aid implementation and testing.
Applications and who uses it
ISO/IEC 19772:2020 is intended for implementers and designers who need robust authenticated encryption guidance:
- Security architects and cryptographic engineers implementing secure messaging, storage, or transport layers.
- Protocol designers integrating confidentiality and integrity protections into network protocols, IoT comms, VPNs, or TLS-like constructions.
- Software and hardware vendors building cryptographic libraries and appliances requiring standardized authenticated encryption modes.
- Security auditors, evaluators and compliance teams assessing the correct use of authenticated encryption mechanisms.
- System integrators protecting metadata or protocol headers using AAD while keeping payloads encrypted.
Typical use cases include secure data-in-transit, encrypted storage with integrity checks, and secure key transport (key wrap).
Related standards
- ISO/IEC 11770 (key management techniques) - key management is out of scope here
- ISO/IEC 9797 (Message Authentication Codes)
- ISO/IEC 10116 (Modes of operation for n‑bit block ciphers)
- ISO/IEC 18033-3 (Block ciphers)
Keywords: ISO/IEC 19772:2020, authenticated encryption, AAD, CCM, EAX, GCM, encrypt‑then‑MAC, key wrap, data confidentiality, data integrity, data origin authentication.
Frequently Asked Questions
ISO/IEC 19772:2020 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information security - Authenticated encryption". This standard covers: This document specifies five methods for authenticated encryption, i.e. defined ways of processing a data string with the following security objectives: - data confidentiality, i.e. protection against unauthorized disclosure of data; - data integrity, i.e. protection that enables the recipient of data to verify that it has not been modified; - data origin authentication, i.e. protection that enables the recipient of data to verify the identity of the data originator. All five methods specified in this document are based on a block cipher algorithm, and require the originator and the recipient of the protected data to share a secret key for this block cipher. Key management is outside the scope of this document. Key management techniques are defined in ISO/IEC 11770 (all parts). Four of the mechanisms in this document, namely mechanisms 3, 4, 5 (AAD variant only) and 6, allow data to be authenticated which is not encrypted. That is, these mechanisms allow a data string that is to be protected to be divided into two parts, D, the data string that is to be encrypted and integrity-protected, and A (the additional authenticated data) that is integrity-protected but not encrypted. In all cases, the string A can be empty. NOTE Examples of types of data that can need to be sent in unencrypted form, but whose integrity is to be protected, include addresses, port numbers, sequence numbers, protocol version numbers and other network protocol fields that indicate how the plaintext is to be handled, forwarded or processed.
This document specifies five methods for authenticated encryption, i.e. defined ways of processing a data string with the following security objectives: - data confidentiality, i.e. protection against unauthorized disclosure of data; - data integrity, i.e. protection that enables the recipient of data to verify that it has not been modified; - data origin authentication, i.e. protection that enables the recipient of data to verify the identity of the data originator. All five methods specified in this document are based on a block cipher algorithm, and require the originator and the recipient of the protected data to share a secret key for this block cipher. Key management is outside the scope of this document. Key management techniques are defined in ISO/IEC 11770 (all parts). Four of the mechanisms in this document, namely mechanisms 3, 4, 5 (AAD variant only) and 6, allow data to be authenticated which is not encrypted. That is, these mechanisms allow a data string that is to be protected to be divided into two parts, D, the data string that is to be encrypted and integrity-protected, and A (the additional authenticated data) that is integrity-protected but not encrypted. In all cases, the string A can be empty. NOTE Examples of types of data that can need to be sent in unencrypted form, but whose integrity is to be protected, include addresses, port numbers, sequence numbers, protocol version numbers and other network protocol fields that indicate how the plaintext is to be handled, forwarded or processed.
ISO/IEC 19772:2020 is classified under the following ICS (International Classification for Standards) categories: 35.030 - IT Security. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/IEC 19772:2020 has the following relationships with other standards: It is inter standard links to ISO/IEC 19772:2009. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO/IEC 19772:2020 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 19772
Second edition
2020-11
Information security — Authenticated
encryption
Sécurité de l'information — Chiffrement authentifié
Reference number
©
ISO/IEC 2020
© ISO/IEC 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 3
5 Requirements . 4
6 Authenticated encryption mechanism 2 (key wrap) . 5
6.1 General . 5
6.2 Specific notation . 5
6.3 Specific requirements . 5
6.4 Encryption procedure . 5
6.5 Decryption procedure . 6
7 Authenticated encryption mechanism 3 (CCM) . 6
7.1 General . 6
7.2 Specific notation . 7
7.3 Specific requirements . 7
7.4 Encryption procedure . 7
7.5 Decryption procedure . 9
8 Authenticated encryption mechanism 4 (EAX) .10
8.1 General .10
8.2 Specific notation .10
8.3 Specific requirements .10
8.4 Definition of function M .10
8.5 Encryption procedure .11
8.6 Decryption procedure .11
9 Authenticated encryption mechanism 5 (encrypt-then-MAC) .12
9.1 General .12
9.2 Specific notation .12
9.3 Specific requirements .12
9.4 Encryption procedure .13
9.5 Decryption procedure .13
10 Authenticated encryption mechanism 6 (GCM) .14
10.1 General .14
10.2 Specific notation .14
10.3 Specific requirements .15
10.4 Definition of multiplication operation • .15
10.5 Definition of function G .15
10.6 Encryption procedure .16
10.7 Decryption procedure .16
Annex A (informative) Guidance on the use of the mechanisms .18
Annex B (informative) Numerical examples .21
Annex C (normative) Object identifiers .25
Bibliography .26
© ISO/IEC 2020 – All rights reserved iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/ patents) or the IEC
list of patent declarations received (see http:// patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/IEC JTC 1, Information Technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
This second edition cancels and replaces the first edition (ISO/IEC 19772:2009) which has been
technically revised. It also incorporates the Technical Corrigendum ISO/IEC 19772:2009/Cor 1:2014.
The main changes compared to the previous edition are as follows:
— old Clause 6 has been removed following the deprecation of mechanism 1 (OCB 2.0);
— optional additional authenticated data has been included in mechanism 5.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
iv © ISO/IEC 2020 – All rights reserved
Introduction
When data is sent from one place to another, it is often necessary to protect it in some way while it is in
transit, e.g. against eavesdropping or unauthorized modification. Similarly, when data is stored in an
environment to which unauthorized parties can have access, it can be necessary to protect it.
If the confidentiality of the data needs to be protected, e.g. against eavesdropping, then one solution
is to use encryption, as specified in ISO/IEC 18033 (all parts) and ISO/IEC 10116. Alternatively,
if it is necessary to protect the data against modification, i.e. integrity protection, then message
authentication codes (MACs) as specified in ISO/IEC 9797 (all parts), or digital signatures as specified in
ISO/IEC 9796 (all parts) and ISO/IEC 14888 (all parts), can be used. If both confidentiality and integrity
protection are required, then one possibility is to use both encryption and a MAC or signature. While
these operations can be combined in many ways, not all combinations of such mechanisms provide
the same security guarantees. As a result, it is desirable to define in detail exactly how integrity and
confidentiality mechanisms should be combined to provide the optimum level of security. Moreover, in
some cases, significant efficiency gains can be obtained by defining a single method of processing the
data with the objective of providing both confidentiality and integrity protection.
In this document, authenticated encryption mechanisms are defined. These are methods for processing
data to provide both integrity and confidentiality protection. They typically involve either a specified
combination of a MAC computation and data encryption, or the use of an encryption algorithm in a
special way such that both integrity and confidentiality protection are provided.
The methods specified in this document have been designed to maximize the level of security and
provide efficient processing of data. Some of the techniques defined here have mathematical "proofs of
security", i.e. rigorous arguments supporting their soundness.
© ISO/IEC 2020 – All rights reserved v
INTERNATIONAL STANDARD ISO/IEC 19772:2020(E)
Information security — Authenticated encryption
1 Scope
This document specifies five methods for authenticated encryption, i.e. defined ways of processing a
data string with the following security objectives:
— data confidentiality, i.e. protection against unauthorized disclosure of data;
— data integrity, i.e. protection that enables the recipient of data to verify that it has not been modified;
— data origin authentication, i.e. protection that enables the recipient of data to verify the identity of
the data originator.
All five methods specified in this document are based on a block cipher algorithm, and require the
originator and the recipient of the protected data to share a secret key for this block cipher.
Key management is outside the scope of this document. Key management techniques are defined in
ISO/IEC 11770 (all parts).
Four of the mechanisms in this document, namely mechanisms 3, 4, 5 (AAD variant only) and 6, allow
data to be authenticated which is not encrypted. That is, these mechanisms allow a data string that is
to be protected to be divided into two parts, D, the data string that is to be encrypted and integrity-
protected, and A (the additional authenticated data) that is integrity-protected but not encrypted. In all
cases, the string A can be empty.
NOTE Examples of types of data that can need to be sent in unencrypted form, but whose integrity is to be
protected, include addresses, port numbers, sequence numbers, protocol version numbers and other network
protocol fields that indicate how the plaintext is to be handled, forwarded or processed.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 9797 (all parts), Information technology — Security techniques — Message Authentication
Codes (MACs)
ISO/IEC 10116, Information technology — Security techniques — Modes of operation for an n-bit block cipher
ISO/IEC 18033-3, Information technology — Security techniques — Encryption algorithms — Part 3:
Block ciphers
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
© ISO/IEC 2020 – All rights reserved 1
3.1
additional authenticated data
AAD
data that is integrity-protected but not encrypted by the authenticated encryption mechanism (3.3)
3.2
authenticated encryption
(reversible) transformation of data by a cryptographic algorithm to produce ciphertext (3.5) that
cannot be altered by an unauthorized entity without detection, i.e. it provides data confidentiality, data
integrity (3.6), and data origin authentication
3.3
authenticated encryption mechanism
cryptographic technique used to protect the confidentiality and guarantee the origin and integrity of
data, and which consists of two component processes: an encryption (3.8) algorithm and a decryption
(3.7) algorithm
3.4
block cipher
symmetric encryption system (3.15) with the property that the encryption (3.8) algorithm operates on a
block of plaintext (3.13), i.e. a string of bits of a defined length, to yield a block of ciphertext (3.5)
[SOURCE: ISO/IEC 18033-1:2015, 2.9]
3.5
ciphertext
data which has been transformed to hide its information content
[SOURCE: ISO/IEC 10116:2017, 3.2]
3.6
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[SOURCE: ISO/IEC 9797-1:2011, 3.4]
3.7
decryption
reversal of a corresponding encryption (3.8)
[SOURCE: ISO/IEC 18033-1:2015, 2.16]
3.8
encryption
(reversible) transformation of data by a cryptographic algorithm to produce ciphertext (3.5), i.e., to hide
the information content of the data
[SOURCE: ISO/IEC 18033-1:2015, 2.21]
3.9
encryption system
cryptographic technique used to protect the confidentiality of data, and which consists of three
component processes: an encryption (3.8) algorithm, a decryption (3.7) algorithm, and a method for
generating keys (3.10)
[SOURCE: ISO/IEC 18033-1:2015, 2.23]
2 © ISO/IEC 2020 – All rights reserved
3.10
key
sequence of symbols that controls the operation of a cryptographic transformation (e.g. encipherment,
decipherment)
[SOURCE: ISO/IEC 18033-1:2015, 2.27]
3.11
message authentication code
MAC
string of bits which is the output of a MAC algorithm
[SOURCE: ISO/IEC 9797-1:2011, 3.9]
3.12
partition
process of dividing a string of bits of arbitrary length into a sequence of blocks, where the length of
each block is n bits, except for the final block which shall contain r bits, 0 < r ≤ n
3.13
plaintext
unencrypted information
[SOURCE: ISO/IEC 10116:2017, 3.11]
3.14
secret key
key (3.10) used with symmetric cryptographic techniques by a specified set of entities
[SOURCE: ISO/IEC 18033-1:2015, 2.33]
3.15
symmetric encryption system
encryption (3.8) system based on symmetric cryptographic techniques that uses the same secret key
(3.14) for both the encryption (3.8) and decryption (3.7) algorithms
[SOURCE: ISO/IEC 18033-1:2015, 2.40]
4 Symbols and abbreviated terms
A additional authenticated data
C authenticated-encrypted data string
D data string to which an authenticated encryption mechanism is to be applied
d block cipher decryption algorithm; d (Y) denotes the result of block cipher decrypting the n-bit
K
block Y using the secret key K
e block cipher encryption algorithm; e (X) denotes the result of block cipher encrypting the n-bit
K
block X using the secret key K
K secret block cipher key shared by the originator and recipient of the data to which the authenti-
cated encryption mechanism is to be applied
m number of blocks in the partitioned version of D
n block length (in bits) for a block cipher
t tag length (in bits)
© ISO/IEC 2020 – All rights reserved 3
i
0 block of i zero bits
i
1 block of i one bits
⊕ bit-wise exclusive-or of strings of bits (of the same bit-length)
|| concatenation of bit strings, i.e. if A and B are blocks of bits, then A||B is the block of bits obtained
by concatenating A and B in the order specified
# function converting a number into an a-bit block of bits
a
If k is an integer (0 ≤ k < 2 ), then # (k) is the a-bit block which, when regarded as the binary rep-
a
resentation of a number with the most significant bit on the left, equals k.
-1
# function converting a block of bits to a number
-1
If A is a block of bits, then # (A) is the unique non- negative integer whose binary representation
-1
is A. Hence, if A has n bits, then # (# (A)) = A.
n
X| left-truncation of the block of bits X
s
If X has bit-length greater than or equal to s, then X| is the s-bit block consisting of the left-most
s
s bits of X.
s
X| right-truncation of the block of bits X
s
If X has bit-length greater than or equal to s, then X| is the s- bit block consisting of the right-most
s bits of X.
X<<1 left shift of a block of bits X by one position
The rightmost bit of Y = X<<1 is always set to zero.
X>>1 right shift of a block of bits X by one position
The leftmost bit of Y = X>>1 is always set to zero.
len function taking a bit-string X as input, and which gives as output the number of bits in X
mod if a and b > 0 are integers, then a mod b denotes the unique integer c such that:
1) 0 ≤ c < b; and
2) a-c is an integer multiple of b.
5 Requirements
The authenticated encryption mechanisms specified in this document have the following requirements.
The originator and recipient of the data to which the authenticated encryption mechanism is to be
applied, shall:
a) agree on the use of a particular mechanism from those specified in this document;
b) agree on the use of a particular block cipher to be used with the mechanism (one of the block
ciphers standardized in ISO/IEC 18033-3 shall be used);
c) share a secret key K: in all mechanisms except for authenticated encryption mechanism 5, this shall
be a key for the selected block cipher, and in mechanism 5 it shall be a key used as input to a key
derivation procedure.
In addition, each mechanism has specific requirements listed immediately before the mechanism
description.
4 © ISO/IEC 2020 – All rights reserved
Annex A provides guidance on the use of the mechanisms defined in this document.
Annex B contains numerical examples of the operation of the mechanisms specified in this document.
Annex C provides the object identifiers which shall be used to identify the mechanisms defined in this
document.
6 Authenticated encryption mechanism 2 (key wrap)
6.1 General
This clause defines an authenticated encryption mechanism commonly known as key wrap.
NOTE 1 This scheme was originally designed for authenticated encryption of keys and associated information.
That is, it is designed for use with short data strings. However, the scheme can be used with arbitrary length data
strings (up to a maximum of around 2 bits), although it is not efficient for protecting long messages.
NOTE 2 This mode is known as AES key wrap when the AES block cipher is used, where AES stands for
advanced encryption standard, a block cipher algorithm specified in ISO/IEC 18033-3:2010. AES key wrap is also
specified in References [7] and [9].
6.2 Specific notation
For the purposes of the specification of this mechanism, the following symbols and notation apply:
C , C , …, C sequence of (m+1) 64-bit blocks obtained as the output of the authenticated encryp-
0 1 m
tion process
D , D , …, D sequence of m 64-bit blocks obtained by partitioning D, i.e. 64m = len(D)
1 2 m
R , R , …, R sequence of m 64-bit blocks computed during the encryption and decryption processes
1 2 m
Y 64-bit block used during the encryption and decryption processes
Z 128-bit block computed during the encryption and decryption processes
6.3 Specific requirements
The block cipher to be used with this mechanism shall be a 128-bit block cipher, i.e. it shall have n=128.
The data string D to be protected using this mechanism shall contain at least 128 bits and a multiple of
64 bits (i.e. the bit-length of D shall be 64m for some integer m > 1).
6.4 Encryption procedure
The originator shall perform the following steps to protect a data string D.
a) Partition D into a sequence of m 64-bit blocks D , D , …, D , so that D contains the first 64 bits of D,
1 2 m 1
D the next 64 bits, and so on.
b) Let Y be the 64-bit block having hexadecimal representation A6A6A6A6A6A6A6A6, i.e. in binary it
equals (10100110 10100110 … 10100110).
c) For i = 1, 2, …, m:
let R = D .
i i
d) For i = 1, 2, ., 6m, perform the following four steps:
1) Let Z = e ( Y || R );
K 1
© ISO/IEC 2020 – All rights reserved 5
2) Let Y = Z| ⊕ # (i);
64 64
3) For j = 1, 2, …, m-1:
let R = R ;
j j+1
4) Let R = Z| .
m
e) Let C = Y.
f) For i = 1, 2, …, m:
let C = R .
i i
The output of the above process, i.e. the authenticated-encrypted version of D, shall be the bit-string:
C = C || C || … || C
0 1 m
That is, a string of 64(m+1) bits, that is C contains precisely 64 bits more than D.
6.5 Decryption procedure
The recipient shall perform the following steps to decrypt and verify an authenticated-encrypted string C.
a) If len(C) is not a multiple of 64 or is less than 192, then halt and output INVALID.
b) Partition C into a sequence of m+1 64-bit blocks C , C , …, C , so that C contains the first 64 bits of
0 1 m 0
C, C the next 64 bits, and so on.
c) Let Y = C .
d) For i = 1, 2, …, m:
let R = C .
i i
e) For i = 6m, 6m-1, down to 1, perform the following four steps:
1) Let Z = d ( [Y ⊕ # (i)] || R );
K 64 m
2) Let Y = Z| ;
3) For j = m, m-1, …, 2:
let R = R ;
j j-1
4) Let R = Z| .
f) If Y = (10100110 10100110 … 10100110), then output D = R || R || … || R . Otherwise, output
1 2 m
INVALID.
7 Authenticated encryption mechanism 3 (CCM)
7.1 General
This clause defines an authenticated encryption mechanism commonly known as CCM (for counter
with CBC-MAC).
[10]
NOTE CCM is due to Whiting, Housley and Ferguson. The version of CCM defined here is a special case of
CCM as defined in References [8] and [10].
6 © ISO/IEC 2020 – All rights reserved
7.2 Specific notation
For the purposes of the specification of this mechanism, the following symbols and notation apply:
B block of bits used in computing the tag value
B , B , …, B sequence of blocks of bits (each of n bits) used in computing the tag value
1 2 v
C , C , …, C sequence of m 128-bit blocks obtained as part of the output of the authenticated en-
1 2 m
cryption process
D , D , …, D sequence of m 128-bit blocks obtained by partitioning a padded version of D
1 2 m
F flag octet
L length of D (in octets), excluding padding and the length block D
r the number of octets of D in the block D
m
S starting variable (of 120-8w bits)
T plaintext tag value (of t bits)
T′ recomputed tag value, generated during the decryption process
U encrypted tag value (of t bits)
v variable used in computing the tag value
w length of message length field in octets
X 128-bit block computed during the encryption and decryption processes
Y 128-bit block computed during the encryption and decryption processes
7.3 Specific requirements
In advance of any use of the mechanism, the originator and recipient of the data to which the
authenticated encryption mechanism is to be applied, shall agree on:
a) t, the bit-length of the tag; t shall be chosen from the set {32, 48, 64, 80, 96, 112, 128}; and
b) w, the octet-length of the message length field; w shall be chosen from the set {2, 3, 4, 5, 6, 7, 8}.
NOTE The choice of w affects the maximum message length which can be protected. The maximum message
8w+3 8w
length is 2 bits, i.e. 2 octets.
The block cipher to be used with this mechanism shall be a 128-bit block cipher, i.e. it shall have n=128.
The data string D to be protected using this mechanism, and the additional authenticated data string
A, shall contain a whole number of octets, i.e. their lengths shall be a multiple of 8 bits [i.e. len(D) and
len(A) shall both be an integer multiple of 8].
7.4 Encryption procedure
The originator shall perform the following steps to protect a data string D. Let L = len(D)/8, i.e. L is the
number of octets in D.
a) A starting variable S containing 15-w octets (i.e. 120-8w bits) shall be selected. This variable shall
be distinct for every message to be protected, and shall be made available to the recipient of the
message. However, it is not necessary that this value is unpredictable or secret.
© ISO/IEC 2020 – All rights reserved 7
NOTE 1 The value S can, for example, be generated using a counter maintained by the originator, and sent
in cleartext along with the protected message.
b) Right pad the data string D with 16-r zero octets (i.e. between 0 and 120 zero bits) so that the
padded version of D contains a multiple of 128 bits. Then, partition the padded version of D into a
sequence of m 128-bit blocks D , D , …, D , so that D contains the first 128 bits of D, D the next
1 2 m 1 2
128 bits, and so on.
NOTE 2 The value m needs to satisfy 16(m-1) < L ≤ 16m.
c) If len(A) = 0, then let the flag octet F = 0 || # ((t-16)/16) || # (w-1).
3 3
d) If len(A) > 0, then let the flag octet F = 0 || 1 || # ((t-16)/16) || # (w-1).
3 3
NOTE 3 The most significant (left-most) bit of F is a "reserved" bit, i.e. it is set to zero for the version of
the mechanism specified here but can be used in the future in other (as yet unspecified) versions of the
mechanism. The next to the most significant bit of F is set to zero to indicate that all the data being protected
by the mechanism is encrypted.
e) Let X = e (F || S || # (L)).
K 8w
f) If len(A) > 0, then perform the following six steps:
1) if 0 < len(A) < 65 280, then let B = # (len(A)/8) || A;
32 15
2) if 65 280 ≤ len(A) < 2 , then let B = 1 || 0 || # (len(A)/8) || A;
32 64 16
3) if 2 ≤ len(A) < 2 , then let B = 1 || # (len(A)/8) || A;
4) partition B into a sequence of blocks: B , B , …, B , as follows: let B contain the first n bits of
1 2 v 1
B, B the next n bits, and so on, until B contains the final k bits, where 0 < k ≤ n. Thus, len(B) =
2 v
(v-1)n+k;
n-k
5) right pad B with n-k zeros, i.e. let B = B || 0 ;
v v v
6) for i = 1, 2, …, v:
let X = e ( X ⊕ B ).
K i
g) For i = 1, 2, …, m:
let X = e ( X ⊕ D ).
K i
h) Let T = X| .
t
NOTE 4 The plaintext tag T is equal to a MAC computed on the data string B , B , ., B , D , D , …, D using
1 2 v 1 2 m
a slight modification of MAC algorithm 1 specified in ISO/IEC 9797-1.
5 8w
i) Let the flag octet F = ( 0 || # (w-1) ), and let Y = ( F || S || 0 ).
NOTE 5 The two most significant (left-most) bits of F are "reserved" bits, i.e. they are set to zero for the
version of the mechanism specified here but can be used in the future in other (as yet unspecified) versions
of the mechanism. The next three most significant bits of F are set to zero to ensure that this octet is distinct
from the flag octet used in step c) above.
j) Let U = T ⊕ [e (Y)]| .
K t
k) For i = 1, 2, …, m-1, perform the following two steps:
1) Let Y = ( F || S || # (i) );
8w
2) Let C = D ⊕ e (Y).
i i K
l) Let Y = ( F || S || # (m) ), and let C = [D ⊕ e (Y) ]| .
8w m m K 8r
8 © ISO/IEC 2020 – All rights reserved
The output of the above process, i.e. the authenticated-encrypted version of D, shall be the bit-string:
C = C || C || … || C || C || U
1 2 m-1 m
That is, a string of 8L+t bits, that is C contains precisely t bits more than the original data string D
[although it is also necessary to convey the (120-8w)-bit starting variable S and the variable length
additional authenticated data A to the recipient].
7.5 Decryption procedure
The recipient shall perform the following steps to decrypt and verify an authenticated-encrypted string C.
a) If C does not contain a whole number of octets, then halt and output INVALID.
b) If the length of C is less than (t+8) bits, then halt and output INVALID.
c) Let m and r be the unique integers such that C contains a total of 128(m-1) + 8r + t bits, where 0 < r ≤
16. Partition C into a sequence of blocks: C , C , …C , U as follows. Let C contain the first 128 bits of
1 2 m 1
C, C the next 128 bits of C, and so on, until C contains the next 8r bits of C. Finally, let U be the final
2 m
t bits of C.
5 8w
d) Let the flag octet F = ( 0 || # (w-1) ), and let Y = ( F || S || 0 ).
e) Let T = U ⊕ [e (Y)]| .
K t
f) For i = 1, 2, …, m-1, perform the following two steps:
1) Let Y = ( F || S || # (i) );
8w
2) Let D = C ⊕ e (Y).
i i K
g) Let Y = ( F || S || # (m) ), and let D = C ⊕ [e (Y)]| .
8w m m K 8r
h) Let D = D || D || … || D , and let L = 16m – 16 + r.
1 2 m
128-8r
i) Right pad D with 128-8r zeros, i.e. let D = D || 0 .
m m m
j) If len(A) = 0, then let the flag octet F = 0 || # ((t-16)/16) || # (w-1).
3 3
k) If len(A) > 0, then let the flag octet F = 0 || 1 || # ((t-16)/16) || # (w-1).
3 3
l) Let X = e (F || S || # (L)).
K 8w
m) If len(A) > 0, then perform the following six steps:
1) if 0 < len(A) < 65 280 then let B = # (len(A)/8) || A;
32 15
2) if 65 280 ≤ len(A) < 2 then let B = 1 || 0 || # (len(A)/8) || A;
32 64 16
3) if 2 ≤ len(A) < 2 then let B = 1 || # (len(A)/8) || A;
4) partition B into a sequence of blocks: B , B , …, B , as follows: let B contain the first n bits of
1 2 v 1
B, B the next n bits, and so on, until B contains the final k bits, where 0 < k ≤ n. Thus, len(B) =
2 v
(v-1)n+k;
n-k
5) right pad B with n-k zeros, i.e. let B = B || 0 ;
v v v
6) for i = 1, 2, …, v:
let X = e ( X ⊕ B ).
K i
n) For i = 1, 2, …, m:
let X = e ( X ⊕ D ).
K i
© ISO/IEC 2020 – All rights reserved 9
o) Let T′ = X| .
t
p) If T = T′, then output D as computed in step h) and A. Otherwise, output INVALID.
8 Authenticated encryption mechanism 4 (EAX)
8.1 General
This clause defines an authenticated encryption mechanism commonly known as EAX.
[2]
NOTE EAX is due to Bellare, Rogaway and Wagner. The letters EAX do not appear to stand for anything in
particular.
8.2 Specific notation
For the purposes of the specification of this mechanism, the following symbols and notation apply:
C , C , …, C sequence of blocks of bits (each of n bits, with the possible exception of C ) obtained as
1 2 m m
part of the output of the authenticated encryption process
D , D , …, D sequence of blocks of bits (each of n bits, with the possible exception of D ) obtained by
1 2 m m
partitioning D
E , E , E n-bit blocks computed during the encryption and decryption processes
0 1 2
M function used in the encryption and decryption processes
S starting variable (n bits)
T tag (t bits), adjoined to an encrypted message to provide integrity protection
T′ recomputed tag value, generated during the decryption process
W n-bit block computed during the encryption and decryption processes
8.3 Specific requirements
In advance of any use of the mechanism, the originator and recipient of the data to which the
authenticated encryption mechanism is to be applied, shall agree on t, the length of the tag in bits,
where 0 < t ≤ n.
8.4 Definition of function M
Definition of the encryption and decryption procedures requires the definition of a function M that
takes an arbitrary length string of bits and a block cipher key as input and gives an n-bit block as output.
The definition of this function is as follows.
If X is a string of bits, and K is a key for the chosen block cipher, then M (X) shall equal an (untruncated)
K
message authentication code computed on the string X using key K using MAC algorithm 5 of
ISO/IEC 9797-1:2011, where the block cipher used in the MAC algorithm shall be the same as the block
cipher algorithm selected for the authenticated encryption process.
NOTE MAC algorithm 5 of ISO/IEC 9797-1:2011 is also known as CMAC.
10 © ISO/IEC 2020 – All rights reserved
8.5 Encryption procedure
The originator shall perform the following steps to protect a data string D.
a) A starting variable S containing n bits shall be selected. This variable shall be distinct for every
message to be protected, and shall be made available to the recipient of the message. However, it is
not necessary that this value is unpredictable or secret.
n
b) Let E = M (0 ||S).
0 K
n-1
c) Let E = M (0 ||1||A).
1 K
d) Let W = E .
e) Partition D into a sequence of blocks: D , D , …, D , as follows. Let D contain the first n bits of D, D
1 2 m 1 2
the next n bits, and so on, until D contains the final r bits, where 0 < r ≤ n. Thus len(D) = (m-1)n+r.
m
f) For i = 1, 2, ., m-1, perform the following two steps:
1) let C = D ⊕ e (W);
i i K
-1 n
2) let W = # (# (W) +1 mod 2 ).
n
g) Let C = D ⊕ [e (W)]| .
m m K r
n-2
h) Let E = M (0 ||1||0||C ||C ||…||C ).
2 K 1 2 m
i) Let T = [E ⊕ E ⊕ E ]| .
0 1 2 t
The output of the above process, i.e. the authenticated-encrypted version of D, shall be the bit-string:
C = C || C || … || C || T
1 2 m
That is, a string of (m-1)n+r+t bits, that is C contains precisely t bits more than D (although it is also
necessary to convey the n-bit starting variable S and the variable length additional authenticated data
A to the recipient).
8.6 Decryption procedure
The recipient shall perform the following steps to decrypt and verify an authenticated-encrypted string C.
a) If the length of C is less than t, then halt and output INVALID.
b) Let m and r be the unique integers defined so that C contains a total of (m-1)n + r + t bits, where 0 < r ≤
n. Partition C into a sequence of blocks: C , C , …C , T as follows. Let C contain the first n bits of C, C
1 2 m 1 2
the next n bits of C, and so on, until C contains the next r bits of C. Finally, let T be the final t bits of C.
m
n
c) Let E = M (0 ||S).
0 K
n-1
d) Let E = M (0 ||1||A).
1 K
n-2
e) Let E = M (0 ||1||0||C ||C ||…||C ).
2 K 1 2 m
f) Let T′ = [E ⊕ E ⊕ E ]| .
0 1 2 t
g) If T ≠ T′, then halt and output INVALID.
h) Let W = E .
i) For i = 1, 2, ., m-1, perform the following two steps:
1) let D = C ⊕ e (W);
i i K
© ISO/IEC 2020 – All rights reserved 11
-1 n
2) let W = # (# (W) +1 mod 2 ).
n
j) Let D = C ⊕ [e (W)]| .
m m K r
k) Output D and A.
9 Authenticated encryption mechanism 5 (encrypt-then-MAC)
9.1 General
This clause defines an authenticated encryption mechanism made up of the combination of any
encryption mechanism and any MAC scheme. The basic mechanism involves first encrypting the data to
be protected, and then computing a MAC on the resulting encrypted data. An AAD variant mechanism
allows AAD to be authenticated but not encrypted.
NOTE The encrypt-then-MAC approach (without additional authenticated data) has been analysed by
[1]
Bellare and Namprempre, who provide a proof of security on the assumption that the method of encryption
and the MAC technique possess certain security properties. Although their analysis does not consider extending
the technique by including a starting variable or additional authenticated data, it can be shown that security is
maintained in this case.
9.2 Specific notation
For the purposes of the specification of this mechanism, the following symbols and notation apply:
C′ bit string obtained by encrypting the data string D
δ the decryption function, i.e. a function which takes as input a block cipher key K , a starting var-
iable S, and an encrypted data string C′ and, using the selected mode of operation, outputs a de-
′
crypted data string: the output is written δ ()C
KS,
ε the encryption function, i.e. a function which takes as input a block cipher key K , a starting var-
iable S, and a data string D and, using the selected mode of operation, outputs an encrypted data
string: the output is written ε ()D
KS,
f the MAC function
If X is an input string, and K is a MAC key, then the output MAC is written fX() .
K
K secret key for the block cipher
K secret key for the MAC function
S starting variable (n bits)
T tag (t bits), adjoined to an encrypted message to provide integrity protection
T′ recomputed tag value, generated during the decryption process
9.3 Specific requirements
In advance of any use of the mechanism, the originator and recipient of the data to which the
authenticated encryption mechanism is to be applied, shall agree on:
a) a block cipher mode of operation from amongst those specified in ISO/IEC 10116 (the ECB mode
shall not be used);
b) a method for MAC computation, which shall be selected from the techniques specified in
ISO/IEC 9797 (all parts) (it is supposed that the chosen method generates a tag of length t bits); and
12 © ISO/IEC 2020 – All rights reserved
c) a method for obtaining a pair of secret keys (K , K ) from the secret key K, where K is a key for the
1 2 1
selected block cipher and K is a key for the selected method of MAC computation.
NOTE 1 K is chosen so that the number of possible values for K is at least as large as the number of possible
values for the block cipher key, and also at least as large as the number of possible values for the MAC key.
NOTE 2 (K , K ) can be obtained from the secret key K by taking (disjoint) bit strings from K or from h(K),
1 2
where h is a hash-function in ISO/IEC 10118 (all parts). More generally (K , K ) can be obtained from the
1 2
secret key K using a derivation function specified in ISO/IEC 11770-6.
d) whether to use the basic mechanism (that does not support AAD) or to use the AAD variant
mechanism. If using the AAD variant mechanism, then the additional authenticated data string A
shall contain a whole number of octets (possibly zero), i.e. len(A) shall be an integer multiple of 8,
but shall contain fewer than 2 octets (or even less depending on the requirements of the MAC
scheme used).
A single key K shall only be used with one variant, i.e. only with the basic variant or only with the
AAD variant.
9.4 Encryption procedure
The originator shall perform the following steps to protect a data string D and, if using the AAD variant
mechanism, to ensure the integrity of an additional authenticated data string A.
a) A starting variable S appropriate for use with the selected block cipher mode of operation shall be
selected. Security requirements for S are as described in the appropriate clauses of ISO/IEC 10116,
and further guidance is given in A.6.
b) Let C′ = ε ()D .
KS,
If not using the AAD variant:
c) Let T = fS()C′ .
K
If using the AAD variant:
c) If len(A) is not a multiple of 8 or is ≥ 2 , then halt and output INVALID.
Let T = f (# (len(A)/8) || A || S || C′).
K
The output of the above process, i.e. the authenticated-encrypted version of D, shall be the bit-string:
C = C′ || T, together with the starting variable S.
9.5 Decryption procedure
The recipient shall perform the following steps to decrypt and verify an authenticated-encrypted
string C, with accompanying starting variable S and, if using the AAD variant mechanis
...
ISO/IEC 19772:2020 is a document that specifies five methods for authenticated encryption, which means processing data in a way that ensures data confidentiality, integrity, and data origin authentication. These methods are based on a block cipher algorithm and require a shared secret key between the data originator and recipient. The document does not cover key management, as that is defined in ISO/IEC 11770. Four of the mechanisms allow for data to be authenticated without encryption, allowing for a data string to be divided into an encrypted and integrity-protected part and an integrity-protected but unencrypted additional authenticated data part. This is useful for protecting the integrity of certain types of data that need to be sent in unencrypted form, such as addresses, port numbers, sequence numbers, protocol version numbers, and other network protocol fields.
記事のタイトル:ISO/IEC 19772:2020 - 情報セキュリティ-認証された暗号化 記事の内容:この文書は、認証された暗号化に対する5つの方法を指定しており、次のセキュリティ目標に基づいてデータ文字列の処理方法が定義されています。- データの機密性:データの非承認開示からの保護。- データの完全性:データが変更されていないことを受信者が確認できる保護。- データの発信元認証:データの受信者がデータの発信元を確認できる保護。この文書で指定されている5つの方法はすべてブロック暗号アルゴリズムに基づいており、保護されたデータの発信者と受信者がこのブロック暗号の共有秘密鍵を持つ必要があります。キー管理はこの文書の範囲外です。キー管理技術はISO/IEC 11770(すべての部分)で定義されています。この文書で指定されているメカニズムのうち、3、4、5(AADバリアントのみ)および6では、暗号化されていないデータの認証が可能です。つまり、これらのメカニズムによって保護されるデータ文字列を、暗号化および整合性保護された部分であるDと、暗号化されていないが整合性保護された追加認証データであるAに分割することができます。すべての場合で、文字列Aは空にすることができます。なお、アドレス、ポート番号、シーケンス番号、プロトコルバージョン番号、およびその他のネットワークプロトコルフィールドなど、暗号化されていない形式で送信される必要のあるが整合性を保護する必要があるデータの例があります。これらのフィールドは、平文の処理、転送、または処理方法を示します。
기사 제목: ISO/IEC 19772:2020 - 정보 보안 - 인증된 암호화 기사 내용: 이 문서는 인증된 암호화에 대한 다섯 가지 방법을 명시하며, 다음과 같은 보안 목표를 가진 데이터 문자열 처리의 정의된 방식입니다: - 데이터 기밀성: 데이터의 무단 공개로부터의 보호 - 데이터 무결성: 수신자가 데이터가 수정되지 않았음을 검증할 수 있도록 보호 - 데이터 출처 인증: 수신자가 데이터 원본의 신원을 확인할 수 있도록 보호 이 문서에서 명시된 다섯 가지 방법은 모두 블록 암호 알고리즘에 기반하며, 보호된 데이터의 발송자와 수신자가 이 블록 암호에 대한 비밀 키를 공유해야 합니다. 이 문서는 키 관리와는 관련이 없습니다. 키 관리 기술은 ISO/IEC 11770 (모든 부분)에서 정의됩니다. 이 문서에서 명시된 메커니즘 중 3, 4, 5 (AAD 변형만 해당) 및 6은 암호화되지 않은 데이터를 인증할 수 있습니다. 즉, 이러한 메커니즘은 보호되어야 하는 데이터 문자열을 암호화되고 무결성이 보호되는 D (보호된 데이터 문자열)와 암호화되지 않은 무결성이 보호되는 A (추가 인증 데이터)로 나눌 수 있습니다. 모든 경우에 문자열 A는 비어 있을 수 있습니다. 참고로, 암호화되지 않은 형식으로 전송되지만 무결성을 보호해야 하는 데이터 유형의 예로는 주소, 포트 번호, 시퀀스 번호, 프로토콜 버전 번호 및 기타 네트워크 프로토콜 필드가 포함됩니다. 이러한 필드는 평문이 어떻게 처리, 전달 또는 처리되어야 하는지를 나타냅니다.








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...