Skip to main content

Multilinear Galois Mode (MGM)
RFC 9058

Document Type RFC - Informational (June 2021)
Was draft-smyshlyaev-mgm (individual)
Authors Stanislav V. Smyshlyaev , Vladislav Nozdrunov , Vasily Shishkin , Ekaterina Griboedova
Last updated 2021-06-30
RFC stream Independent Submission
Formats
IESG Responsible AD (None)
Send notices to (None)
RFC 9058


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