Multilinear Galois Mode (MGM)CryptoPro+7 (495) 995-48-20svs@cryptopro.ruTC 26nozdrunov_vi@tc26.ruTC 26shishkin_va@tc26.ruCryptoProgriboedovaekaterina@gmail.com
General
Network Working Groupauthenticated encryptionmode of operationAEAD
Multilinear Galois Mode (MGM) is an Authenticated Encryption
with Associated Data (AEAD) block cipher mode based on the
Encrypt-then-MAC (EtM) principle. MGM is defined for use with
64-bit and 128-bit block ciphers.
MGM has been standardized in Russia. It is used as an AEAD
mode for the GOST block cipher algorithms in many protocols,
e.g., TLS 1.3 and IPsec. This document provides a reference for
MGM to enable review of the mechanisms in use and to make MGM
available for use with any block cipher.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any
other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value
for implementation or deployment. Documents approved for
publication by the RFC Editor are not candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
. Introduction
. Conventions Used in This Document
. Basic Terms and Definitions
. Specification
. MGM Encryption and Tag Generation Procedure
. MGM Decryption and Tag Verification Check Procedure
. Rationale
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
. Test Vectors
. Test Vectors for the Kuznyechik Block Cipher
. Example 1
. Example 2
. Test Vectors for the Magma Block Cipher
. Example 1
. Example 2
Contributors
Authors' Addresses
Introduction
Multilinear Galois Mode (MGM) is an Authenticated Encryption
with Associated Data (AEAD) block cipher mode based on EtM
principle. MGM is defined for use with 64-bit and 128-bit
block ciphers. The MGM design principles can easily be
applied to other block sizes.
MGM has been standardized in Russia . It is used as
an AEAD mode for the GOST block cipher algorithms in many
protocols, e.g., TLS 1.3 and IPsec. This document provides a
reference for MGM to enable review of the mechanisms in use
and to make MGM available for use with any block cipher.
This document does not have IETF consensus and does not imply
IETF support for MGM.
Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be
interpreted as described in BCP 14
when, and only when, they appear in all capitals, as shown
here.
Basic Terms and Definitions This document uses the following terms and definitions for the sets and operations
on the elements of these sets:
V*
The set of all bit strings of a finite length
(hereinafter referred to as strings), including the
empty string; substrings and string components are
enumerated from right to left starting from zero.
V_s
The set of all bit strings of length s, where s is a
non-negative integer. For s = 0, the V_0 consists of a
single empty string.
|X|
The bit length of the bit string X (if X is an empty
string, then |X| = 0).
X || Y
Concatenation of strings X and Y both belonging to V*,
i.e., a string from V_{|X|+|Y|}, where the left
substring from V_{|X|} is equal to X, and the right
substring from V_{|Y|} is equal to Y.
a^s
The string in V_s that consists of s 'a' bits.
(xor)
Exclusive-or of two bit strings of the same
length.
Z_{2^s}
Ring of residues modulo 2^s.
MSB_i
V_s -> V_iThe transformation that maps the string X =
(x_{s-1}, ... , x_0) in V_s into the string MSB_i(X) =
(x_{s-1}, ... , x_{s-i}) in V_i, i <= s (most
significant bits).
Int_s
V_s -> Z_{2^s}The transformation that maps the string X =
(x_{s-1}, ... , x_0) in V_s, s > 0, into the integer
Int_s(X) = 2^{s-1} * x_{s-1} + ... + 2 * x_1 + x_0 (the
interpretation of the bit string as an integer).
Vec_s
Z_{2^s} -> V_sThe transformation inverse to the mapping Int_s
(the interpretation of an integer as a bit string).
E_K
V_n -> V_nThe block cipher permutation under the key K in V_k.
k
The bit length of the block cipher key.
n
The block size of the block cipher (in bits).
len
V_s -> V_{n/2}The transformation that maps a string X in V_s, 0
<= s <= 2^{n/2} - 1, into the string len(X) =
Vec_{n/2}(|X|) in V_{n/2}, where n is the block size
of the used block cipher.
[+]
The addition operation in Z_{2^{n/2}}, where n is the
block size of the used block cipher.
(x)
The transformation that maps two strings, X = (x_{n-1},
... , x_0) in V_n and Y = (y_{n-1}, ... , y_0), in V_n
into the string Z = X (x) Y = (z_{n-1}, ... , z_0) in
V_n; the string Z corresponds to the polynomial Z(w) =
z_{n-1} * w^{n-1} + ... + z_1 * w + z_0, which is the
result of multiplying the polynomials X(w) = x_{n-1} *
w^{n-1} + ... + x_1 * w + x_0 and Y(w) = y_{n-1} *
w^{n-1} + ... + y_1 * w + y_0 in the field GF(2^n),
where n is the block size of the used block cipher; if
n = 64, then the field polynomial is equal to f(w) =
w^64 + w^4 + w^3 + w + 1; if n = 128, then the field
polynomial is equal to f(w) = w^128 + w^7 + w^2 + w +
1.
incr_l
V_n -> V_n
The transformation that maps an n-byte string A = L || R into the n-byte
string incr_l(A) = Vec_{n/2}(Int_{n/2}(L) [+] 1) || R, where L and R are
n/2-byte strings.
incr_r
V_n -> V_n
The transformation that maps an n-byte string A = L || R into the n-byte
string incr_r(A) = L || Vec_{n/2}(Int_{n/2}(R) [+] 1), where L and R are
n/2-byte strings.
Specification
An additional parameter that defines the functioning of
MGM is the bit length S of the
authentication tag, 32 <= S <= n. The value of S
MUST be fixed for a particular protocol. The
choice of the value S involves a trade-off between message
expansion and the forgery probability.
MGM Encryption and Tag Generation Procedure
The MGM encryption and tag generation procedure takes the
following parameters as inputs:
Encryption key K in V_k.
Initial counter nonce ICN in V_{n-1}.
Associated authenticated data A, 0 <= |A| <
2^{n/2}. If |A| > 0, then A = A_1 || ... ||
A*_h, A_j in V_n, for j = 1, ... , h - 1, A*_h in
V_t, 1 <= t <= n. If |A| = 0, then by
definition A*_h is empty, and the h and t
parameters are set as follows: h = 0, t = n. The
associated data is authenticated but is not
encrypted.
Plaintext P, 0 <= |P| < 2^{n/2}. If |P| >
0, then P = P_1 || ... || P*_q, P_i in V_n, for i
= 1, ... , q - 1, P*_q in V_u, 1 <= u <=
n. If |P| = 0, then by definition P*_q is empty,
and the q and u parameters are set as follows: q =
0, u = n.
The MGM encryption and tag generation procedure outputs
the following parameters:
Initial counter nonce ICN.
Associated authenticated data A.
Ciphertext C in V_{|P|}.
Authentication tag T in V_S.
The MGM encryption and tag generation procedure consists
of the following steps:
+----------------------------------------------------------------+
| MGM-Encrypt(K, ICN, A, P) |
|----------------------------------------------------------------|
| 1. Encryption step: |
| - if |P| = 0 then |
| - C*_q = P*_q |
| - C = P |
| - else |
| - Y_1 = E_K(0^1 || ICN), |
| - For i = 2, 3, ... , q do |
| Y_i = incr_r(Y_{i-1}), |
| - For i = 1, 2, ... , q - 1 do |
| C_i = P_i (xor) E_K(Y_i), |
| - C*_q = P*_q (xor) MSB_u(E_K(Y_q)), |
| - C = C_1 || ... || C*_q. |
| |
| 2. Padding step: |
| - A_h = A*_h || 0^{n-t}, |
| - C_q = C*_q || 0^{n-u}. |
| |
| 3. Authentication tag T generation step: |
| - Z_1 = E_K(1^1 || ICN), |
| - sum = 0^n, |
| - For i = 1, 2, ..., h do |
| H_i = E_K(Z_i), |
| sum = sum (xor) ( H_i (x) A_i ), |
| Z_{i+1} = incr_l(Z_i), |
| - For j = 1, 2, ..., q do |
| H_{h+j} = E_K(Z_{h+j}), |
| sum = sum (xor) ( H_{h+j} (x) C_j ), |
| Z_{h+j+1} = incr_l(Z_{h+j}), |
| - H_{h+q+1} = E_K(Z_{h+q+1}), |
| - T = MSB_S(E_K(sum (xor) ( H_{h+q+1} (x) |
| ( len(A) || len(C) ) ))). |
| |
| 4. Return (ICN, A, C, T). |
+----------------------------------------------------------------+
The ICN value for each message that is encrypted under
the given key K must be chosen in a unique manner.
Users who do not wish to encrypt plaintext can provide a
string P of zero length. Users who do not wish to
authenticate associated data can provide a string A of
zero length. The length of the associated data A and of
the plaintext P MUST be such that 0 <
|A| + |P| < 2^{n/2}.
MGM Decryption and Tag Verification Check Procedure
The MGM decryption and tag verification procedure takes the following parameters as inputs:
Encryption key K in V_k.
Initial counter nonce ICN in V_{n-1}.
Associated authenticated data A, 0 <= |A| <
2^{n/2}. If |A| > 0, then A = A_1 || ... ||
A*_h, A_j in V_n, for j = 1, ... , h - 1, A*_h in
V_t, 1 <= t <= n. If |A| = 0, then by
definition A*_h is empty, and the h and t
parameters are set as follows: h = 0, t = n. The
associated data is authenticated but is not
encrypted.
Ciphertext C, 0 <= |C| < 2^{n/2}. If |C| > 0, then C = C_1 || ... || C*_q, C_i in V_n, for i = 1, ... , q - 1, C*_q in V_u, 1 <= u <= n.
If |C| = 0, then by definition C*_q is empty, and the q and u parameters
are set as follows: q = 0, u = n.
Authentication tag T in V_S.
The MGM decryption and tag verification procedure outputs FAIL or the following parameters:
Associated authenticated data A.
Plaintext P in V_{|C|}.
The MGM decryption and tag verification procedure consists of the following steps:
+----------------------------------------------------------------+
| MGM-Decrypt(K, ICN, A, C, T) |
|----------------------------------------------------------------|
| 1. Padding step: |
| - A_h = A*_h || 0^{n-t}, |
| - C_q = C*_q || 0^{n-u}. |
| |
| 2. Authentication tag T verification step: |
| - Z_1 = E_K(1^1 || ICN), |
| - sum = 0^n, |
| - For i = 1, 2, ..., h do |
| H_i = E_K(Z_i), |
| sum = sum (xor) ( H_i (x) A_i ), |
| Z_{i+1} = incr_l(Z_i), |
| - For j = 1, 2, ..., q do |
| H_{h+j} = E_K(Z_{h+j}), |
| sum = sum (xor) ( H_{h+j} (x) C_j ), |
| Z_{h+j+1} = incr_l(Z_{h+j}), |
| - H_{h+q+1} = E_K(Z_{h+q+1}), |
| - T' = MSB_S(E_K(sum (xor) ( H_{h+q+1} (x) |
| ( len(A) || len(C) ) ))), |
| - If T' != T then return FAIL. |
| |
| 3. Decryption step: |
| - if |C| = 0 then |
| - P = C |
| - else |
| - Y_1 = E_K(0^1 || ICN), |
| - For i = 2, 3, ... , q do |
| Y_i = incr_r(Y_{i-1}), |
| - For i = 1, 2, ... , q - 1 do |
| P_i = C_i (xor) E_K(Y_i), |
| - P*_q = C*_q (xor) MSB_u(E_K(Y_q)), |
| - P = P_1 || ... || P*_q. |
| |
| 4. Return (A, P). |
+----------------------------------------------------------------+
The length of the associated data A and of the ciphertext C MUST be such that 0 < |A| + |C| < 2^{n/2}.
Rationale
MGM was originally proposed in .
From the operational point of view, MGM is designed to be
parallelizable, inverse free, and online and is also designed to provide
availability of precomputations.
Parallelizability of MGM is achieved due to its
counter-type structure and the usage of the multilinear
function for authentication. Indeed, both encryption blocks
E_K(Y_i) and authentication blocks H_i are produced in the
counter mode manner, and the multilinear function determined
by H_i is parallelizable in itself. Additionally, the
counter-type structure of the mode provides the inverse-free
property.
The online property means the possibility of processing messages
even if it is not completely received (so its length is
unknown). To provide this property, MGM uses blocks
E_K(Y_i) and H_i, which are produced based on two independent
source blocks Y_i and Z_i.
Availability of precomputations for MGM means the possibility of calculating H_i and E_K(Y_i) even before
data is retrieved. It holds again due to the usage of counters for calculating them.
Security Considerations
The security properties of MGM are based on the following:
Different functions generating the counter values:
The functions incr_r and incr_l are chosen to minimize
intersection (if it happens) of counter values Y_i and Z_i.
Encryption of the multilinear function output:
It allows attacks based on padding
and linear properties to be resisted (see for details).
Multilinear function for authentication:
It allows the small subgroup attacks to be resisted .
Encryption of the nonces (0^1 || ICN) and (1^1 || ICN):
The use of this encryption minimizes the number of
plaintext/ciphertext pairs of blocks known to an adversary.
It prevents attacks that need a substantial amount of such material (e.g.,
linear and differential cryptanalysis and side-channel attacks).
It is crucial to the security of MGM to use unique ICN
values. Using the same ICN values for two different messages
encrypted with the same key eliminates the security properties
of this mode.
It is crucial for the security of MGM not to process empty
plaintext and empty associated data at the same
time. Otherwise, a tag becomes independent from a nonce value,
leading to vulnerability to forgery attacks.
Security analysis for MGM with E_K being a random permutation
was performed in . More precisely, the bounds for
confidentiality advantage (CA) and integrity advantage (IA)
(for details, see ) were obtained. According to these results,
for an adversary making at most q encryption queries with the
total length of plaintexts and associated data of at most s
blocks, and allowed to output a forgery with the summary length
of ciphertext and associated data of at most l blocks:
CA <= ( 3( s + 4q )^2 )/ 2^n,
IA <= ( 3( s + 4q + l + 3 )^2 )/ 2^n + 2/2^S,
where n is the block size and S is the authentication tag size.
These bounds can be used as guidelines on how to calculate
confidentiality and integrity limits (for details, also see
).
IANA Considerations
This document has no IANA actions.
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.GOST R 34.12-2015: Block Cipher "Kuznyechik"This document is intended to be a source of information about the Russian Federal standard GOST R 34.12-2015 describing the block cipher with a block length of n=128 bits and a key length of k=256 bits, which is also referred to as "Kuznyechik". This algorithm is one of the set of Russian cryptographic standard algorithms (called GOST algorithms).Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.GOST R 34.12-2015: Block Cipher "Magma"In addition to a new cipher with a block length of n=128 bits (referred to as "Kuznyechik" and described in RFC 7801), Russian Federal standard GOST R 34.12-2015 includes an updated version of the block cipher with a block length of n=64 bits and key length of k=256 bits, which is also referred to as "Magma". The algorithm is an updated version of an older block cipher with a block length of n=64 bits described in GOST 28147-89 (RFC 5830). This document is intended to be a source of information about the updated version of the 64-bit cipher. It may facilitate the use of the block cipher in Internet applications by providing information for developers and users of the GOST 64-bit cipher with the revised version of the cipher for encryption and decryption.Informative ReferencesUsage Limits on AEAD AlgorithmsETH ZurichMozillaCloudflare An Authenticated Encryption with Associated Data (AEAD) algorithm
provides confidentiality and integrity. Excessive use of the same
key can give an attacker advantages in breaking these properties.
This document provides simple guidance for users of common AEAD
functions about how to limit the use of keys in order to bound the
advantage given to an attacker. It considers limits in both single-
and multi-key settings.
Work in ProgressInformation technology. Cryptographic data security. Authenticated encryption block cipher operation modesFederal Agency on Technical Regulating and MetrologyR 1323565.1.026-2019Authentication weaknesses in GCMInformation technology. Cryptographic data security. Block ciphersFederal Agency on Technical Regulating and MetrologyGOST R 34.12-2015Parallel and double block cipher mode of operation (PD-mode) for authenticated encryptionCTCrypt 2017 proceedings, pp. 36-45 Cycling Attacks on GCM, GHASH and Other Polynomial MACs and HashesFast Software EncryptionFSE 2012 proceedings, pp. 216-225Security of Multilinear Galois Mode (MGM)IACR Cryptology ePrint Archive 2019, pp. 123Test VectorsTest Vectors for the Kuznyechik Block Cipher
Test vectors for the Kuznyechik block cipher (n = 128, k = 256) are defined in (the English version can be found in ).
Example 1
Encryption key K:
00000: 88 99 AA BB CC DD EE FF 00 11 22 33 44 55 66 77
00010: FE DC BA 98 76 54 32 10 01 23 45 67 89 AB CD EF
ICN:
00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88
Associated authenticated data A:
00000: 02 02 02 02 02 02 02 02 01 01 01 01 01 01 01 01
00010: 04 04 04 04 04 04 04 04 03 03 03 03 03 03 03 03
00020: EA 05 05 05 05 05 05 05 05
Plaintext P:
00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88
00010: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A
00020: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00
00030: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11
00040: AA BB CC
Encryption step:
0^1 || ICN:
00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88
Y_1:
00000: 7F 67 9D 90 BE BC 24 30 5A 46 8D 42 B9 D4 ED CD
E_K(Y_1):
00000: B8 57 48 C5 12 F3 19 90 AA 56 7E F1 53 35 DB 74
Y_2:
00000: 7F 67 9D 90 BE BC 24 30 5A 46 8D 42 B9 D4 ED CE
E_K(Y_2):
00000: 80 64 F0 12 6F AC 9B 2C 5B 6E AC 21 61 2F 94 33
Y_3:
00000: 7F 67 9D 90 BE BC 24 30 5A 46 8D 42 B9 D4 ED CF
E_K(Y_3):
00000: 58 58 82 1D 40 C0 CD 0D 0A C1 E6 C2 47 09 8F 1C
Y_4:
00000: 7F 67 9D 90 BE BC 24 30 5A 46 8D 42 B9 D4 ED D0
E_K(Y_4):
00000: E4 3F 50 81 B5 8F 0B 49 01 2F 8E E8 6A CD 6D FA
Y_5:
00000: 7F 67 9D 90 BE BC 24 30 5A 46 8D 42 B9 D4 ED D1
E_K(Y_5):
00000: 86 CE 9E 2A 0A 12 25 E3 33 56 91 B2 0D 5A 33 48
C:
00000: A9 75 7B 81 47 95 6E 90 55 B8 A3 3D E8 9F 42 FC
00010: 80 75 D2 21 2B F9 FD 5B D3 F7 06 9A AD C1 6B 39
00020: 49 7A B1 59 15 A6 BA 85 93 6B 5D 0E A9 F6 85 1C
00030: C6 0C 14 D4 D3 F8 83 D0 AB 94 42 06 95 C7 6D EB
00040: 2C 75 52
Authentication tag T generation step:
1^1 || ICN:
00000: 91 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88
Z_1:
00000: 79 32 72 68 96 C4 3E 3F BF D6 50 89 EB F1 E5 B6
H_1:
00000: 99 3A 80 66 CC C0 A4 0F AC 4A 14 F7 A2 F6 6D 9B
current sum:
00000: 0A C1 1E 2C 1C D6 07 D8 2F E3 55 54 B4 01 02 81
Z_2:
00000: 79 32 72 68 96 C4 3E 40 BF D6 50 89 EB F1 E5 B6
H_2:
00000: 0C 38 A7 1E E7 93 BF 76 89 81 BF CD 7C DA 78 C8
len(A) || len(C):
00000: 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00
sum (xor) ( H_2 (x) ( len(A) || len(C) ) ):
00000: CA 1E F8 92 71 EA 60 C4 53 9E 40 EB 26 C2 80 5D
Tag T:
00000: 79 01 E9 EA 20 85 CD 24 7E D2 49 69 5F 9F 8A 85
Test Vectors for the Magma Block Cipher
Test vectors for the Magma block cipher (n = 64, k = 256) are
defined in
(the English version can be found in ).
Example 1
Encryption key K:
00000: FF EE DD CC BB AA 99 88 77 66 55 44 33 22 11 00
00010: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF
ICN:
00000: 12 DE F0 6B 3C 13 0A 59
Associated authenticated data A:
00000: 01 01 01 01 01 01 01 01 02 02 02 02 02 02 02 02
00010: 03 03 03 03 03 03 03 03 04 04 04 04 04 04 04 04
00020: 05 05 05 05 05 05 05 05 EA
Plaintext P:
00000: FF EE DD CC BB AA 99 88 11 22 33 44 55 66 77 00
00010: 88 99 AA BB CC EE FF 0A 00 11 22 33 44 55 66 77
00020: 99 AA BB CC EE FF 0A 00 11 22 33 44 55 66 77 88
00030: AA BB CC EE FF 0A 00 11 22 33 44 55 66 77 88 99
00040: AA BB CC
Authentication tag T generation step:
1^1 || ICN:
00000: 80 77 66 55 44 33 22 11
Z_1:
00000: 59 73 54 78 7E 52 E6 EB
H_1:
00000: EC E3 F9 DA 11 8C 7D 95
current sum:
00000: 25 D0 E4 20 7B 6B F6 3D
Z_2:
00000: 59 73 54 79 7E 52 E6 EB
H_2:
00000: 31 0C 0D AC C9 D0 4D 93
len(A) || len(C):
00000: 00 00 00 00 00 00 00 40
sum (xor) ( H_2 (x) ( len(A) || len(C) ) ):
00000: 66 D3 8F 12 0F 78 92 49
Tag T:
00000: 33 4E E2 70 45 0B EC 9E
ContributorsCryptoProalekseev@cryptopro.ruCryptoProbabueva@cryptopro.ruCryptoProlah@cryptopro.ruTC 26marshalko_gb@tc26.ruTC 26rudskoy_vi@tc26.ruNational Research University Higher School of Economicsanesterenko@hse.ruCryptoPronikiforova@cryptopro.ruAuthors' AddressesCryptoPro+7 (495) 995-48-20svs@cryptopro.ruTC 26nozdrunov_vi@tc26.ruTC 26shishkin_va@tc26.ruCryptoProgriboedovaekaterina@gmail.com