rfc9058xml2.original.xml   rfc9058.xml 
<?xml version = "1.0" encoding = "utf-8"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?> <?rfc toc="yes"?>
<?rfc tocdepth="4"?> <?rfc tocdepth="4"?>
<?rfc symrefs="yes"?> <?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?> <?rfc sortrefs="yes" ?>
<?rfc compact="no" ?> <?rfc compact="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="9058" category="info" do cName="draft-smyshlyaev-mgm-20" ipr="trust200902" obsoletes="" updates="" submis sionType="independent" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="tru e" sortRefs="true" version="3">
<rfc category="info" docName="draft-smyshlyaev-mgm-20" ipr="trust200902"> <front>
<title abbrev="Multilinear Galois Mode (MGM)">
<front>
<title abbrev="Multilinear Galois Mode (MGM)">
Multilinear Galois Mode (MGM) Multilinear Galois Mode (MGM)
</title> </title>
<seriesInfo name="RFC" value="9058"/>
<author fullname="Stanislav Smyshlyaev" initials="S" role="editor" surname="
Smyshlyaev">
<organization>CryptoPro</organization>
<address>
<phone>+7 (495) 995-48-20</phone>
<email>svs@cryptopro.ru</email>
</address>
</author>
<author fullname="Vladislav Nozdrunov" initials="V" surname="Nozdrunov">
<organization>TC 26</organization>
<address>
<email>nozdrunov_vi@tc26.ru</email>
</address>
</author>
<author fullname="Vasily Shishkin" initials="V" surname="Shishkin">
<organization>TC 26</organization>
<address>
<email>shishkin_va@tc26.ru</email>
</address>
</author>
<author fullname="Ekaterina Griboedova" initials="E" surname="Griboedova">
<organization>CryptoPro</organization>
<address>
<email>griboedovaekaterina@gmail.com</email>
</address>
</author>
<date month="June" year="2021"/>
<author fullname="Stanislav Smyshlyaev" initials="S.V." role="editor" su <area>General</area>
rname="Smyshlyaev">
<organization>CryptoPro</organization>
<address>
<phone>+7 (495) 995-48-20</phone>
<email>svs@cryptopro.ru</email>
</address>
</author>
<author fullname="Vladislav Nozdrunov" initials="V.N." surname="Nozdruno <workgroup>Network Working Group</workgroup>
v"> <keyword>authenticated encryption</keyword>
<organization>TC 26</organization> <keyword>mode of operation</keyword>
<address> <keyword>AEAD</keyword>
<email>nozdrunov_vi@tc26.ru</email> <abstract>
</address>
</author>
<author fullname="Vasily Shishkin" initials="V.S." surname="Shishkin"> <t>
<organization>TC 26</organization> Multilinear Galois Mode (MGM) is an Authenticated Encryption
<address> with Associated Data (AEAD) block cipher mode based on the
<email>shishkin_va@tc26.ru</email> Encrypt-then-MAC (EtM) principle. MGM is defined for use with
</address> 64-bit and 128-bit block ciphers.
</author> </t>
<author fullname="Ekaterina Griboedova" initials="E.S." surname="Griboed <t>
ova"> MGM has been standardized in Russia. It is used as an AEAD
<organization>CryptoPro</organization> mode for the GOST block cipher algorithms in many protocols,
<address> e.g., TLS 1.3 and IPsec. This document provides a reference for
<email>griboedovaekaterina@gmail.com</email> MGM to enable review of the mechanisms in use and to make MGM
</address> available for use with any block cipher.
</author> </t>
</abstract>
</front>
<middle>
<section anchor="Introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>
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.
</t>
<t>
MGM has been standardized in Russia <xref
target="AUTH-ENC-BLOCK-CIPHER" format="default"/>. 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.
</t>
<t>
This document does not have IETF consensus and does not imply
IETF support for MGM.
</t>
</section>
<section numbered="true" toc="default">
<name>Conventions Used in This Document</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST
NOT</bcp14>", "<bcp14>REQUIRED</bcp14>",
"<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT
RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"
format="default"/> <xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown
here.
</t>
</section>
<section anchor="Definition" numbered="true" toc="default">
<name>Basic Terms and Definitions</name>
<t> This document uses the following terms and definitions for the sets an
d operations
on the elements of these sets:
</t>
<dl newline="false" spacing="normal" indent="10">
<dt>V*</dt>
<dd>
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.
</dd>
<dt>V_s</dt>
<dd>
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.
</dd>
<dt>|X|</dt>
<dd>
The bit length of the bit string X (if X is an empty
string, then |X| = 0).
</dd>
<dt>X || Y</dt>
<dd>
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.
</dd>
<dt>a^s</dt>
<dd>
The string in V_s that consists of s 'a' bits.
</dd>
<dt>(xor)</dt>
<dd>
Exclusive-or of two bit strings of the same
length.
</dd>
<dt>Z_{2^s}</dt>
<dd>
Ring of residues modulo 2^s.
</dd>
<dt>MSB_i</dt> <dd><t> V_s -&gt; V_i</t>
<date year="2021" /> <t>The transformation that maps the string X =
<!--если не указываем число и месяц, они подставляются автоматически--> (x_{s-1}, ... , x_0) in V_s into the string MSB_i(X) =
<area>General</area> (x_{s-1}, ... , x_{s-i}) in V_i, i &lt;= s (most
<!--как в rfc7748--> significant bits).</t>
<workgroup>Network Working Group</workgroup> </dd>
<keyword>authenticated encryption, mode of operation, AEAD</keyword> <dt>Int_s</dt><dd> <t>V_s -&gt; Z_{2^s}</t>
<abstract> <t>The transformation that maps the string X =
<t> (x_{s-1}, ... , x_0) in V_s, s &gt; 0, into the integer
Multilinear Galois Mode (MGM) is an authenticated encryption wit Int_s(X) = 2^{s-1} * x_{s-1} + ... + 2 * x_1 + x_0 (the
h associated data (AEAD) block interpretation of the bit string as an integer).</t>
cipher mode based on EtM principle. MGM is defined for use with </dd>
64-bit and 128-bit block ciphers. <dt>Vec_s</dt><dd><t> Z_{2^s} -&gt; V_s</t>
</t>
<t>
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 provide
s a reference for MGM to enable review
of the mechanisms in use and to make MGM available for use with
any block cipher.
</t>
</abstract>
</front>
<middle> <t>The transformation inverse to the mapping Int_s
<section title="Introduction" anchor="Introduction"> (the interpretation of an integer as a bit string).</t>
<t> </dd>
Multilinear Galois Mode (MGM) is an authenticated encryption wit <dt>E_K</dt><dd><t>V_n -&gt; V_n</t>
h 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 s
izes.
</t>
<t>
MGM has been standardized in Russia <xref target="R1323565.1.026
-2019"/>. 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 provide
s a reference for MGM to enable review
of the mechanisms in use and to make MGM available for use with
any block cipher.
</t>
<t>
This document does not have IETF consensus and does not imply IE
TF support for MGM.
</t>
</section>
<section title="Conventions Used in This Document"> <t>The block cipher permutation under the key K in V_k.</
<t> t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NO </dd>
T", "SHOULD", "SHOULD NOT", <dt>k</dt>
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this <dd>
document are to be interpreted The bit length of the block cipher key.
as described in BCP 14 <xref target="RFC2119"/> <xref target="RF </dd>
C8174"/> when, and only when, <dt>n</dt>
they appear in all capitals, as shown here. <dd>
</t> The block size of the block cipher (in bits).
</section> </dd>
<dt>len</dt><dd><t> V_s -&gt; V_{n/2}</t>
<section title="Basic Terms and Definitions" anchor="Definition"> <t>The transformation that maps a string X in V_s, 0
<t> This document uses the following terms and definitions for the s &lt;= s &lt;= 2^{n/2} - 1, into the string len(X) =
ets and operations Vec_{n/2}(|X|) in V_{n/2}, where n is the block size
on the elements of these sets: of the used block cipher.</t>
<list style = "hanging" hangIndent = "8"> </dd>
<t hangText = "V*"> <dt>[+]</dt>
the set of all bit strings of a finite length (hereinaft <dd>
er The addition operation in Z_{2^{n/2}}, where n is the
referred to as strings), including the empty string; block size of the used block cipher.
substrings and string components are enumerated from rig </dd>
ht to left <dt>(x)</dt>
starting from zero; <dd>
</t> The transformation that maps two strings, X = (x_{n-1},
<t hangText = "V_s"> ... , x_0) in V_n and Y = (y_{n-1}, ... , y_0), in V_n
the set of all bit strings of length s, where s is a non into the string Z = X (x) Y = (z_{n-1}, ... , z_0) in
-negative integer. For s = 0, the V_0 consists V_n; the string Z corresponds to the polynomial Z(w) =
of a single empty string; z_{n-1} * w^{n-1} + ... + z_1 * w + z_0, which is the
</t> result of multiplying the polynomials X(w) = x_{n-1} *
<t hangText = "|X|"> w^{n-1} + ... + x_1 * w + x_0 and Y(w) = y_{n-1} *
the bit length of the bit string X (if X is an empty str w^{n-1} + ... + y_1 * w + y_0 in the field GF(2^n),
ing, then |X| = 0); where n is the block size of the used block cipher; if
</t> n = 64, then the field polynomial is equal to f(w) =
<t hangText = "X || Y"> w^64 + w^4 + w^3 + w + 1; if n = 128, then the field
concatenation of strings X and Y both belonging to V*, i polynomial is equal to f(w) = w^128 + w^7 + w^2 + w +
.e., a string from V_{|X|+|Y|}, where the left substring 1.
from V_{|X|} is equal to X, and the right substring from </dd>
V_{|Y|} is equal to Y;
</t>
<t hangText = "a^s">
the string in V_s that consists of s 'a' bits;
</t>
<t hangText = "(xor)">
exclusive-or of the two bit strings of the same length;
</t>
<t hangText = "Z_{2^s}">
ring of residues modulo 2^s;
</t>
<t hangText = "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 &lt;= s, (
most significant bits);
</t>
<t hangText = "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);
</t>
<t hangText = "Vec_s: Z_{2^s} -> V_s">
the transformation inverse to the mapping Int_s (the int
erpretation of an integer as a bit string);
</t>
<t hangText = "E_K: V_n -> V_n">
the block cipher permutation under the key K in V_k;
</t>
<t hangText = "k">
the bit length of the block cipher key;
</t>
<t hangText = "n">
the block size of the block cipher (in bits);
</t>
<t hangText = "len: V_s -> V_{n/2}">
the transformation that maps a string X in V_s, 0 &lt;=
s &lt;= 2^{n/2} - 1,
into the string len(X) = Vec_{n/2}(|X|) in V_{n/2}, wher
e n is the block size of the used block cipher;
</t>
<t hangText = "[+]">
the addition operation in Z_{2^{n/2}}, where n is the bl
ock size of the used block cipher;
</t>
<t hangText = "(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 th
e 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;
</t>
<t hangText = "incr_l: V_n -> V_n">
the transformation that maps a string L || R, where L, R
in V_{n/2}, into the string incr_l(L || R) = Vec_{n/2}(Int_{n/2}(L) [+] 1) || R
;
</t>
<t hangText = "incr_r: V_n -> V_n">
the transformation that maps a string L || R, where L, R
in V_{n/2}, into the string incr_r(L || R) = L || Vec_{n/2}(Int_{n/2}(R) [+] 1)
.
</t>
</list>
</t>
</section>
<section title="Specification"> <dt>incr_l</dt><dd><t> V_n -&gt; V_n</t>
<t> <t>
An additional parameter that defines the functioning of Multilin The transformation that maps an n-byte string A = L || R into the n-byte
ear Galois Mode (MGM) is the string incr_l(A) = Vec_{n/2}(Int_{n/2}(L) [+] 1) || R, where L and R are
bit length S of the authentication tag, 32 &lt;= S &lt;= n. The n/2-byte strings.
value of S MUST be fixed for a particular protocol. </t>
The choice of the value S involves a trade-off between message e
xpansion and the forgery probability. </dd>
</t> <dt>incr_r</dt>
<section title="MGM Encryption and Tag Generation Procedure" anchor= <dd><t>V_n -&gt; V_n</t>
"ENC">
<t> <t>
The MGM encryption and tag generation procedure takes the fo The transformation that maps an n-byte string A = L || R into the n-byte
llowing parameters as inputs: string incr_r(A) = L || Vec_{n/2}(Int_{n/2}(R) [+] 1), where L and R are
<list style="numbers"> n/2-byte strings.
<t> </t>
</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Specification</name>
<t>
An additional parameter that defines the functioning of
MGM is the bit length S of the
authentication tag, 32 &lt;= S &lt;= n. The value of S
<bcp14>MUST</bcp14> be fixed for a particular protocol. The
choice of the value S involves a trade-off between message
expansion and the forgery probability.
</t>
<section anchor="ENC" numbered="true" toc="default">
<name>MGM Encryption and Tag Generation Procedure</name>
<t>
The MGM encryption and tag generation procedure takes the
following parameters as inputs:
</t>
<ol spacing="normal" type="1"><li>
Encryption key K in V_k. Encryption key K in V_k.
</t> </li>
<t>
<li>
Initial counter nonce ICN in V_{n-1}. Initial counter nonce ICN in V_{n-1}.
</t> </li>
<t> <li>
Associated authenticated data A, 0 &lt;= |A| &lt; 2^ Associated authenticated data A, 0 &lt;= |A| &lt;
{n/2}. If |A| > 0, 2^{n/2}. If |A| &gt; 0, then A = A_1 || ... ||
then A = A_1 || ... || A*_h, A_j in V_n, for j = 1, A*_h, A_j in V_n, for j = 1, ... , h - 1, A*_h in
... , h - 1, A*_h in V_t, 1 &lt;= t &lt;= n. If |A| = 0, V_t, 1 &lt;= t &lt;= n. If |A| = 0, then by
then by definition A*_h is empty, and the h and t pa definition A*_h is empty, and the h and t
rameters are set as follows: h = 0, t = n. parameters are set as follows: h = 0, t = n. The
The associated data is authenticated but is not encr associated data is authenticated but is not
ypted. encrypted.
</t> </li>
<t> <li>
Plaintext P, 0 &lt;= |P| &lt; 2^{n/2}. If |P| > 0, t Plaintext P, 0 &lt;= |P| &lt; 2^{n/2}. If |P| &gt;
hen P = P_1 || ... || P*_q, P_i in 0, then P = P_1 || ... || P*_q, P_i in V_n, for i
V_n, for i = 1, ... , q - 1, P*_q in V_u, 1 &lt;= u = 1, ... , q - 1, P*_q in V_u, 1 &lt;= u &lt;=
&lt;= n. If |P| = 0, then by definition P*_q is empty, and the q and u parameter n. If |P| = 0, then by definition P*_q is empty,
s and the q and u parameters are set as follows: q =
are set as follows: q = 0, u = n. 0, u = n.
</t> </li>
</list> </ol>
</t> <t>
<t> The MGM encryption and tag generation procedure outputs
The MGM encryption and tag generation procedure outputs the the following parameters:
following parameters: </t>
<list style="numbers"> <ol spacing="normal" type="1"><li>Initial counter nonce ICN.</li>
<t>Initial counter nonce ICN.</t> <li>Associated authenticated data A.</li>
<t>Associated authenticated data A.</t> <li>Ciphertext C in V_{|P|}.</li>
<t>Ciphertext C in V_{|P|}.</t> <li>Authentication tag T in V_S.</li>
<t>Authentication tag T in V_S.</t> </ol>
</list> <t>
</t> The MGM encryption and tag generation procedure consists
<t> of the following steps:
The MGM encryption and tag generation procedure consists of </t>
the following steps:
</t> <sourcecode type="pseudocode"><![CDATA[
<t> +----------------------------------------------------------------+
<figure> | MGM-Encrypt(K, ICN, A, P) |
<artwork> |----------------------------------------------------------------|
<![CDATA[ | 1. Encryption step: |
+----------------------------------------------------------------+ | - if |P| = 0 then |
| MGM-Encrypt(K, ICN, A, P) | | - C*_q = P*_q |
|----------------------------------------------------------------| | - C = P |
| 1. Encryption step: | | - else |
| - if |P| = 0 then | | - Y_1 = E_K(0^1 || ICN), |
| - C*_q = P*_q | | - For i = 2, 3, ... , q do |
| - C = P | | Y_i = incr_r(Y_{i-1}), |
| - else | | - For i = 1, 2, ... , q - 1 do |
| - Y_1 = E_K(0^1 || ICN), | | C_i = P_i (xor) E_K(Y_i), |
| - For i = 2, 3, ... , q do | | - C*_q = P*_q (xor) MSB_u(E_K(Y_q)), |
| Y_i = incr_r(Y_{i-1}), | | - C = C_1 || ... || C*_q. |
| - For i = 1, 2, ... , q - 1 do | | |
| C_i = P_i (xor) E_K(Y_i), | | 2. Padding step: |
| - C*_q = P*_q (xor) MSB_u(E_K(Y_q)), | | - A_h = A*_h || 0^{n-t}, |
| - C = C_1 || ... || C*_q. | | - C_q = C*_q || 0^{n-u}. |
| | | |
| 2. Padding step: | | 3. Authentication tag T generation step: |
| - A_h = A*_h || 0^{n-t}, | | - Z_1 = E_K(1^1 || ICN), |
| - C_q = C*_q || 0^{n-u}. | | - sum = 0^n, |
| | | - For i = 1, 2, ..., h do |
| 3. Authentication tag T generation step: | | H_i = E_K(Z_i), |
| - Z_1 = E_K(1^1 || ICN), | | sum = sum (xor) ( H_i (x) A_i ), |
| - sum = 0^n, | | Z_{i+1} = incr_l(Z_i), |
| - For i = 1, 2, ..., h do | | - For j = 1, 2, ..., q do |
| H_i = E_K(Z_i), | | H_{h+j} = E_K(Z_{h+j}), |
| sum = sum (xor) ( H_i (x) A_i ), | | sum = sum (xor) ( H_{h+j} (x) C_j ), |
| Z_{i+1} = incr_l(Z_i), | | Z_{h+j+1} = incr_l(Z_{h+j}), |
| - For j = 1, 2, ..., q do | | - H_{h+q+1} = E_K(Z_{h+q+1}), |
| H_{h+j} = E_K(Z_{h+j}), | | - T = MSB_S(E_K(sum (xor) ( H_{h+q+1} (x) |
| sum = sum (xor) ( H_{h+j} (x) C_j ), | | ( len(A) || len(C) ) ))). |
| Z_{h+j+1} = incr_l(Z_{h+j}), | | |
| - H_{h+q+1} = E_K(Z_{h+q+1}), | | 4. Return (ICN, A, C, T). |
| - T = MSB_S(E_K(sum (xor) ( H_{h+q+1} (x) | +----------------------------------------------------------------+
| ( len(A) || len(C) ) ))). | ]]></sourcecode>
| |
| 4. Return (ICN, A, C, T). | <t>
+----------------------------------------------------------------+
]]>
</artwork>
</figure>
</t>
<t>
The ICN value for each message that is encrypted under The ICN value for each message that is encrypted under
the given key K must be chosen in a unique manner. the given key K must be chosen in a unique manner.
</t> </t>
<t> <t>
Users who do not wish to encrypt plaintext can provide a str Users who do not wish to encrypt plaintext can provide a
ing P of zero length. Users who do not wish to authenticate string P of zero length. Users who do not wish to
associated data can provide a string A of zero length. The l authenticate associated data can provide a string A of
ength of the associated data A and of the plaintext P MUST be such that 0 &lt; | zero length. The length of the associated data A and of
A| + |P| &lt; 2^{n/2}. the plaintext P <bcp14>MUST</bcp14> be such that 0 &lt;
</t> |A| + |P| &lt; 2^{n/2}.
</section> </t>
</section>
<section numbered="true" toc="default">
<name>MGM Decryption and Tag Verification Check Procedure</name>
<section title="MGM Decryption and Tag Verification Check Procedure" <t>
>
<t>
The MGM decryption and tag verification procedure takes the following parameters as inputs: The MGM decryption and tag verification procedure takes the following parameters as inputs:
<list style="numbers"> </t>
<t> <ol spacing="normal" type="1"><li>
Encryption key K in V_k. Encryption key K in V_k.
</t> </li>
<t> <li>
Initial counter nonce ICN in V_{n-1}. Initial counter nonce ICN in V_{n-1}.
</t> </li>
<t> <li>
Associated authenticated data A, 0 &lt;= |A| &lt; 2^ Associated authenticated data A, 0 &lt;= |A| &lt;
{n/2}. If |A| > 0, 2^{n/2}. If |A| &gt; 0, then A = A_1 || ... ||
then A = A_1 || ... || A*_h, A_j in V_n, for j = 1, A*_h, A_j in V_n, for j = 1, ... , h - 1, A*_h in
... , h - 1, A*_h in V_t, 1 &lt;= t &lt;= n. If |A| = 0, V_t, 1 &lt;= t &lt;= n. If |A| = 0, then by
then by definition A*_h is empty, and the h and t pa definition A*_h is empty, and the h and t
rameters are set as follows: h = 0, t = n. parameters are set as follows: h = 0, t = n. The
The associated data is authenticated but is not encr associated data is authenticated but is not
ypted. encrypted.
</t> </li>
<t> <li>
Ciphertext C, 0 &lt;= |C| &lt; 2^{n/2}. If |C| > 0, Ciphertext C, 0 &lt;= |C| &lt; 2^{n/2}. If |C| &gt;
then C = C_1 || ... || C*_q, C_i in V_n, for i = 1, ... , q - 1, C*_q in V_u, 1 0, then C = C_1 || ... || C*_q, C_i in V_n, for i = 1, ... , q - 1, C*_q in V_u,
&lt;= u &lt;= n. 1 &lt;= u &lt;= n.
If |C| = 0, then by definition C*_q is empty, and th e q and u parameters If |C| = 0, then by definition C*_q is empty, and th e q and u parameters
are set as follows: q = 0, u = n. are set as follows: q = 0, u = n.
</t> </li>
<t> <li>
Authentication tag T in V_S. Authentication tag T in V_S.
</t> </li>
</list> </ol>
</t> <t>
<t>
The MGM decryption and tag verification procedure outputs FA IL or the following parameters: The MGM decryption and tag verification procedure outputs FA IL or the following parameters:
<list style="numbers"> </t>
<t>Associated authenticated data A.</t> <ol spacing="normal" type="1"><li>Associated authenticated data A.</li>
<t>Plaintext P in V_{|C|}.</t> <li>Plaintext P in V_{|C|}.</li>
</list> </ol>
</t> <t>
<t>
The MGM decryption and tag verification procedure consists o f the following steps: The MGM decryption and tag verification procedure consists o f the following steps:
</t> </t>
<t>
<figure>
<artwork>
<![CDATA[
+----------------------------------------------------------------+
| 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). |
+----------------------------------------------------------------+
]]>
</artwork>
</figure>
</t>
<t>
The length of the associated data A and of the ciphertext C
MUST be such that 0 &lt; |A| + |C| &lt; 2^{n/2}.
</t>
</section>
</section>
<section anchor="RefRationale" title="Rationale"> <sourcecode type="pseudocode"><![CDATA[
<t> +----------------------------------------------------------------+
The MGM was originally proposed in <xref target="PDMODE"/>. | MGM-Decrypt(K, ICN, A, C, T) |
</t> |----------------------------------------------------------------|
<t> | 1. Padding step: |
From the operational point of view the MGM is designed to be par | - A_h = A*_h || 0^{n-t}, |
allelizable, inverse-free, online and | - C_q = C*_q || 0^{n-u}. |
to provide availability of precomputations. | |
</t> | 2. Authentication tag T verification step: |
<t> | - Z_1 = E_K(1^1 || ICN), |
Parallelizability of the MGM is achieved due to its counter-type | - sum = 0^n, |
structure and the usage of the multilinear | - For i = 1, 2, ..., h do |
function for authentication. Indeed, both encryption blocks E_K( | H_i = E_K(Z_i), |
Y_i) and authentication blocks H_i are produced | sum = sum (xor) ( H_i (x) A_i ), |
in the counter mode manner, and the multilinear function determi | Z_{i+1} = incr_l(Z_i), |
ned by H_i is parallelizable in itself. | - For j = 1, 2, ..., q do |
Additionally, the counter-type structure of the mode provides th | H_{h+j} = E_K(Z_{h+j}), |
e inverse-free property. | sum = sum (xor) ( H_{h+j} (x) C_j ), |
</t> | Z_{h+j+1} = incr_l(Z_{h+j}), |
<t> | - H_{h+q+1} = E_K(Z_{h+q+1}), |
The online property means the possibility to process message eve | - T' = MSB_S(E_K(sum (xor) ( H_{h+q+1} (x) |
n if it is not completely received (so its length | ( len(A) || len(C) ) ))), |
is unknown). To provide this property the MGM uses blocks E_K(Y_ | - If T' != T then return FAIL. |
i) and H_i which are produced basing on | |
two independent source blocks Y_i and Z_i. | 3. Decryption step: |
</t> | - if |C| = 0 then |
<t> | - P = C |
Availability of precomputations for the MGM means the possibilit | - else |
y to calculate H_i and E_K(Y_i) even before | - 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). |
+----------------------------------------------------------------+
]]></sourcecode>
<t>
The length of the associated data A and of the ciphertext C
<bcp14>MUST</bcp14> be such that 0 &lt; |A| + |C| &lt; 2^{n/2}.
</t>
</section>
</section>
<section anchor="RefRationale" numbered="true" toc="default">
<name>Rationale</name>
<t>
MGM was originally proposed in <xref target="PDMODE" format="def
ault"/>.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 f or calculating them. data is retrieved. It holds again due to the usage of counters f or calculating them.
</t> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
<section anchor="Security" title="Security Considerations"> The security properties of MGM are based on the following:
<t> </t>
The security properties of the MGM are based on the following:
<list style="symbols">
<t>
Different functions generating the counter values: <vspa
ce/>
The functions incr_r and incr_l are chosen to minimize
intersection (if it happens) of counter values Y_i and Z
_i.
</t>
<t>
Encryption of the multilinear function output:<vspace/>
It allows to resist attacks based on padding
and linear properties (see <xref target="Ferg05"/> for d
etails).
</t>
<t>
Multilinear function for authentication:<vspace/>
It allows to resist the small subgroup attacks <xref tar
get="Saar12"/>.
</t>
<t>
Encryption of the nonces (0^1 || ICN) and (1^1 || ICN):<
vspace/>
The use of this encryption minimizes the number of plain
text/ciphertext pairs
of blocks known to an adversary. It allows to resist att
acks that need substantial amount of such
material (e.g., linear and differential cryptanalysis, s
ide-channel attacks).
</t>
</list>
</t>
<t>
It is crucial to the security of MGM to use unique ICN values. U
sing the same ICN values for two different messages encrypted with the same key
eliminates the security properties of this mode.
</t>
<t>
It is crucial for the security of MGM not to process empty plain
text and empty associated data at the same time. Otherwise, a tag becomes indepe
ndent from a nonce value, leading to vulnerability to forgery attack.
</t>
<t>
Security analysis for MGM with E_K being a random permutation wa
s performed in <xref target="SecMGM"/>. More precisely, the bounds for confident
iality advantage (CA) and integrity advantage (IA)
(for details see <xref target="I-D.irtf-cfrg-aead-limits"/>) wer
e obtained. According to these results, for an adversary making at most q encryp
tion 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 b
locks:
<list style = "empty">
<t>
CA &lt;= ( 3( s + 4q )^2 )/ 2^n,
</t>
<t>
IA &lt;= ( 3( s + 4q + l + 3 )^2 )/ 2^n + 2/2^S,
</t>
</list>
where n is the block size and S is the authentication tag size.
</t>
<t>
These bounds can be used as guidelines on how to calculate confi
dentiality and integrity limits (for details also see <xref target="I-D.irtf-cfr
g-aead-limits"/>).
</t>
</section>
<section anchor="IANA" title="IANA Considerations"> <dl spacing="normal" newline="true">
<t>
This document does not require any IANA actions.
</t>
</section>
</middle> <dt> Different functions generating the counter values: </dt>
<dd>The functions incr_r and incr_l are chosen to minimize
intersection (if it happens) of counter values Y_i and Z_i.</dd>
<dt> Encryption of the multilinear function output:</dt>
<dd> It allows attacks based on padding
and linear properties to be resisted (see <xref target="FERG05" format="
default"/> for details).</dd>
<dt> Multilinear function for authentication:</dt>
<dd> It allows the small subgroup attacks to be resisted <xref target="S
AAR12" format="default"/>.</dd>
<dt> Encryption of the nonces (0^1 || ICN) and (1^1 || ICN):</dt>
<dd> The use of this encryption minimizes the number of
plaintext/ciphertext pairs of blocks known to an adversary.
<back> It prevents attacks that need a substantial amount of such material (e.g.,
<references title="Normative References"> linear and differential cryptanalysis and side-channel attacks).
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7801.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8891.xml' ?>
</references>
<references title="Informative References">
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/r eference.I-D.draft-irtf-cfrg-aead-limits-01.xml' ?> </dd>
<reference anchor="PDMODE"> </dl>
<front>
<title>
Parallel and double block cipher mode of operation (PD-m
ode) for authenticated encryption
</title>
<author>
<organization>
Nozdrunov, V.
</organization>
</author>
<date year="2017"/>
</front>
<seriesInfo name="CTCrypt 2017 proceedings," value="pp. 36-45"/>
</reference>
<reference anchor="GOST3412-2015"> <t>
<front> It is crucial to the security of MGM to use unique ICN
<title> values. Using the same ICN values for two different messages
Information technology. Cryptographic data security. Blo encrypted with the same key eliminates the security properties
ck ciphers of this mode.
</title> </t>
<author> <t>
<organization> It is crucial for the security of MGM not to process empty
Federal Agency on Technical Regulating and Metrology plaintext and empty associated data at the same
</organization> time. Otherwise, a tag becomes independent from a nonce value,
</author> leading to vulnerability to forgery attacks.
<date year="2015"/> </t>
</front> <t>
<seriesInfo name="GOST R" value="34.12-2015"/> Security analysis for MGM with E_K being a random permutation
</reference> was performed in <xref target="SEC-MGM"
format="default"/>. More precisely, the bounds for
confidentiality advantage (CA) and integrity advantage (IA)
(for details, see <xref target="I-D.irtf-cfrg-aead-limits"
format="default"/>) 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:
</t>
<reference anchor="Ferg05"> <t indent="6">CA &lt;= ( 3( s + 4q )^2 )/ 2^n,
<front> </t>
<title>
Authentication weaknesses in GCM
</title>
<author>
<organization>
Ferguson, N.
</organization>
</author>
<date year="2005"/>
</front>
</reference>
<reference anchor="R1323565.1.026-2019"> <t indent="6">IA &lt;= ( 3( s + 4q + l + 3 )^2 )/ 2^n + 2/2^S,
<front> </t>
<title>
Information technology. Cryptographic data security. Aut
henticated encryption block cipher operation modes
</title>
<author>
<organization>
Federal Agency on Technical Regulating and Metrology
</organization>
</author>
<date year="2019"/>
</front>
<seriesInfo name="R" value="1323565.1.026-2019"/>
</reference>
<reference anchor="Saar12"> <t>
<front> where n is the block size and S is the authentication tag size.
<title> </t>
Cycling Attacks on GCM, GHASH and Other Polynomial MACs <t>
and Hashes These bounds can be used as guidelines on how to calculate
</title> confidentiality and integrity limits (for details, also see
<author> <xref target="I-D.irtf-cfrg-aead-limits" format="default"/>).
<organization> </t>
Saarinen, O. </section>
</organization> <section anchor="IANA" numbered="true" toc="default">
</author> <name>IANA Considerations</name>
<date year="2012"/> <t>
</front> This document has no IANA actions.
<seriesInfo name="FSE 2012 proceedings," value="pp. 216-225"/> </t>
</reference> </section>
</middle>
<back>
<reference anchor="SecMGM"> <displayreference target="I-D.irtf-cfrg-aead-limits" to="AEAD-LIMITS"/>
<front> <references>
<title> <name>References</name>
Security of Multilinear Galois Mode (MGM). <references>
</title> <name>Normative References</name>
<author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization> FC.2119.xml"/>
Akhmetzyanova, L., Alekseev, E., Karpunin, G. and V. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Nozdrunov FC.7801.xml"/>
</organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</author> FC.8174.xml"/>
<date year="2019"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.8891.xml"/>
<seriesInfo name="IACR Cryptology ePrint Archive 2019," value="p </references>
. 123"/> <references>
</reference> <name>Informative References</name>
</references> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-irtf-cf rg-aead-limits.xml"/>
<section anchor="Appendix" title="Test Vectors"> <reference anchor="PDMODE">
<section title="Test Vectors for the Kuznyechik block cipher"> <front>
<t> <title>Parallel and double block cipher mode of operation (PD-mode)
Test vectors for the Kuznyechik block cipher (n = 128, k = for authenticated encryption
256) defined in <xref target="GOST3412-2015"/> (the English version can be found </title>
in <xref target="RFC7801"/>). <author fullname="Vladislav Nozdrunov" initials="V." surname="Nozdru
</t> nov">
<t> <organization/>
<figure> </author>
<artwork> <date month="June" year="2017"/>
<![CDATA[ </front>
<refcontent>CTCrypt 2017 proceedings, pp. 36-45 </refcontent>
</reference>
<reference anchor="GOST3412-2015">
<front>
<title>Information technology. Cryptographic data security. Block ci
phers
</title>
<author>
<organization>Federal Agency on Technical Regulating and Metrology
</organization>
</author>
<date year="2015"/>
</front>
<refcontent>GOST R 34.12-2015</refcontent>
</reference>
<reference anchor="FERG05">
<front>
<title>Authentication weaknesses in GCM
</title>
<author fullname="Niels Ferguson" initials="N" surname="Ferguson">
<organization/>
</author>
<date year="2005" month="May"/>
</front>
</reference>
<reference anchor="AUTH-ENC-BLOCK-CIPHER">
<front>
<title>
Information technology. Cryptographic data
security. Authenticated encryption block cipher
operation modes
</title>
<author>
<organization>
Federal Agency on Technical Regulating and Metrology
</organization>
</author>
<date year="2019"/>
</front>
<refcontent>R 1323565.1.026-2019</refcontent>
</reference>
<reference anchor="SAAR12">
<front>
<title>Cycling Attacks on GCM, GHASH and Other Polynomial MACs and H
ashes
</title>
<author fullname="Markku-Juhani Olavi Saarinen" initials="M-J" surna
me="Saarinen">
<organization>Fast Software Encryption</organization>
</author>
<date year="2012"/>
</front>
<refcontent>FSE 2012 proceedings, pp. 216-225</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-642-34047-5_13"/>
</reference>
<reference anchor="SEC-MGM">
<front>
<title>Security of Multilinear Galois Mode (MGM)
</title>
<author fullname="Liliya Akhmetzyanova" initials="L" surname="Akhmet
zyanova"/>
<author fullname="Evgeny Alekseev" initials="E" surname="Alekseev"/>
<author fullname="Grigory Karpunin" initials="G" surname="Karpunin"/>
<author fullname="Vladislav Nozdrunov" initials="V" surname="Nozdrunov"/>
<date year="2019"/>
</front>
<refcontent>IACR Cryptology ePrint Archive 2019, pp. 123</refcontent>
</reference>
</references>
</references>
<section anchor="Appendix" numbered="true" toc="default">
<name>Test Vectors</name>
<section numbered="true" toc="default">
<name>Test Vectors for the Kuznyechik Block Cipher</name>
<t>
Test vectors for the Kuznyechik block cipher (n = 128, k =
256) are defined in <xref target="GOST3412-2015" format="default"/> (the English
version can be found in <xref target="RFC7801" format="default"/>).
</t>
<section anchor="example1">
<name>Example 1</name>
<sourcecode><![CDATA[
Encryption key K: Encryption key K:
00000: 88 99 AA BB CC DD EE FF 00 11 22 33 44 55 66 77 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 00010: FE DC BA 98 76 54 32 10 01 23 45 67 89 AB CD EF
ICN: ICN:
00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88 00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88
Associated authenticated data A: Associated authenticated data A:
00000: 02 02 02 02 02 02 02 02 01 01 01 01 01 01 01 01 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 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 00020: EA 05 05 05 05 05 05 05 05
Plaintext P: Plaintext P:
00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88 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 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 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 00030: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11
00040: AA BB CC 00040: AA BB CC
]]></sourcecode>
1. Encryption step: <ol>
<li><t>Encryption step:</t>
<sourcecode><![CDATA[
0^1 || ICN: 0^1 || ICN:
00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88 00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88
Y_1: Y_1:
00000: 7F 67 9D 90 BE BC 24 30 5A 46 8D 42 B9 D4 ED CD 00000: 7F 67 9D 90 BE BC 24 30 5A 46 8D 42 B9 D4 ED CD
E_K(Y_1): E_K(Y_1):
00000: B8 57 48 C5 12 F3 19 90 AA 56 7E F1 53 35 DB 74 00000: B8 57 48 C5 12 F3 19 90 AA 56 7E F1 53 35 DB 74
Y_2: Y_2:
00000: 7F 67 9D 90 BE BC 24 30 5A 46 8D 42 B9 D4 ED CE 00000: 7F 67 9D 90 BE BC 24 30 5A 46 8D 42 B9 D4 ED CE
skipping to change at line 603 skipping to change at line 698
00000: 7F 67 9D 90 BE BC 24 30 5A 46 8D 42 B9 D4 ED D1 00000: 7F 67 9D 90 BE BC 24 30 5A 46 8D 42 B9 D4 ED D1
E_K(Y_5): E_K(Y_5):
00000: 86 CE 9E 2A 0A 12 25 E3 33 56 91 B2 0D 5A 33 48 00000: 86 CE 9E 2A 0A 12 25 E3 33 56 91 B2 0D 5A 33 48
C: C:
00000: A9 75 7B 81 47 95 6E 90 55 B8 A3 3D E8 9F 42 FC 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 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 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 00030: C6 0C 14 D4 D3 F8 83 D0 AB 94 42 06 95 C7 6D EB
00040: 2C 75 52 00040: 2C 75 52
]]></sourcecode>
</li>
2. Padding step: <li><t>Padding step:</t>
<sourcecode><![CDATA[
A_1 || ... || A_h: A_1 || ... || A_h:
00000: 02 02 02 02 02 02 02 02 01 01 01 01 01 01 01 01 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 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 00020: EA 05 05 05 05 05 05 05 05 00 00 00 00 00 00 00
C_1 || ... || C_q: C_1 || ... || C_q:
00000: A9 75 7B 81 47 95 6E 90 55 B8 A3 3D E8 9F 42 FC 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 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 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 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 00040: 2C 75 52 00 00 00 00 00 00 00 00 00 00 00 00 00
]]></sourcecode>
</li>
3. Authentication tag T generation step: <li><t>Authentication tag T generation step:</t>
<sourcecode><![CDATA[
1^1 || ICN: 1^1 || ICN:
00000: 91 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88 00000: 91 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88
Z_1: Z_1:
00000: 7F C2 45 A8 58 6E 66 02 A7 BB DB 27 86 BD C6 6F 00000: 7F C2 45 A8 58 6E 66 02 A7 BB DB 27 86 BD C6 6F
H_1: H_1:
00000: 8D B1 87 D6 53 83 0E A4 BC 44 64 76 95 2C 30 0B 00000: 8D B1 87 D6 53 83 0E A4 BC 44 64 76 95 2C 30 0B
current sum: current sum:
00000: 4C F4 27 F4 AD B7 5C F4 C0 DA 39 D5 AB 48 CF 38 00000: 4C F4 27 F4 AD B7 5C F4 C0 DA 39 D5 AB 48 CF 38
skipping to change at line 690 skipping to change at line 790
00000: 7F C2 45 A8 58 6E 66 0A A7 BB DB 27 86 BD C6 6F 00000: 7F C2 45 A8 58 6E 66 0A A7 BB DB 27 86 BD C6 6F
H_9: H_9:
00000: BC BC E6 C4 1A A3 55 A4 14 88 62 BF 64 BD 83 0D 00000: BC BC E6 C4 1A A3 55 A4 14 88 62 BF 64 BD 83 0D
len(A) || len(C): len(A) || len(C):
00000: 00 00 00 00 00 00 01 48 00 00 00 00 00 00 02 18 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) ) ): 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 00000: C0 C7 22 DB 5E 0B D6 DB 25 76 73 83 3D 56 71 28
Tag T: Tag T:
00000: CF 5D 65 6F 40 C3 4F 5C 46 E8 BB 0E 29 FC DB 4C 00000: CF 5D 65 6F 40 C3 4F 5C 46 E8 BB 0E 29 FC DB 4C
]]> ]]></sourcecode>
</artwork> </li>
</figure> </ol>
</t> </section>
<t>
<figure>
<artwork>
<![CDATA[
<section anchor="example2">
<name>Example 2</name>
<sourcecode><![CDATA[
Encryption key K: Encryption key K:
00000: 99 AA BB CC DD EE FF 00 11 22 33 44 55 66 77 FE 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 00010: DC BA 98 76 54 32 10 01 23 45 67 89 AB CD EF 88
ICN: ICN:
00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88 00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88
Associated authenticated data A: Associated authenticated data A:
00000: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00000: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
Plaintext P: Plaintext P:
00000: 00000:
]]></sourcecode>
1. Encryption step: <ol>
<li><t>Encryption step:</t>
<sourcecode><![CDATA[
C: C:
00000: 00000:
]]></sourcecode>
</li>
2. Padding step: <li><t>Padding step:</t>
<sourcecode><![CDATA[
A_1 || ... || A_h: A_1 || ... || A_h:
00000: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00000: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
C_1 || ... || C_q: C_1 || ... || C_q:
00000: 00000:
]]></sourcecode>
</li>
3. Authentication tag T generation step: <li><t>Authentication tag T generation step:</t>
<sourcecode><![CDATA[
1^1 || ICN: 1^1 || ICN:
00000: 91 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88 00000: 91 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88
Z_1: Z_1:
00000: 79 32 72 68 96 C4 3E 3F BF D6 50 89 EB F1 E5 B6 00000: 79 32 72 68 96 C4 3E 3F BF D6 50 89 EB F1 E5 B6
H_1: H_1:
00000: 99 3A 80 66 CC C0 A4 0F AC 4A 14 F7 A2 F6 6D 9B 00000: 99 3A 80 66 CC C0 A4 0F AC 4A 14 F7 A2 F6 6D 9B
current sum: current sum:
00000: 0A C1 1E 2C 1C D6 07 D8 2F E3 55 54 B4 01 02 81 00000: 0A C1 1E 2C 1C D6 07 D8 2F E3 55 54 B4 01 02 81
skipping to change at line 750 skipping to change at line 852
00000: 79 32 72 68 96 C4 3E 40 BF D6 50 89 EB F1 E5 B6 00000: 79 32 72 68 96 C4 3E 40 BF D6 50 89 EB F1 E5 B6
H_2: H_2:
00000: 0C 38 A7 1E E7 93 BF 76 89 81 BF CD 7C DA 78 C8 00000: 0C 38 A7 1E E7 93 BF 76 89 81 BF CD 7C DA 78 C8
len(A) || len(C): len(A) || len(C):
00000: 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 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) ) ): 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 00000: CA 1E F8 92 71 EA 60 C4 53 9E 40 EB 26 C2 80 5D
Tag T: Tag T:
00000: 79 01 E9 EA 20 85 CD 24 7E D2 49 69 5F 9F 8A 85 00000: 79 01 E9 EA 20 85 CD 24 7E D2 49 69 5F 9F 8A 85
]]> ]]></sourcecode>
</artwork> </li>
</figure> </ol>
</t> </section>
</section> </section>
<section title="Test Vectors for the Magma block cipher"> <section numbered="true" toc="default">
<t> <name>Test Vectors for the Magma Block Cipher</name>
Test vectors for the Magma block cipher (n = 64, k = 256) define <t>
d in <xref target="GOST3412-2015"/> (the English version can be found in <xref t Test vectors for the Magma block cipher (n = 64, k = 256) are
arget="RFC8891"/>). defined in <xref target="GOST3412-2015" format="default"/>
</t> (the English version can be found in <xref target="RFC8891"
<t> format="default"/>).
<figure> </t>
<artwork> <section anchor="examplemagma1">
<![CDATA[ <name>Example 1</name>
<sourcecode><![CDATA[
Encryption key K: Encryption key K:
00000: FF EE DD CC BB AA 99 88 77 66 55 44 33 22 11 00 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 00010: F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF
ICN: ICN:
00000: 12 DE F0 6B 3C 13 0A 59 00000: 12 DE F0 6B 3C 13 0A 59
Associated authenticated data A: Associated authenticated data A:
00000: 01 01 01 01 01 01 01 01 02 02 02 02 02 02 02 02 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 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 00020: 05 05 05 05 05 05 05 05 EA
Plaintext P: Plaintext P:
00000: FF EE DD CC BB AA 99 88 11 22 33 44 55 66 77 00 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 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 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 00030: AA BB CC EE FF 0A 00 11 22 33 44 55 66 77 88 99
00040: AA BB CC 00040: AA BB CC
]]></sourcecode>
1. Encryption step: <ol>
<li><t>Encryption step:</t>
<sourcecode><![CDATA[
0^1 || ICN: 0^1 || ICN:
00000: 12 DE F0 6B 3C 13 0A 59 00000: 12 DE F0 6B 3C 13 0A 59
Y_1: Y_1:
00000: 56 23 89 01 62 DE 31 BF 00000: 56 23 89 01 62 DE 31 BF
E_K(Y_1): E_K(Y_1):
00000: 38 7B DB A0 E4 34 39 B3 00000: 38 7B DB A0 E4 34 39 B3
Y_2: Y_2:
00000: 56 23 89 01 62 DE 31 C0 00000: 56 23 89 01 62 DE 31 C0
skipping to change at line 840 skipping to change at line 946
00000: 56 23 89 01 62 DE 31 C7 00000: 56 23 89 01 62 DE 31 C7
E_K(Y_9): E_K(Y_9):
00000: A9 00 50 4A 14 8D EE 26 00000: A9 00 50 4A 14 8D EE 26
C: C:
00000: C7 95 06 6C 5F 9E A0 3B 85 11 33 42 45 91 85 AE 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 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 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 00030: 70 F6 5C 64 6A BB 75 D5 47 AA 37 C3 BC B5 C3 4E
00040: 03 BB 9C 00040: 03 BB 9C
]]></sourcecode>
</li>
2. Padding step: <li><t>Padding step:</t>
<sourcecode><![CDATA[
A_1 || ... || A_h: A_1 || ... || A_h:
00000: 01 01 01 01 01 01 01 01 02 02 02 02 02 02 02 02 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 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 00020: 05 05 05 05 05 05 05 05 EA 00 00 00 00 00 00 00
C_1 || ... || C_q: C_1 || ... || C_q:
00000: C7 95 06 6C 5F 9E A0 3B 85 11 33 42 45 91 85 AE 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 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 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 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 00040: 03 BB 9C 00 00 00 00 00
]]></sourcecode>
</li>
3. Authentication tag T generation step: <li><t>Authentication tag T generation step:</t>
<sourcecode><![CDATA[
1^1 || ICN: 1^1 || ICN:
00000: 92 DE F0 6B 3C 13 0A 59 00000: 92 DE F0 6B 3C 13 0A 59
Z_1: Z_1:
00000: 2B 07 3F 04 94 F3 72 A0 00000: 2B 07 3F 04 94 F3 72 A0
H_1: H_1:
00000: 70 8A 78 19 1C DD 22 AA 00000: 70 8A 78 19 1C DD 22 AA
current sum: current sum:
00000: D6 BB 5B EA 81 93 12 62 00000: D6 BB 5B EA 81 93 12 62
skipping to change at line 976 skipping to change at line 1086
00000: 2B 07 3F 13 94 F3 72 A0 00000: 2B 07 3F 13 94 F3 72 A0
H_16: H_16:
00000: 83 11 B6 02 4A A9 66 C1 00000: 83 11 B6 02 4A A9 66 C1
len(A) || len(C): len(A) || len(C):
00000: 00 00 01 48 00 00 02 18 00000: 00 00 01 48 00 00 02 18
sum (xor) ( H_16 (x) ( len(A) || len(C) ) ): sum (xor) ( H_16 (x) ( len(A) || len(C) ) ):
00000: 73 CE F4 4B AE 6B DB 61 00000: 73 CE F4 4B AE 6B DB 61
Tag T: Tag T:
00000: A7 92 80 69 AA 10 FD 10 00000: A7 92 80 69 AA 10 FD 10
]]> ]]></sourcecode>
</artwork> </li>
</figure> </ol>
</t> </section>
<t>
<figure>
<artwork>
<![CDATA[
<section anchor="examplemagma2">
<name>Example 2</name>
<sourcecode><![CDATA[
Encryption key K: Encryption key K:
00000: 99 AA BB CC DD EE FF 00 11 22 33 44 55 66 77 FE 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 00010: DC BA 98 76 54 32 10 01 23 45 67 89 AB CD EF 88
ICN: ICN:
00000: 00 77 66 55 44 33 22 11 00000: 00 77 66 55 44 33 22 11
Associated authenticated data A: Associated authenticated data A:
00000: 00000:
Plaintext P: Plaintext P:
00000: 22 33 44 55 66 77 00 FF 00000: 22 33 44 55 66 77 00 FF
]]></sourcecode>
1. Encryption step: <ol>
<li><t>Encryption step:</t>
<sourcecode><![CDATA[
0^1 || ICN: 0^1 || ICN:
00000: 00 77 66 55 44 33 22 11 00000: 00 77 66 55 44 33 22 11
Y_1: Y_1:
00000: 5B 2A 7E 60 4F 9F BB 95 00000: 5B 2A 7E 60 4F 9F BB 95
E_K(Y_1): E_K(Y_1):
00000: 48 A6 A5 17 0D 52 9D B1 00000: 48 A6 A5 17 0D 52 9D B1
C: C:
00000: 6A 95 E1 42 6B 25 9D 4E 00000: 6A 95 E1 42 6B 25 9D 4E
]]></sourcecode>
2. Padding step: </li>
<li><t>Padding step:</t>
<sourcecode><![CDATA[
A_1 || ... || A_h: A_1 || ... || A_h:
00000: 00000:
C_1 || ... || C_q: C_1 || ... || C_q:
00000: 6A 95 E1 42 6B 25 9D 4E 00000: 6A 95 E1 42 6B 25 9D 4E
]]></sourcecode>
</li>
3. Authentication tag T generation step: <li><t>Authentication tag T generation step:</t>
<sourcecode><![CDATA[
1^1 || ICN: 1^1 || ICN:
00000: 80 77 66 55 44 33 22 11 00000: 80 77 66 55 44 33 22 11
Z_1: Z_1:
00000: 59 73 54 78 7E 52 E6 EB 00000: 59 73 54 78 7E 52 E6 EB
H_1: H_1:
00000: EC E3 F9 DA 11 8C 7D 95 00000: EC E3 F9 DA 11 8C 7D 95
current sum: current sum:
00000: 25 D0 E4 20 7B 6B F6 3D 00000: 25 D0 E4 20 7B 6B F6 3D
skipping to change at line 1044 skipping to change at line 1155
00000: 59 73 54 79 7E 52 E6 EB 00000: 59 73 54 79 7E 52 E6 EB
H_2: H_2:
00000: 31 0C 0D AC C9 D0 4D 93 00000: 31 0C 0D AC C9 D0 4D 93
len(A) || len(C): len(A) || len(C):
00000: 00 00 00 00 00 00 00 40 00000: 00 00 00 00 00 00 00 40
sum (xor) ( H_2 (x) ( len(A) || len(C) ) ): sum (xor) ( H_2 (x) ( len(A) || len(C) ) ):
00000: 66 D3 8F 12 0F 78 92 49 00000: 66 D3 8F 12 0F 78 92 49
Tag T: Tag T:
00000: 33 4E E2 70 45 0B EC 9E 00000: 33 4E E2 70 45 0B EC 9E
]]> ]]></sourcecode>
</artwork> </li>
</figure> </ol>
</t> </section>
</section> </section>
</section> </section>
<section anchor="contributors" numbered="false" toc="default">
<name>Contributors</name>
<section anchor="contributors" title="Contributors"> <contact fullname="Evgeny Alekseev">
<t> <organization>CryptoPro</organization>
<list style="symbols"> <address>
<t> <email>alekseev@cryptopro.ru</email>
Evgeny Alekseev <vspace/> </address>
CryptoPro <vspace/> </contact>
alekseev@cryptopro.ru
</t> <contact fullname="Alexandra Babueva">
<t>
Alexandra Babueva <vspace/> <organization>CryptoPro</organization>
CryptoPro <vspace/> <address>
babueva@cryptopro.ru <email>babueva@cryptopro.ru</email>
</t> </address>
<t> </contact>
Lilia Akhmetzyanova <vspace />
CryptoPro<vspace /> <contact fullname="Lilia Akhmetzyanova">
lah@cryptopro.ru
</t> <organization>CryptoPro</organization>
<t> <address>
Grigory Marshalko<vspace /> <email>lah@cryptopro.ru</email>
TC 26<vspace /> </address>
marshalko_gb@tc26.ru </contact>
</t>
<t> <contact fullname="Grigory Marshalko">
Vladimir Rudskoy<vspace />
TC 26<vspace /> <organization>TC 26</organization>
rudskoy_vi@tc26.ru <address>
</t> <email>marshalko_gb@tc26.ru</email>
<t> </address>
Alexey Nesterenko <vspace /> </contact>
National Research University Higher School of Economics<
vspace /> <contact fullname="Vladimir Rudskoy">
anesterenko@hse.ru
</t> <organization>TC 26</organization>
<t> <address>
Lidia Nikiforova<vspace/> <email>rudskoy_vi@tc26.ru</email>
CryptoPro<vspace /> </address>
nikiforova@cryptopro.ru </contact>
</t>
</list> <contact fullname="Alexey Nesterenko">
</t>
</section> <organization>National Research University Higher School of Economics</org
<!-- anization>
<section title="Acknowledgments"> <address>
<t> <email>anesterenko@hse.ru</email>
We thank TODO for their useful comments. </address>
</t> </contact>
</section>
--> <contact fullname="Lidia Nikiforova">
<organization>CryptoPro</organization>
<address>
<email>nikiforova@cryptopro.ru</email>
</address>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 71 change blocks. 
723 lines changed or deleted 760 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/