CryptoPro

+7 (495) 995-48-20 svs@cryptopro.ru

TC 26

nozdrunov_vi@tc26.ru

TC 26

shishkin_va@tc26.ru

General Network Working Group authenticated encryption, mode of operation, AEAD, TODO Multiline Galois Mode (MGM) is an authenticated encryption with associated data block cipher mode based on EtM principle. MGM is defined for use with 64-bit and 128-bit block ciphers.

Multiline Galois Mode (MGM) is an authenticated encryption with associated data block cipher mode based on EtM principle. MGM is defined for use with 64-bit and 128-bit block. The MGM design principles can easily be applied to other block sizes. The mode was originally proposed in .

The text will be added in the future versions of the draft.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This document uses the following terms and definitions for the sets and operations on the elements of these sets: 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; the set of all bit strings of length s, where s is a non-negative integer; the bit length of the bit string X (if X is an empty string, then |X| = 0); 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; the string in V_s that consists of s 'a' bits: a^s = (a, a, ... , a), 'a' in V_1; exclusive-or of the two bit strings of the same length, ring of residues modulo 2^s; 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); the transformation that maps a string X = (x_{s-1}, ... , x_0) in V_s 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); the transformation inverse to the mapping Int_s (the interpretation of an integer as a bit string); the block cipher permutation under the key K in V_k; the bit length of the block cipher key; the block size of the block cipher (in bits); 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; multiplication in GF(2^n), where n is the block size of the used block cipher; 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; 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);

An additional parameter that defines the functioning of MGM mode is the size S of the authentication field (in bits). The value of S MUST be fixed for a particular protocol, 32 <= S <= 128. The choice of the value S involves a trade-off between message expansion and the probability that an attacker can modify a message undetectably.

The MGM encryption and authentication procedure takes the following parameters as inputs: Encryption key K in V_k. Initial counter nonce ICN in V_{n-1}. Plaintext P, 0 <= |P| < 2^{n/2}. P = P_1 || ... || P*_q, P_i in V_n, i = 1, ... , q - 1, P*_q in V_u, 1 <= u <= n. Associated authenticated data A, 0 <= |A| < 2^{n/2}. A = A_1 || ... || A*_h, A_j in V_n, j = 1, ... , h - 1, A*_h in V_t, 1 <= t <= n. The associated data is authenticated but is not encrypted. The MGM encryption and authentication procedure outputs the following parameters: Initial counter nonce ICN. Associated authenticated data A. Ciphertext C in V_{|P|}. Authentication tag T in V_S. The MGM encryption and authentication procedure consists of the following steps:

The ICN value for each message that is encrypted under the given key K must be chosen in a unique manner. Using the same ICN values for two different messages encrypted with the same key eliminates the security properties of this mode. Users who do not wish to encrypt plaintext can provide a string P of length zero. Users who do not wish to authenticate associated data can provide a string A of length zero. The length of the associated data A and of the plaintext P MUST be such that 0 < |A| + |P| < 2^{n/2}.

The MGM decryption and authentication procedure takes the following parameters as inputs: The encryption key K in V_k. The initial counter nonce ICN in V_{n-1}. The associated authenticated data A, 0 <= |A| < 2^{n/2}. A = A_1 || ... || A*_h, A_j in V_n, j = 1, ... , h - 1, A*_h in V_t, 1 <= t <= n. The ciphertext C, 0 <= |C| < 2^{n/2}. C = C_1 || ... || C*_q, C_i in V_n, i = 1, ... , q - 1, C*_q in V_u, 1 <= u <= n. The authenticated tag T in V_S. The MGM decryption and authentication procedure outputs FAIL or the following parameters: Plaintext P in V_{|C|}. Associated authenticated data A. The MGM decryption and authentication procedure consists of the following steps:

During the construction of MGM mode our task was to create a fast, parallelizable, inverse free, online and secure block cipher mode. MGM is based on counters for reasons of performance. The first counter is used for message encryption, the second counter is used for authentication. For providing parallelizable authentication we use multilinear function. By encrypting second counter we produce elements H_i with the property that if one knows any information about value H_k he/she can't obtain any information about value H_l ( l is not equal to k ) besides that H_k is not equal to H_l. By adding the length of associated data A and encrypted message C and encrypting authentication tag we avoid attacks based on padding and linear properties of multilinear function. A collision of "usual" counters leads to obtaining information about values H_i, that could be dangerous to authentication. For minimizing probability of this event we change the principle of counters operating by using the functions incr_l and incr_l. To counteract finding collisions we encrypt initialization values of both counters.

Vladislav Nozdrunov

The text will be added in the future versions of the draft.

Evgeny Alekseev CryptoPro alekseev@cryptopro.ru Ekaterina Smyshlyaeva CryptoPro ess@cryptopro.ru Lilia Ahmetzyanova CryptoPro lah@cryptopro.ru Grigory Marshalko TC 26 marshalko_gb@tc26.ru Vladimir Rudskoy TC 26 rudskoy_vi@tc26.ru