Multilinear Galois Mode (MGM)
An authenticated encryption mode that works with the GOST block ciphers and with any other block cipher.
Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E. Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058, DOI 10.17487/RFC9058, June 2021, <https://www.rfc-editor.org/info/rfc9058>.
@misc{rfc9058,
series = {Request for Comments},
number = 9058,
howpublished = {RFC 9058},
publisher = {RFC Editor},
doi = {10.17487/RFC9058},
url = {https://www.rfc-editor.org/info/rfc9058},
author = {S. Smyshlyaev and V. Nozdrunov and V. Shishkin and E. Griboedova},
title = {{Multilinear Galois Mode (MGM)}},
pagetotal = 25,
year = 2021,
month = jun,
} RFC text
Contents
Independent Submission S. Smyshlyaev, Ed.
Request for Comments: 9058 CryptoPro
Category: Informational V. Nozdrunov
ISSN: 2070-1721 V. Shishkin
TC 26
E. Griboedova
CryptoPro
June 2021
Multilinear Galois Mode (MGM)
Abstract
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
https://www.rfc-editor.org/info/rfc9058.
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
(https://trustee.ietf.org/license-info) 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
1. Introduction
2. Conventions Used in This Document
3. Basic Terms and Definitions
4. Specification
4.1. MGM Encryption and Tag Generation Procedure
4.2. MGM Decryption and Tag Verification Check Procedure
5. Rationale
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Test Vectors
A.1. Test Vectors for the Kuznyechik Block Cipher
A.1.1. Example 1
A.1.2. Example 2
A.2. Test Vectors for the Magma Block Cipher
A.2.1. Example 1
A.2.2. Example 2
Contributors
Authors' Addresses
1. 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 [AUTH-ENC-BLOCK-CIPHER]. 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.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. 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_i
The 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_s
The transformation inverse to the mapping Int_s (the
interpretation of an integer as a bit string).
E_K V_n -> V_n
The 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.
4. 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.
4.1. MGM Encryption and Tag Generation Procedure
The MGM encryption and tag generation procedure takes the following
parameters as inputs:
1. Encryption key K in V_k.
2. Initial counter nonce ICN in V_{n-1}.
3. 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.
4. 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:
1. Initial counter nonce ICN.
2. Associated authenticated data A.
3. Ciphertext C in V_{|P|}.
4. 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}.
4.2. MGM Decryption and Tag Verification Check Procedure
The MGM decryption and tag verification procedure takes the following
parameters as inputs:
1. Encryption key K in V_k.
2. Initial counter nonce ICN in V_{n-1}.
3. 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.
4. 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.
5. Authentication tag T in V_S.
The MGM decryption and tag verification procedure outputs FAIL or the
following parameters:
1. Associated authenticated data A.
2. 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}.
5. Rationale
MGM was originally proposed in [PDMODE].
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.
6. 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 [FERG05] for details).
Multilinear function for authentication:
It allows the small subgroup attacks to be resisted [SAAR12].
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 [SEC-MGM]. More precisely, the bounds for
confidentiality advantage (CA) and integrity advantage (IA) (for
details, see [AEAD-LIMITS]) 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
[AEAD-LIMITS]).
7. IANA Considerations
This document has no IANA actions.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher
"Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016,
<https://www.rfc-editor.org/info/rfc7801>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015:
Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891,
September 2020, <https://www.rfc-editor.org/info/rfc8891>.
8.2. Informative References
[AEAD-LIMITS]
Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on
AEAD Algorithms", Work in Progress, Internet-Draft, draft-
irtf-cfrg-aead-limits-02, 22 February 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
aead-limits-02>.
[AUTH-ENC-BLOCK-CIPHER]
Federal Agency on Technical Regulating and Metrology,
"Information technology. Cryptographic data security.
Authenticated encryption block cipher operation modes", R
1323565.1.026-2019, 2019.
[FERG05] Ferguson, N., "Authentication weaknesses in GCM", May
2005.
[GOST3412-2015]
Federal Agency on Technical Regulating and Metrology,
"Information technology. Cryptographic data security.
Block ciphers", GOST R 34.12-2015, 2015.
[PDMODE] Nozdrunov, V., "Parallel and double block cipher mode of
operation (PD-mode) for authenticated encryption", CTCrypt
2017 proceedings, pp. 36-45, June 2017.
[SAAR12] Saarinen, M-J., "Cycling Attacks on GCM, GHASH and Other
Polynomial MACs and Hashes", FSE 2012 proceedings, pp.
216-225, DOI 10.1007/978-3-642-34047-5_13, 2012,
<https://doi.org/10.1007/978-3-642-34047-5_13>.
[SEC-MGM] Akhmetzyanova, L., Alekseev, E., Karpunin, G., and V.
Nozdrunov, "Security of Multilinear Galois Mode (MGM)",
IACR Cryptology ePrint Archive 2019, pp. 123, 2019.
Appendix A. Test Vectors
A.1. Test Vectors for the Kuznyechik Block Cipher
Test vectors for the Kuznyechik block cipher (n = 128, k = 256) are
defined in [GOST3412-2015] (the English version can be found in
[RFC7801]).
A.1.1. 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
1. 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
2. Padding step:
A_1 || ... || A_h:
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 00 00 00 00 00 00 00
C_1 || ... || C_q:
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 00 00 00 00 00 00 00 00 00 00 00 00 00
3. 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: 7F C2 45 A8 58 6E 66 02 A7 BB DB 27 86 BD C6 6F
H_1:
00000: 8D B1 87 D6 53 83 0E A4 BC 44 64 76 95 2C 30 0B
current sum:
00000: 4C F4 27 F4 AD B7 5C F4 C0 DA 39 D5 AB 48 CF 38
Z_2:
00000: 7F C2 45 A8 58 6E 66 03 A7 BB DB 27 86 BD C6 6F
H_2:
00000: 7A 24 F7 26 30 E3 76 37 21 C8 F3 CD B1 DA 0E 31
current sum:
00000: 94 95 44 0E F6 24 A1 DD C6 F5 D9 77 28 50 C5 73
Z_3:
00000: 7F C2 45 A8 58 6E 66 04 A7 BB DB 27 86 BD C6 6F
H_3:
00000: 44 11 96 21 17 D2 06 35 C5 25 E0 A2 4D B4 B9 0A
current sum:
00000: A4 9A 8C D8 A6 F2 74 23 DB 79 E4 4A B3 06 D9 42
Z_4:
00000: 7F C2 45 A8 58 6E 66 05 A7 BB DB 27 86 BD C6 6F
H_4:
00000: D8 C9 62 3C 4D BF E8 14 CE 7C 1C 0C EA A9 59 DB
current sum:
00000: 09 FE 3F 6A 83 3C 21 B3 90 27 D0 20 6A 84 E1 5A
Z_5:
00000: 7F C2 45 A8 58 6E 66 06 A7 BB DB 27 86 BD C6 6F
H_5:
00000: A5 E1 F1 95 33 3E 14 82 96 99 31 BF BE 6D FD 43
current sum:
00000: B5 DA 26 BB 00 EB A8 04 35 D7 97 6B C6 B5 46 4D
Z_6:
00000: 7F C2 45 A8 58 6E 66 07 A7 BB DB 27 86 BD C6 6F
H_6:
00000: B4 CA 80 8C AC CF B3 F9 17 24 E4 8A 2C 7E E9 D2
current sum:
00000: DD 1C 0E EE F7 83 C8 EB 2A 33 F3 58 D7 23 0E E5
Z_7:
00000: 7F C2 45 A8 58 6E 66 08 A7 BB DB 27 86 BD C6 6F
H_7:
00000: 72 90 8F C0 74 E4 69 E8 90 1B D1 88 EA 91 C3 31
current sum:
00000: 89 6C E1 08 32 EB EA F9 06 9F 3F 73 76 59 4D 40
Z_8:
00000: 7F C2 45 A8 58 6E 66 09 A7 BB DB 27 86 BD C6 6F
H_8:
00000: 23 CA 27 15 B0 2C 68 31 3B FD AC B3 9E 4D 0F B8
current sum:
00000: 99 1A F5 C9 D0 80 F7 63 87 FE 64 9E 7C 93 C6 42
Z_9:
00000: 7F C2 45 A8 58 6E 66 0A A7 BB DB 27 86 BD C6 6F
H_9:
00000: BC BC E6 C4 1A A3 55 A4 14 88 62 BF 64 BD 83 0D
len(A) || len(C):
00000: 00 00 00 00 00 00 01 48 00 00 00 00 00 00 02 18
sum (xor) ( H_9 (x) ( len(A) || len(C) ) ):
00000: C0 C7 22 DB 5E 0B D6 DB 25 76 73 83 3D 56 71 28
Tag T:
00000: CF 5D 65 6F 40 C3 4F 5C 46 E8 BB 0E 29 FC DB 4C
A.1.2. Example 2
Encryption key K:
00000: 99 AA BB CC DD EE FF 00 11 22 33 44 55 66 77 FE
00010: DC BA 98 76 54 32 10 01 23 45 67 89 AB CD EF 88
ICN:
00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88
Associated authenticated data A:
00000: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
Plaintext P:
00000:
1. Encryption step:
C:
00000:
2. Padding step:
A_1 || ... || A_h:
00000: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
C_1 || ... || C_q:
00000:
3. 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
A.2. Test Vectors for the Magma Block Cipher
Test vectors for the Magma block cipher (n = 64, k = 256) are defined
in [GOST3412-2015] (the English version can be found in [RFC8891]).
A.2.1. 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
1. Encryption step:
0^1 || ICN:
00000: 12 DE F0 6B 3C 13 0A 59
Y_1:
00000: 56 23 89 01 62 DE 31 BF
E_K(Y_1):
00000: 38 7B DB A0 E4 34 39 B3
Y_2:
00000: 56 23 89 01 62 DE 31 C0
E_K(Y_2):
00000: 94 33 00 06 10 F7 F2 AE
Y_3:
00000: 56 23 89 01 62 DE 31 C1
E_K(Y_3):
00000: 97 B7 AA 6D 73 C5 87 57
Y_4:
00000: 56 23 89 01 62 DE 31 C2
E_K(Y_4):
00000: 94 15 52 8B FF C9 E8 0A
Y_5:
00000: 56 23 89 01 62 DE 31 C3
E_K(Y_5):
00000: 03 F7 68 BF F1 82 D6 70
Y_6:
00000: 56 23 89 01 62 DE 31 C4
E_K(Y_6):
00000: FD 05 F8 4E 9B 09 D2 FE
Y_7:
00000: 56 23 89 01 62 DE 31 C5
E_K(Y_7):
00000: DA 4D 90 8A 95 B1 75 C4
Y_8:
00000: 56 23 89 01 62 DE 31 C6
E_K(Y_8):
00000: 65 99 73 96 DA C2 4B D7
Y_9:
00000: 56 23 89 01 62 DE 31 C7
E_K(Y_9):
00000: A9 00 50 4A 14 8D EE 26
C:
00000: C7 95 06 6C 5F 9E A0 3B 85 11 33 42 45 91 85 AE
00010: 1F 2E 00 D6 BF 2B 78 5D 94 04 70 B8 BB 9C 8E 7D
00020: 9A 5D D3 73 1F 7D DC 70 EC 27 CB 0A CE 6F A5 76
00030: 70 F6 5C 64 6A BB 75 D5 47 AA 37 C3 BC B5 C3 4E
00040: 03 BB 9C
2. Padding step:
A_1 || ... || A_h:
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 00 00 00 00 00 00 00
C_1 || ... || C_q:
00000: C7 95 06 6C 5F 9E A0 3B 85 11 33 42 45 91 85 AE
00010: 1F 2E 00 D6 BF 2B 78 5D 94 04 70 B8 BB 9C 8E 7D
00020: 9A 5D D3 73 1F 7D DC 70 EC 27 CB 0A CE 6F A5 76
00030: 70 F6 5C 64 6A BB 75 D5 47 AA 37 C3 BC B5 C3 4E
00040: 03 BB 9C 00 00 00 00 00
3. Authentication tag T generation step:
1^1 || ICN:
00000: 92 DE F0 6B 3C 13 0A 59
Z_1:
00000: 2B 07 3F 04 94 F3 72 A0
H_1:
00000: 70 8A 78 19 1C DD 22 AA
current sum:
00000: D6 BB 5B EA 81 93 12 62
Z_2:
00000: 2B 07 3F 05 94 F3 72 A0
H_2:
00000: 6F 02 CC 46 4B 2F A0 A3
current sum:
00000: DD 1C 82 4E 91 78 49 A5
Z_3:
00000: 2B 07 3F 06 94 F3 72 A0
H_3:
00000: 9F 81 F2 26 FD 19 6F 05
current sum:
00000: 05 89 22 17 F6 5A DA C7
Z_4:
00000: 2B 07 3F 07 94 F3 72 A0
H_4:
00000: B9 C2 AC 9B E5 B5 DF F9
current sum:
00000: D1 DB 9B 7F C4 9E 7C 97
Z_5:
00000: 2B 07 3F 08 94 F3 72 A0
H_5:
00000: 74 B5 EC 96 55 1B F8 88
current sum:
00000: 56 45 F6 B5 18 5C B7 1A
Z_6:
00000: 2B 07 3F 09 94 F3 72 A0
H_6:
00000: 7E B0 21 A4 03 5B 04 C3
current sum:
00000: 3F C2 C2 E6 FB EE D0 4D
Z_7:
00000: 2B 07 3F 0A 94 F3 72 A0
H_7:
00000: C2 A9 C3 A8 70 4D 9B B0
current sum:
00000: 15 47 1F B5 CD 8E 6C 02
Z_8:
00000: 2B 07 3F 0B 94 F3 72 A0
H_8:
00000: F5 D5 05 A8 7B 83 83 B5
current sum:
00000: 12 56 78 96 1D 40 E0 93
Z_9:
00000: 2B 07 3F 0C 94 F3 72 A0
H_9:
00000: F7 95 E7 5F DE B8 93 3C
current sum:
00000: 6E F4 0A B0 C1 5F 20 48
Z_10:
00000: 2B 07 3F 0D 94 F3 72 A0
H_10:
00000: 65 A1 A3 E6 80 F0 81 45
current sum:
00000: A4 64 A7 08 FF 45 14 22
Z_11:
00000: 2B 07 3F 0E 94 F3 72 A0
H_11:
00000: 1C 74 A5 76 4C B0 D5 95
current sum:
00000: 60 94 4E 05 D0 85 75 14
Z_12:
00000: 2B 07 3F 0F 94 F3 72 A0
H_12:
00000: DC 84 47 A5 14 E7 83 E7
current sum:
00000: EE 98 B9 B5 0F F7 83 E8
Z_13:
00000: 2B 07 3F 10 94 F3 72 A0
H_13:
00000: A7 E3 AF E0 04 EE 16 E3
current sum:
00000: C0 39 0F A2 28 AF 6D CB
Z_14:
00000: 2B 07 3F 11 94 F3 72 A0
H_14:
00000: A5 AA BB 0B 79 80 D0 71
current sum:
00000: 73 E0 6E 07 EF 37 CD CC
Z_15:
00000: 2B 07 3F 12 94 F3 72 A0
H_15:
00000: 6E 10 4C C9 33 52 5C 5D
current sum:
00000: 2F 40 69 0A EB 53 F5 39
Z_16:
00000: 2B 07 3F 13 94 F3 72 A0
H_16:
00000: 83 11 B6 02 4A A9 66 C1
len(A) || len(C):
00000: 00 00 01 48 00 00 02 18
sum (xor) ( H_16 (x) ( len(A) || len(C) ) ):
00000: 73 CE F4 4B AE 6B DB 61
Tag T:
00000: A7 92 80 69 AA 10 FD 10
A.2.2. Example 2
Encryption key K:
00000: 99 AA BB CC DD EE FF 00 11 22 33 44 55 66 77 FE
00010: DC BA 98 76 54 32 10 01 23 45 67 89 AB CD EF 88
ICN:
00000: 00 77 66 55 44 33 22 11
Associated authenticated data A:
00000:
Plaintext P:
00000: 22 33 44 55 66 77 00 FF
1. Encryption step:
0^1 || ICN:
00000: 00 77 66 55 44 33 22 11
Y_1:
00000: 5B 2A 7E 60 4F 9F BB 95
E_K(Y_1):
00000: 48 A6 A5 17 0D 52 9D B1
C:
00000: 6A 95 E1 42 6B 25 9D 4E
2. Padding step:
A_1 || ... || A_h:
00000:
C_1 || ... || C_q:
00000: 6A 95 E1 42 6B 25 9D 4E
3. 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
Contributors
Evgeny Alekseev
CryptoPro
Email: alekseev@cryptopro.ru
Alexandra Babueva
CryptoPro
Email: babueva@cryptopro.ru
Lilia Akhmetzyanova
CryptoPro
Email: lah@cryptopro.ru
Grigory Marshalko
TC 26
Email: marshalko_gb@tc26.ru
Vladimir Rudskoy
TC 26
Email: rudskoy_vi@tc26.ru
Alexey Nesterenko
National Research University Higher School of Economics
Email: anesterenko@hse.ru
Lidia Nikiforova
CryptoPro
Email: nikiforova@cryptopro.ru
Authors' Addresses
Stanislav Smyshlyaev (editor)
CryptoPro
Phone: +7 (495) 995-48-20
Email: svs@cryptopro.ru
Vladislav Nozdrunov
TC 26
Email: nozdrunov_vi@tc26.ru
Vasily Shishkin
TC 26
Email: shishkin_va@tc26.ru
Ekaterina Griboedova
CryptoPro
Email: griboedovaekaterina@gmail.com
ISO Plain Language
On this page
§1What MGM Is For
Multilinear Galois Mode (MGM) is a block cipher mode that provides authenticated encryption with associated data (AEAD), built on the Encrypt-then-MAC principle: the data is encrypted first, and the authentication tag is then computed over the ciphertext. It is defined for use with 64-bit and 128-bit block ciphers, and the design principles can be applied to other block sizes.
MGM was standardised in Russia. It is used as an AEAD mode with the GOST block ciphers in a number of protocols, among them TLS 1.3 and IPsec. This document is a reference, so that the mechanisms in use can be reviewed and so that MGM can be used with any block cipher.
The RFC is explicit about its standing: it does not have IETF consensus and does not imply IETF support for MGM.
MGM does two jobs in one. It hides the content of a message and it produces a short tag that lets the receiver prove the message was not changed on the way.
The RFC writes the method down so that cryptographers can check it and so that other block ciphers can use it.
§3The Notation Used
The specification is written in a compact notation, and the RFC defines it precisely. V* is the set of all bit strings of any finite length, including the empty one, and substrings are counted from the right starting at zero. V_s is the set of all bit strings of length s. |X| is the length of a string in bits, and X || Y is the two strings joined end to end. a^s is the string of s copies of the bit a, and (xor) is exclusive-or of two strings of the same length.
Three conversions move between bit strings and numbers. MSB_i takes the i most significant bits of a string. Int_s reads a string as a binary number, and Vec_s is its inverse, writing a number as a bit string.
E_K is the block cipher permutation under the key K. The letter k is the length of that key in bits and n is the block size in bits. len maps a string whose length is at most 2^(n/2) - 1 to the n/2-bit representation of that length, and [+] is addition modulo 2^(n/2).
Two operations do the real work. (x) is multiplication of two polynomials over the Galois field GF(2^n): a bit string is read as a polynomial with those bits as coefficients, the two polynomials are multiplied, and the result is read back as a bit string. The field is fixed by a polynomial, which is w^64 + w^4 + w^3 + w + 1 when n is 64 and w^128 + w^7 + w^2 + w + 1 when n is 128.
The last two are counters. incr_l splits a block into a left half and a right half and adds one to the left half, keeping the right half. incr_r does the opposite and increments the right half. Both are additions in Z_(2^(n/2)).
The specification uses symbols rather than words, so it is worth stating what the main ones mean. The important one is the multiplication: two blocks are treated as polynomials over a finite field and multiplied, which is the step that lets the authentication tag detect any change to the data.
§4.1Encrypting and Producing the Tag
One more parameter completes the definition: the bit length S of the authentication tag, where 32 <= S <= n. The value must be fixed for a given protocol, and choosing it trades message expansion against the probability of a successful forgery.
The encryption procedure takes four inputs: the encryption key K; an initial counter nonce (ICN) in V_(n-1); the associated authenticated data A, whose length is less than 2^(n/2) and which is authenticated but not encrypted; and the plaintext P, whose length is likewise less than 2^(n/2). Both A and P are split into blocks of n bits, with a possibly shorter last block. If A is empty then h is 0 and t is n; if P is empty then q is 0 and u is n.
The output is the ICN, the associated data, the ciphertext C and the authentication tag T of length S.
The procedure itself has four steps. The encryption step builds a counter block from the nonce, encrypts it to get Y_1, and increments the right half for each further block. Each full block of plaintext is exclusive-ored with the encryption of its counter block, and the last, possibly short, block uses only the leading bits of that encryption. The padding step pads the last block of associated data and the last block of ciphertext with zeroes to full blocks. The tag generation step runs a second counter, this time starting from a block built from the nonce and encrypting it to get Z_1. It multiplies each associated data block by the encryption of its counter value, exclusive-ors the results together, then does the same with the ciphertext blocks. Finally it multiplies one more counter value by the concatenation of the lengths of the associated data and the ciphertext, adds that to the running sum, encrypts the sum and takes the leading S bits as the tag. The procedure returns (ICN, A, C, T).
Two rules govern the inputs. The ICN must be chosen uniquely for every message encrypted under the same key. And the lengths of the associated data and the plaintext must satisfy 0 < |A| + |P| < 2^(n/2), so the two together are never empty and never exceed the limit.
Encryption works like a stream cipher: a counter is encrypted under the key and the result is combined with the data. The tag is built from a second counter and a multiplication over the finite field, so any change to the data changes the tag.
The nonce must never repeat under the same key, and the data cannot be completely empty.
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).§4.2Decrypting and Checking the Tag
The decryption procedure takes the key, the ICN, the associated data, the ciphertext and the received tag. It outputs either FAIL, or the associated data and the recovered plaintext.
It has four steps, and the order matters. The padding step comes first, padding the last block of associated data and the last block of ciphertext to full blocks, exactly as the sender did. The tag verification step then recomputes the tag in the same way the sender did, using the ciphertext rather than the plaintext. If the recomputed tag differs from the received one, the procedure returns FAIL and the plaintext is never produced. Only after that check passes does the decryption step run, which repeats the counter-mode encryption of the sender and exclusive-ors it with the ciphertext to recover the plaintext.
This order is the Encrypt-then-MAC principle in practice. The tag is checked over the ciphertext, so nothing is decrypted until the data has been shown to be untampered with. The length rule is the same as on the sending side: 0 < |A| + |C| < 2^(n/2).
The receiver works backwards, but it checks the tag before it decrypts anything. If the tag does not match, the message is rejected and no plain text is produced.
That order is the whole point of the design: bad data never reaches the application.
§5Why the Mode Is Shaped This Way
MGM was first proposed in a 2017 conference paper. Its design is driven by four operational properties.
It is parallelizable. Its structure is that of a counter, so the blocks E_K(Y_i) and the authentication blocks H_i are produced in counter mode, and the multilinear function itself can be evaluated in parallel.
It is inverse free. The sender never has to invert the block cipher, again because of the counter structure.
It is online, which means a message can be processed before its length is known. This works because the encryption blocks and the authentication blocks are derived from two independent source blocks, Y_i and Z_i.
It offers the availability of precomputations, meaning the values H_i and E_K(Y_i) can be calculated before any data arrives, again because the counters make them independent of the data.
Four practical goals shape the design. The work can be spread over several processors, the sender never has to run the cipher backwards, a message can be processed while it is still arriving, and the values can be worked out before the data turns up.
- ParallelizableEncryption and authentication blocks are produced in counter mode, and the multilinear function can be evaluated in parallel.
- Inverse freeThe sender never has to invert the block cipher.
- OnlineA message can be processed before its length is known, using two independent counter blocks.
- PrecomputableThe values can be calculated before any data arrives.
§6Security Considerations
The RFC lists four properties that the security of MGM rests on.
The functions incr_r and incr_l are chosen so that the counter values Y_i and Z_i overlap as little as possible. The output of the multilinear function is encrypted, which resists attacks based on padding and on linear properties. The multilinear function itself is used for authentication, which resists the small subgroup attacks described in the literature. And the nonces (0^1 || ICN) and (1^1 || ICN) are encrypted, which minimises the number of plaintext and ciphertext pairs an adversary can obtain and so blocks attacks that need a lot of such material, including linear cryptanalysis, differential cryptanalysis and side-channel attacks.
Two rules are called crucial. The ICN values must be unique; using the same ICN for two different messages under the same key removes the security properties of the mode entirely. And empty plaintext and empty associated data must not be processed together, because the tag would then be independent of the nonce value, which opens the way to forgery attacks.
A security analysis exists for MGM when the block cipher is treated as a random permutation, and it gives bounds for the confidentiality advantage and the integrity advantage. For an adversary making at most q encryption queries over at most s blocks of plaintext and associated data, and allowed to produce a forgery over at most l blocks, the bounds are CA <= (3(s + 4q)^2) / 2^n and IA <= (3(s + 4q + l + 3)^2) / 2^n + 2/2^S, where n is the block size and S the tag size. The RFC says these bounds can be used as guidelines for calculating confidentiality and integrity limits.
Two mistakes break the scheme: reusing a nonce under the same key, and encrypting nothing at all with no extra context. Both are called out as crucial.
The RFC also gives the published bounds on how much an attacker can learn or forge, so that a protocol can pick a tag length and usage limits that match.