Network Working Group | S. Smyshlyaev, Ed. |
Internet-Draft | CryptoPro |
Intended status: Informational | V. Nozdrunov |
Expires: October 14, 2018 | V. Shishkin |
TC 26 | |
April 12, 2018 |
Multilinear Galois Mode (MGM)
draft-smyshlyaev-mgm-07
Multilinear 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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 14, 2018.
Copyright (c) 2018 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Multilinear 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 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 [RFC2119].
This document uses the following terms and definitions for the sets and operations on the elements of these sets:
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:
The MGM encryption and authentication procedure outputs the following parameters:
The MGM encryption and authentication procedure consists of the following steps:
+----------------------------------------------------------------+ | MGM-Encrypt(K, ICN, P, A) | |----------------------------------------------------------------| | 1. Encryption step: | | - 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), | | - sum1 = 0, sum2 = 0, | | - For i = 1, 2, ..., h do | | H_i = E_K(Z_i), | | sum1 = sum1 (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}), | | sum2 = sum2 (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(sum1 (xor) sum2 (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. 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 MGM decryption and authentication procedure outputs FAIL or the following parameters:
The MGM decryption and authentication 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' generation step: | | - Z_1 = E_K(1^1 || ICN), | | - sum1 = 0, sum2 = 0, | | - For i = 1, 2, ..., h do | | H_i = E_K(Z_i), | | sum1 = sum1 (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}), | | sum2 = sum2 (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(sum1 (xor) sum2 (xor) | | H_{h+q+1} (x) (len(A) || len(C)))), | | - If T' != T then return FAIL | | return FAIL. | | | | 3. Decryption step: | | - 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 (P, A). | |----------------------------------------------------------------+
The mode was originally proposed in [PDMODE].
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.
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
[PDMODE] | Vladislav Nozdrunov, "Parallel and double block cipher mode of operation (PD-mode) for authenticated encryption", CTCrypt 2017 proceedings, pp. 36-45, 2017. |
The text will be added in the future versions of the draft.