From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8645.txt | 3867 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3867 insertions(+) create mode 100644 doc/rfc/rfc8645.txt (limited to 'doc/rfc/rfc8645.txt') diff --git a/doc/rfc/rfc8645.txt b/doc/rfc/rfc8645.txt new file mode 100644 index 0000000..8c60bf0 --- /dev/null +++ b/doc/rfc/rfc8645.txt @@ -0,0 +1,3867 @@ + + + + + + +Internet Research Task Force (IRTF) S. Smyshlyaev, Ed. +Request for Comments: 8645 CryptoPro +Category: Informational August 2019 +ISSN: 2070-1721 + + + Re-keying Mechanisms for Symmetric Keys + +Abstract + + A certain maximum amount of data can be safely encrypted when + encryption is performed under a single key. This amount is called + the "key lifetime". This specification describes a variety of + methods for increasing the lifetime of symmetric keys. It provides + two types of re-keying mechanisms based on hash functions and block + ciphers that can be used with modes of operations such as CTR, GCM, + CBC, CFB, and OMAC. + + This document is a product of the Crypto Forum Research Group (CFRG) + in the IRTF. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related research + and development activities. These results might not be suitable for + deployment. This RFC represents the consensus of the Crypto Forum + Research Group of the Internet Research Task Force (IRTF). Documents + approved for publication by the IRSG 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/rfc8645. + + + + + + + + + + + + + + +Smyshlyaev Informational [Page 1] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +Copyright Notice + + Copyright (c) 2019 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Smyshlyaev Informational [Page 2] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 7 + 3. Basic Terms and Definitions . . . . . . . . . . . . . . . . . 7 + 4. Choosing Constructions and Security Parameters . . . . . . . 9 + 5. External Re-keying Mechanisms . . . . . . . . . . . . . . . . 11 + 5.1. Methods of Key Lifetime Control . . . . . . . . . . . . . 14 + 5.2. Parallel Constructions . . . . . . . . . . . . . . . . . 14 + 5.2.1. Parallel Construction Based on a KDF on a Block + Cipher . . . . . . . . . . . . . . . . . . . . . . . 15 + 5.2.2. Parallel Construction Based on a KDF on a Hash + Function . . . . . . . . . . . . . . . . . . . . . . 16 + 5.2.3. Tree-Based Construction . . . . . . . . . . . . . . . 16 + 5.3. Serial Constructions . . . . . . . . . . . . . . . . . . 17 + 5.3.1. Serial Construction Based on a KDF on a Block Cipher 19 + 5.3.2. Serial Construction Based on a KDF on a Hash Function 19 + 5.4. Using Additional Entropy during Re-keying . . . . . . . . 19 + 6. Internal Re-keying Mechanisms . . . . . . . . . . . . . . . . 20 + 6.1. Methods of Key Lifetime Control . . . . . . . . . . . . . 22 + 6.2. Constructions that Do Not Require a Master Key . . . . . 23 + 6.2.1. ACPKM Re-keying Mechanisms . . . . . . . . . . . . . 23 + 6.2.2. CTR-ACPKM Encryption Mode . . . . . . . . . . . . . . 25 + 6.2.3. GCM-ACPKM Authenticated Encryption Mode . . . . . . . 26 + 6.3. Constructions that Require a Master Key . . . . . . . . . 29 + 6.3.1. ACPKM-Master Key Derivation from the Master Key . . . 29 + 6.3.2. CTR-ACPKM-Master Encryption Mode . . . . . . . . . . 31 + 6.3.3. GCM-ACPKM-Master Authenticated Encryption Mode . . . 33 + 6.3.4. CBC-ACPKM-Master Encryption Mode . . . . . . . . . . 37 + 6.3.5. CFB-ACPKM-Master Encryption Mode . . . . . . . . . . 39 + 6.3.6. OMAC-ACPKM-Master Authentication Mode . . . . . . . . 40 + 7. Joint Usage of External and Internal Re-keying . . . . . . . 42 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 44 + 10.2. Informative References . . . . . . . . . . . . . . . . . 45 + Appendix A. Test Examples . . . . . . . . . . . . . . . . . . . 48 + A.1. Test Examples for External Re-keying . . . . . . . . . . 48 + A.1.1. External Re-keying with a Parallel Construction . . . 48 + A.1.2. External Re-keying with a Serial Construction . . . . 49 + A.2. Test Examples for Internal Re-keying . . . . . . . . . . 52 + A.2.1. Internal Re-keying Mechanisms that Do Not + Require a Master Key . . . . . . . . . . . . . . . . 52 + A.2.2. Internal Re-keying Mechanisms with a Master Key . . . 56 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 69 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 69 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 69 + + + +Smyshlyaev Informational [Page 3] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +1. Introduction + + A certain maximum amount of data can be safely encrypted when + encryption is performed under a single key. Hereinafter, this amount + will be referred to as the "key lifetime". The need for such a + limitation is dictated by the following methods of cryptanalysis: + + 1. Methods based on the combinatorial properties of the used block + cipher mode of operation + + These methods do not depend on the underlying block cipher. + Common mode restrictions derived from such methods are of + order 2^{n/2}, where n is a block size defined in Section 3. + [Sweet32] includes an example of an attack that is based on + such methods. + + 2. Methods based on side-channel analysis issues + + In most cases, these methods do not depend on the used + encryption modes and weakly depend on the used cipher + features. Limitations resulting from these considerations are + usually the most restrictive ones. [TEMPEST] is an example of + an attack that is based on such methods. + + 3. Methods based on the properties of the used block cipher + + The most common methods of this type are linear and + differential cryptanalysis [LDC]. In most cases, these + methods do not depend on the used modes of operation. In the + case of secure block ciphers, bounds resulting from such + methods are roughly the same as the natural bounds of 2^n and + are dominated by the other bounds above. Therefore, they can + be excluded from the considerations here. + + As a result, it is important to replace a key when the total size of + the processed plaintext under that key approaches the lifetime + limitation. A specific value of the key lifetime should be + determined in accordance with some safety margin for protocol + security and the methods outlined above. + + Suppose L is a key lifetime limitation in some protocol P. For + simplicity, assume that all messages have the same length m. Hence, + the number of messages q that can be processed with a single key K + should be such that m * q <= L. This can be depicted graphically as + a rectangle with sides m and q enclosed by area L (see Figure 1). + + + + + + +Smyshlyaev Informational [Page 4] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + +------------------------+ + | L | + | +--------m---------+ | + | |==================| | + | |==================| | + | q==================| | m * q <= L + | |==================| | + | |==================| | + | +------------------+ | + +------------------------+ + + Figure 1: Graphic Display of the Key Lifetime Limitation + + In practice, the amount of data that corresponds to limitation L may + not be enough. The simplest and obvious solution in this situation + is a regular renegotiation of an initial key after processing this + threshold amount of data L. However, this reduces the total + performance, since it usually entails termination of application data + transmission, additional service messages, the use of a random number + generator, and many other additional calculations, including + resource-intensive public key cryptography. + + For protocols based on block ciphers or stream ciphers, a more + efficient way to increase the key lifetime is to use various + re-keying mechanisms. This specification considers re-keying + mechanisms for block ciphers only; re-keying mechanisms typical for + stream ciphers (e.g., [Pietrzak2009], [FPS2012]) are beyond the scope + of this document. + + Re-keying mechanisms can be applied at the different protocol levels: + the block cipher level (this approach is known as fresh re-keying and + is described, for instance, in [FRESHREKEYING]; the block cipher mode + of operation level (see Section 6); and the protocol level above the + block cipher mode of operation (see Section 5). The usage of the + first approach is highly inefficient due to the key changing after + each message block is processed. Moreover, fresh re-keying + mechanisms can change the block cipher internal structure and, + consequently, can require an additional security analysis for each + particular block cipher. As a result, this approach depends on + particular primitive properties and cannot be applied to any + arbitrary block cipher without additional security analysis. + Therefore, fresh re-keying mechanisms go beyond the scope of this + document. + + Thus, this document contains the list of recommended re-keying + mechanisms that can be used in the symmetric encryption schemes based + on the block ciphers. These mechanisms are independent from the + + + + +Smyshlyaev Informational [Page 5] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + particular block cipher specification, and their security properties + rely only on the standard block cipher security assumption. + + This specification presents two basic approaches to extending the + lifetime of a key while avoiding renegotiation, which were introduced + in [AAOS2017]: + + 1. External re-keying + + External re-keying is performed by a protocol, and it is + independent of the underlying block cipher and the mode of + operation. External re-keying can use parallel and serial + constructions. In the parallel case, data processing keys K^1, + K^2, ... are generated directly from the initial key K + independently of each other. In the serial case, every data- + processing key depends on the state that is updated after the + generation of each new data-processing key. + + As a generalization of external parallel re-keying, an external + tree-based mechanism can be considered. It is specified in + Section 5.2.3 and can be viewed as the tree generalization in + [GGM]. Similar constructions are used in the one-way tree + mechanism ([OWT]) and [AESDUKPT] standard. + + 2. Internal re-keying + + Internal re-keying is built into the mode, and it depends heavily + on the properties of the mode of operation and the block size. + + The re-keying approaches extend the key lifetime for a single initial + key by allowing the leakages to be limited (via side channels) and by + improving the combinatorial properties of the used block cipher mode + of operation. + + In practical applications, re-keying can be useful for protocols that + need to operate in hostile environments or under restricted resource + conditions (e.g., those that require lightweight cryptography, where + ciphers have a small block size that imposes strict combinatorial + limitations). Moreover, mechanisms that use external or internal + re-keying may provide some protection against possible future attacks + (by limiting the number of plaintext-ciphertext pairs that an + adversary can collect) and some properties of forward or backward + security (meaning that past or future data-processing keys remain + secure even if the current key is compromised; see [AbBell] for more + details). External or internal re-keying can be used in network + protocols as well as in the systems for data-at-rest encryption. + + + + + +Smyshlyaev Informational [Page 6] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Depending on the concrete protocol characteristics, there might be + situations in which both external and internal re-keying mechanisms + (see Section 7) can be applied. For example, a similar approach was + used in Taha's tree construction (see [TAHA]). + + Note that there are key-updating (key regression) algorithms (e.g., + [FKK2005] and [KMNT2003]) that are called "re-keying" as well, but + they pursue goals other than increasing the key lifetime. Therefore, + key regression algorithms are excluded from the considerations here. + + This document represents the consensus of the Crypto Forum Research + Group (CFRG). + +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; + + V_s the set of all bit strings of length s, where s is a + non-negative integer; + + |X| the bit length of the bit string X; + + A | B the concatenation of strings A and B both belonging to V*, + i.e., a string in V_{|A|+|B|}, where the left substring in + V_|A| is equal to A and the right substring in V_|B| is equal + to B; + + (xor) the exclusive-or of two bit strings of the same length; + + Z_{2^n} the ring of residues modulo 2^n; + + Int_s: V_s -> Z_{2^s} + the transformation that maps the string a = (a_s, ... , a_1) + in V_s into the integer Int_s(a) = 2^{s-1} * a_s + ... + 2 * + a_2 + a_1 (the interpretation of the binary string as an + integer); + + + +Smyshlyaev Informational [Page 7] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Vec_s: Z_{2^s} -> V_s + the transformation inverse to the mapping Int_s (the + interpretation of an integer as a binary string); + + MSB_i: V_s -> V_i + the transformation that maps the string a = (a_s, ... , a_1) + in V_s into the string MSB_i(a) = (a_s, ... , a_{s-i+1}) in + V_i (most significant bits); + + LSB_i: V_s -> V_i + the transformation that maps the string a = (a_s, ... , a_1) + in V_s into the string LSB_i(a) = (a_i, ... , a_1) in V_i + (least significant bits); + + Inc_c: V_s -> V_s + the transformation that maps the string a = (a_s, ... , a_1) + in V_s into the string Inc_c(a) = MSB_{|a|-c}(a) | + Vec_c(Int_c(LSB_c(a)) + 1(mod 2^c)) in V_s (incrementing the + least significant c bits of the bit string, regarded as the + binary representation of an integer); + + a^s the string in V_s that consists of s 'a' bits; + + E_{K}: V_n -> V_n + the block cipher permutation under the key K in V_k; + + ceil(x) the smallest integer that is greater than or equal to x; + + floor(x) + the biggest integer that is less than or equal to x; + + k the bit length of the K; k is assumed to be divisible by 8; + + n the block size of the block cipher (in bits); n is assumed to + be divisible by 8; + + b the number of data blocks in the plaintext P (b = + ceil(|P|/n)); + + N the section size (the number of bits that are processed with + one section key before this key is transformed). + + A plaintext message P and the corresponding ciphertext C are divided + into b = ceil(|P|/n) blocks, denoted as P = P_1 | P_2 | ... | P_b and + C = C_1 | C_2 | ... | C_b, respectively. The first b-1 blocks P_i + and C_i are in V_n for i = 1, 2, ... , b-1. The b-th blocks P_b and + C_b may be incomplete blocks, i.e., in V_r, where r <= n if not + otherwise specified. + + + +Smyshlyaev Informational [Page 8] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +4. Choosing Constructions and Security Parameters + + External re-keying is an approach assuming that a key is transformed + after encrypting a limited number of entire messages. The external + re-keying method is chosen at the protocol level, regardless of the + underlying block cipher or the encryption mode. External re-keying + is recommended for protocols that process relatively short messages + or protocols that have a way to divide a long message into manageable + pieces. Through external re-keying, the number of messages that can + be securely processed with a single initial key K is substantially + increased without a loss of message length. + + External re-keying has the following advantages + + 1. It increases the lifetime of an initial key by increasing the + number of messages processed with this key. + + 2. It has minimal impact on performance when the number of messages + processed under one initial key is sufficiently large. + + 3. It provides forward and backward security of data-processing + keys. + + However, the use of external re-keying has the following + disadvantage: in cases with restrictive key lifetime limitations, the + message sizes can become obstructive due to the impossibility of + processing sufficiently large messages, so it may be necessary to + perform additional fragmentation at the protocol level. For example, + if the key lifetime L is 1 GB and the message length m = 3 GB, then + this message cannot be processed as a whole, and it should be divided + into three fragments that will be processed separately. + + Internal re-keying is an approach assuming that a key is transformed + during each separate message processing. Such procedures are + integrated into the base modes of operations, so every internal + re-keying mechanism is defined for the particular operation mode and + the block size of the used cipher. Internal re-keying is recommended + for protocols that process long messages: the size of each single + message can be substantially increased without loss in the number of + messages that can be securely processed with a single initial key. + + Internal re-keying has the following advantages: + + 1. It increases the lifetime of an initial key by increasing the + size of the messages processed with one initial key. + + 2. It has minimal impact on performance. + + + + +Smyshlyaev Informational [Page 9] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + 3. Internal re-keying mechanisms without a master key do not affect + short-message transformation at all. + + 4. It is transparent (works like any mode of operation): it does not + require changes of initialization vectors (IVs) and a restart of + MACing. + + However, the use of internal re-keying has the following + disadvantages: + + 1. a specific method must not be chosen independently of a mode of + operation. + + 2. internal re-keying mechanisms without a master key do not provide + backward security of data-processing keys. + + Any block cipher modes of operations with internal re-keying can be + jointly used with any external re-keying mechanisms. Such joint + usage increases both the number of messages processed with one + initial key and their maximum possible size. + + If the adversary has access to the data-processing interface, the use + of the same cryptographic primitives both for data-processing and + re-keying transformation decreases the code size but can lead to some + possible vulnerabilities (the possibility of mounting a chosen- + plaintext attack may lead to the compromise of the following keys). + This vulnerability can be eliminated by using different primitives + for data processing and re-keying, e.g., block cipher for data + processing and hash for re-keying (see Section 5.2.2 and + Section 5.3.2). However, in this case, the security of the whole + scheme cannot be reduced to standard notions like a pseudorandom + function (PRF) or pseudorandom permutation (PRP), so security + estimations become more difficult and unclear. + + Summing up the abovementioned issues briefly: + + 1. If a protocol assumes processing of long records (e.g., [CMS]), + internal re-keying should be used. If a protocol assumes + processing of a significant number of ordered records, which can + be considered as a single data stream (e.g., [TLS], [SSH]), + internal re-keying may also be used. + + 2. For protocols that allow out-of-order delivery and lost records + (e.g., [DTLS], [ESP]), external re-keying should be used as, in + this case, records cannot be considered as a single data stream. + If the records are also long enough, internal re-keying should + also be used during each separate message processing. + + + + +Smyshlyaev Informational [Page 10] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + For external re-keying: + + 1. If it is desirable to separate transformations used for data + processing and key updates, hash function-based re-keying should + be used. + + 2. If parallel data processing is required, then parallel external + re-keying should be used. + + 3. If restrictive key lifetime limitations are present, external + tree-based re-keying should be used. + + For internal re-keying: + + 1. If the property of forward and backward security is desirable for + data-processing keys and if additional key material can be easily + obtained for the data-processing stage, internal re-keying with a + master key should be used. + +5. External Re-keying Mechanisms + + This section presents an approach to increasing the initial key + lifetime by using a transformation of a data-processing key (frame + key) after processing a limited number of entire messages (frame). + The approach provides external parallel and serial re-keying + mechanisms (see [AbBell]). These mechanisms use initial key K only + for frame key generation and never use it directly for data + processing. Such mechanisms operate outside of the base modes of + operations and do not change them at all; therefore, they are called + "external re-keying" mechanisms in this document. + + External re-keying mechanisms are recommended for usage in protocols + that process quite small messages, since the maximum gain in + increasing the initial key lifetime is achieved by increasing the + number of messages. + + External re-keying increases the initial key lifetime through the + following approach. Suppose there is a protocol P with some mode of + operation (base encryption or authentication mode). Let L1 be a key + lifetime limitation induced by side-channel analysis methods (side- + channel limitation), let L2 be a key lifetime limitation induced by + methods based on the combinatorial properties of a used mode of + operation (combinatorial limitation), and let q1, q2 be the total + numbers of messages of length m that can be safely processed with an + initial key K according to these limitations. + + + + + + +Smyshlyaev Informational [Page 11] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Let L = min(L1, L2), q = min(q1, q2), and q * m <= L. As the L1 + limitation is usually much stronger than the L2 limitation (L1 < L2), + the final key lifetime restriction is equal to the most restrictive + limitation L1. Thus, as displayed in Figure 2, without re-keying, + only q1 (q1 * m <= L1) messages can be safely processed. + + <--------m-------> + +----------------+ ^ ^ + |================| | | + |================| | | + K-->|================| q1| + |================| | | + |==============L1| | | + +----------------+ v | + | | | + | | | + | | q2 + | | | + | | | + | | | + | | | + | | | + | | | + | | | + | | | + | L2| | + +----------------+ v + + Figure 2: Basic Principles of Message Processing + without External Re-keying + + Suppose that the safety margin for the protocol P is fixed and the + external re-keying approach is applied to the initial key K to + generate the sequence of frame keys. The frame keys are generated in + such a way that the leakage of a previous frame key does not have any + impact on the following one, so the side-channel limitation L1 is + switched off. Thus, the resulting key lifetime limitation of the + initial key K can be calculated on the basis of a new combinatorial + limitation L2'. It is proven (see [AbBell]) that the security of the + mode of operation that uses external re-keying leads to an increase + when compared to base mode without re-keying (thus, L2 < L2'). + Hence, as displayed in Figure 3, the resulting key lifetime + limitation if using external re-keying can be increased up to L2'. + + + + + + + + +Smyshlyaev Informational [Page 12] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + <--------m-------> + K +----------------+ + | |================| + v |================| + K^1--> |================| + | |================| + | |==============L1| + | +----------------+ + | |================| + v |================| + K^2--> |================| + | |================| + | |==============L1| + | +----------------+ + | |================| + v |================| + ... | . . . | + | | + | | + | L2| + +----------------+ + | | + ... ... + | L2'| + +----------------+ + + Figure 3: Basic Principles of Message Processing + with External Re-keying + + Note: The key transformation process is depicted in a simplified + form. A specific approach (parallel and serial) is described below. + + Consider an example. Let the message size in a protocol P be equal + to 1 KB. Suppose L1 = 128 MB and L2 = 1 TB. Thus, if an external + re-keying mechanism is not used, the initial key K must be + renegotiated after processing 128 MB / 1 KB = 131072 messages. + + If an external re-keying mechanism is used, the key lifetime + limitation L1 goes off. Hence, the resulting key lifetime limitation + L2' can be set to more than 1 TB. Thus, if an external re-keying + mechanism is used, more than 1 TB / 1 KB = 2^30 messages can be + processed before the initial key K is renegotiated. This is 8192 + times greater than the number of messages that can be processed when + an external re-keying mechanism is not used. + + + + + + + +Smyshlyaev Informational [Page 13] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +5.1. Methods of Key Lifetime Control + + Suppose L is an amount of data that can be safely processed with one + frame key. For i in {1, 2, ... , t}, the frame key K^i (see Figures + 4 and 6) should be transformed after processing q_i messages, where + q_i can be calculated in accordance with one of the following + approaches: + + Explicit approach: + + q_i is such that |M^{i,1}| + ... + |M^{i,q_i}| <= L, |M^{i,1}| + + ... + |M^{i,q_i+1}| > L. + This approach allows use of the frame key K^i in an almost optimal + way, but it can be applied only when messages cannot be lost or + reordered (e.g., TLS records). + + Implicit approach: + + q_i = L / m_max, i = 1, ... , t. + The amount of data processed with one frame key K^i is calculated + under the assumption that every message has the maximum length + m_max. Hence, this amount can be considerably less than the key + lifetime limitation L. On the other hand, this approach can be + applied when messages may be lost or reordered (e.g., DTLS + records). + + Dynamic key changes: + + We can organize the key change using the Protected Point to Point + ([P3]) solution by building a protected tunnel between the + endpoints in which the information about frame key updating can be + safely passed across. This can be useful, for example, when we + want the adversary to not detect the key change during the + protocol evaluation. + +5.2. Parallel Constructions + + External parallel re-keying mechanisms generate frame keys K^1, K^2, + ... directly from the initial key K independently of each other. + + The main idea behind external re-keying with a parallel construction + is presented in Figure 4: + + + + + + + + + +Smyshlyaev Informational [Page 14] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Maximum message size = m_max. + _____________________________________________________________ + + m_max + <----------------> + M^{1,1} |=== | + M^{1,2} |=============== | + +->K^1--> ... ... + | M^{1,q_1} |======== | + | + | + | M^{2,1} |================| + | M^{2,2} |===== | + K-----|->K^2--> ... ... + | M^{2,q_2} |========== | + | + ... + | M^{t,1} |============ | + | M^{t,2} |============= | + +->K^t--> ... ... + M^{t,q_t} |========== | + + _____________________________________________________________ + + Figure 4: External Parallel Re-keying Mechanisms + + The frame key K^i, i = 1, ... , t - 1 is updated after processing a + certain number of messages (see Section 5.1). + +5.2.1. Parallel Construction Based on a KDF on a Block Cipher + + The ExtParallelC re-keying mechanism is based on the key derivation + function on a block cipher and is used to generate t frame keys as + follows: + + K^1 | K^2 | ... | K^t = ExtParallelC(K, t * k) = MSB_{t * + k}(E_{K}(Vec_n(0)) | + E_{K}(Vec_n(1)) | ... | E_{K}(Vec_n(R - 1))), + + where R = ceil(t * k/n). + + + + + + + + + + + +Smyshlyaev Informational [Page 15] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +5.2.2. Parallel Construction Based on a KDF on a Hash Function + + The ExtParallelH re-keying mechanism is based on the key derivation + function HKDF-Expand, described in [RFC5869], and is used to generate + t frame keys as follows: + + K^1 | K^2 | ... | K^t = ExtParallelH(K, t * k) = HKDF-Expand(K, + label, t * k), + + where label is a string (may be a zero-length string) that is defined + by a specific protocol. + +5.2.3. Tree-Based Construction + + The application of an external tree-based mechanism leads to the + construction of the key tree with the initial key K (root key) at the + 0 level and the frame keys K^1, K^2, ... at the last level, as + described in Figure 5. + + K_root = K + ___________|___________ + | ... | + V V + K{1,1} K{1,W1} + ______|______ ______|______ + | ... | | ... | + V V V V + K{2,1} K{2,W2} K{2,(W1-1)*W2+1} K{2,W1*W2} + __|__ __|__ __|__ __|__ + | ... | | ... | | ... | | ... | + V V V V V V V V + K{3,1} ... ... ... ... ... ... K{3,W1*W2*W3} + + ... ... + __|__ ... __|__ + | ... | | ... | + V V V V + K{h,1} K{h,Wh} K{h,(W1*...*W{h-1}-1)*Wh+1} K{h,W1*...*Wh} + // \\ // \\ + K^1 K^{Wh} K^{(W1*...*W{h-1}-1)*Wh+1} K^{W1*...*Wh} + ____________________________________________________________________ + + Figure 5: External Tree-Based Mechanism + + The tree height h and the number of keys Wj, j in {1, ... , h}, which + can be partitioned from the "parent" key, are defined in accordance + with a specific protocol and key lifetime limitations for the used + derivation functions. + + + +Smyshlyaev Informational [Page 16] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Each j-level key K{j,w}, where j in {1, ... , h}, w in {1, ... , W1 * + ... * Wj}, is derived from the (j-1)-level "parent" key K{j-1, + ceil(w/Wi)} (and other appropriate input data) using the j-th level + derivation function. This function can be based on the block cipher + function or on the hash function and is defined in accordance with a + specific protocol. + + The i-th frame K^i, i in {1, 2, ... , W1*...*Wh}, can be calculated + as follows: + + K^i = ExtKeyTree(K, i) = KDF_h(KDF_{h-1}(... KDF_1(K, ceil(i / (W2 + * ... * Wh)) ... , ceil(i / Wh)), i), + + where KDF_j is the j-th level derivation function that takes two + arguments (the parent key value and the integer in a range from 1 to + W1 * ... * Wj) and outputs the j-th level key value. + + The frame key K^i is updated after processing a certain number of + messages (see Section 5.1). + + In order to create an efficient implementation, during frame key K^i + generation, the derivation functions KDF_j, j in {1, ... , h-1} + should be used only when ceil(i / (W{j+1} * ... * Wh)) != ceil((i - + 1) / (W{j+1} * ... * Wh)); otherwise, it is necessary to use a + previously generated value. This approach also makes it possible to + take countermeasures against side-channel attacks. + + Consider an example. Suppose h = 3, W1 = W2 = W3 = W, and KDF_1, + KDF_2, KDF_3 are key derivation functions based on the + KDF_GOSTR3411_2012_256 (hereafter simply KDF) function described in + [RFC7836]. The resulting ExtKeyTree function can be defined as + follows: + + ExtKeyTree(K, i) = KDF(KDF(KDF(K, "level1", ceil(i / W^2)), + "level2", ceil(i / W)), "level3", i). + + where i in {1, 2, ... , W^3}. + + A structure similar to the external tree-based mechanism can be found + in Section 6 of [NISTSP800-108]. + +5.3. Serial Constructions + + External serial re-keying mechanisms generate frame keys, each of + which depends on the secret state (K*_1, K*_2, ...) that is updated + after the generation of each new frame key; see Figure 6. Similar + approaches are used in the [SIGNAL] protocol and the [TLS] updating + + + + +Smyshlyaev Informational [Page 17] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + traffic key mechanism and were proposed for use in the [U2F] + protocol. + + External serial re-keying mechanisms have the obvious disadvantage of + being impossible to implement in parallel, but they may be the + preferred option if additional forward secrecy is desirable. If all + keys are securely deleted after usage, the compromise of a current + secret state at some point does not lead to a compromise of all + previous secret states and frame keys. In terms of [TLS], compromise + of application_traffic_secret_N does not compromise all previous + application_traffic_secret_i, i < N. + + The main idea behind external re-keying with a serial construction is + presented in Figure 6: + + Maximum message size = m_max. + _____________________________________________________________ + m_max + <----------------> + M^{1,1} |=== | + M^{1,2} |=============== | + K*_1 = K --->K^1--> ... ... + | M^{1,q_1} |======== | + | + | + | M^{2,1} |================| + v M^{2,2} |===== | + K*_2 ------->K^2--> ... ... + | M^{2,q_2} |========== | + | + ... + | M^{t,1} |============ | + v M^{t,2} |============= | + K*_t ------->K^t--> ... ... + M^{t,q_t} |========== | + + + _____________________________________________________________ + + Figure 6: External Serial Re-keying Mechanisms + + The frame key K^i, i = 1, ... , t - 1, is updated after processing a + certain number of messages (see Section 5.1). + + + + + + + + +Smyshlyaev Informational [Page 18] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +5.3.1. Serial Construction Based on a KDF on a Block Cipher + + The frame key K^i is calculated using the ExtSerialC transformation + as follows: + + K^i = ExtSerialC(K, i) = + MSB_k(E_{K*_i}(Vec_n(0)) |E_{K*_i}(Vec_n(1)) | ... | + E_{K*_i}(Vec_n(J - 1))), + + where J = ceil(k / n), i = 1, ... , t, K*_i is calculated as follows: + + K*_1 = K, + + K*_{j+1} = MSB_k(E_{K*_j}(Vec_n(J)) | E_{K*_j}(Vec_n(J + 1)) | + ... | + E_{K*_j}(Vec_n(2 * J - 1))), + + where j = 1, ... , t - 1. + +5.3.2. Serial Construction Based on a KDF on a Hash Function + + The frame key K^i is calculated using the ExtSerialH transformation + as follows: + + K^i = ExtSerialH(K, i) = HKDF-Expand(K*_i, label1, k), + + where i = 1, ... , t; HKDF-Expand is the HMAC-based key derivation + function, as described in [RFC5869]; and K*_i is calculated as + follows: + + K*_1 = K, + + K*_{j+1} = HKDF-Expand(K*_j, label2, k), where j = 1, ... , t - 1, + + where label1 and label2 are different strings from V* that are + defined by a specific protocol (see, for example, the algorithm for + updating traffic keys in TLS 1.3 [TLS]). + +5.4. Using Additional Entropy during Re-keying + + In many cases, using additional entropy during re-keying won't + increase security but may give a false sense of that. Therefore, one + can rely on additional entropy only after conducting a deep security + analysis. For example, good PRF constructions do not require + additional entropy for the quality of keys, so, in most cases, there + is no need to use additional entropy with external re-keying + mechanisms based on secure KDFs. However, in some situations, mixed- + in entropy can still increase security in the case of a time-limited + + + +Smyshlyaev Informational [Page 19] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + but complete breach of the system when an adversary can access the + frame-key generation interface but cannot reveal the master keys + (e.g., when the master keys are stored in a Hardware Security Module + (HSM)). + + For example, an external parallel construction based on a KDF on a + hash function with a mixed-in entropy can be described as follows: + + K^i = HKDF-Expand(K, label_i, k), + + where label_i is additional entropy that must be sent to the + recipient (e.g., sent jointly with an encrypted message). The + entropy label_i and the corresponding key K^i must be generated + directly before message processing. + +6. Internal Re-keying Mechanisms + + This section presents an approach to increasing the key lifetime by + using a transformation of a data-processing key (section key) during + each separate message processing. Each message is processed starting + with the same key (the first section key), and each section key is + updated after processing N bits of the message (section). + + This section provides internal re-keying mechanisms called ACPKM + (Advanced Cryptographic Prolongation of Key Material) and ACPKM- + Master that do not use a master key and use a master key, + respectively. Such mechanisms are integrated into the base modes of + operation and actually form new modes of operation. Therefore, they + are called "internal re-keying" mechanisms in this document. + + Internal re-keying mechanisms are recommended to be used in protocols + that process large single messages (e.g., CMS messages), since the + maximum gain in increasing the key lifetime is achieved by increasing + the length of a message, while it provides almost no increase in the + number of messages that can be processed with one initial key. + + Internal re-keying increases the key lifetime through the following + approach. Suppose protocol P uses some base mode of operation. Let + L1 and L2 be a side channel and combinatorial limitations, + respectively, and for some fixed number of messages q, let m1, m2 be + the lengths of messages that can be safely processed with a single + initial key K according to these limitations. + + Thus, the approach without re-keying (analogous to Section 5) yields + a final key lifetime restriction equal to L1, and only q messages of + the length m1 can be safely processed; see Figure 7. + + + + + +Smyshlyaev Informational [Page 20] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + K + | + v + ^ +----------------+------------------------------------+ + | |==============L1| L2| + | |================| | + q |================| | + | |================| | + | |================| | + v +----------------+------------------------------------+ + <-------m1-------> + <----------------------------m2-----------------------> + + Figure 7: Basic Principles of Message Processing + without Internal Re-keying + + Suppose that the safety margin for the protocol P is fixed and the + internal re-keying approach is applied to the base mode of operation. + Suppose further that every message is processed with a section key, + which is transformed after processing N bits of data, where N is a + parameter. If q * N does not exceed L1, then the side-channel + limitation L1 goes off, and the resulting key lifetime limitation of + the initial key K can be calculated on the basis of a new + combinatorial limitation L2'. The security of the mode of operation + that uses internal re-keying increases when compared to the base mode + of operation without re-keying (thus, L2 < L2'). Hence, as displayed + in Figure 8, the resulting key lifetime limitation if using internal + re-keying can be increased up to L2'. + + K-----> K^1-------------> K^2 -----------> . . . + | | + v v + ^ +---------------+---------------+------------------+--...--+ + | |=============L1|=============L1|====== L2| L2'| + | |===============|===============|====== | | + q |===============|===============|====== . . . | | + | |===============|===============|====== | | + | |===============|===============|====== | | + v +---------------+---------------+------------------+--...--+ + <-------N-------> + + Figure 8: Basic Principles of Message Processing + with Internal Re-keying + + Note: The key transformation process is depicted in a simplified + form. A specific approach (ACPKM and ACPKM-Master re-keying + mechanisms) is described below. + + + + +Smyshlyaev Informational [Page 21] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Since the performance of encryption can slightly decrease for rather + small values of N, the maximum possible value should be selected for + parameter N for a particular protocol in order to provide the + necessary key lifetime for the considered security models. + + Consider an example. Suppose L1 = 128 MB and L2 = 10 TB. Let the + message size in the protocol be large/unlimited (which may exhaust + the whole key lifetime L2). The most restrictive resulting key + lifetime limitation is equal to 128 MB. + + Thus, there is a need to put a limit on the maximum message size + m_max. For example, if m_max = 32 MB, it may happen that the + renegotiation of initial key K would be required after processing + only four messages. + + If an internal re-keying mechanism with section size N = 1 MB is + used, more than L1 / N = 128 MB / 1 MB = 128 messages can be + processed before the renegotiation of initial key K (instead of four + messages when an internal re-keying mechanism is not used). Note + that only one section of each message is processed with the section + key K^i, and, consequently, the key lifetime limitation L1 goes off. + Hence, the resulting key lifetime limitation L2' can be set to more + than 10 TB (in cases when a single large message is processed using + the initial key K). + +6.1. Methods of Key Lifetime Control + + Suppose L is an amount of data that can be safely processed with one + section key and N is a section size (fixed parameter). Suppose + M^{i}_1 is the first section of message M^{i}, i = 1, ... , q (see + Figures 9 and 10); the parameter q can then be calculated in + accordance with one of the following two approaches: + + o Explicit approach: + q_i is such that |M^{1}_1| + ... + |M^{q}_1| <= L, |M^{1}_1| + ... + + |M^{q+1}_1| > L + This approach allows use of the section key K^i in an almost + optimal way, but it can be applied only when messages cannot be + lost or reordered (e.g., TLS records). + + o Implicit approach: + q = L / N. + The amount of data processed with one section key K^i is + calculated under the assumption that the length of every message + is equal to or greater than section size N and thus can be + considerably less than the key lifetime limitation L. On the + other hand, this approach can be applied when messages may be lost + or reordered (e.g., DTLS records). + + + +Smyshlyaev Informational [Page 22] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +6.2. Constructions that Do Not Require a Master Key + + This section describes the block cipher modes that use the ACPKM + re-keying mechanism, which does not use a master key; an initial key + is used directly for the data encryption. + +6.2.1. ACPKM Re-keying Mechanisms + + This section defines a periodical key transformation without a master + key, which is called the ACPKM re-keying mechanism. This mechanism + can be applied to one of the base encryption modes (CTR and GCM block + cipher modes) to get an extension of this encryption mode that uses + periodical key transformation without a master key. This extension + can be considered as a new encryption mode. + + An additional parameter that defines the functioning of base + encryption modes with the ACPKM re-keying mechanism is the section + size N. The value of N is measured in bits and is fixed within a + specific protocol based on the requirements of the system capacity + and the key lifetime. The section size N MUST be divisible by the + block size n. + + The main idea behind internal re-keying without a master key is + presented in Figure 9: + + Section size = const = N, + maximum message size = m_max. + ____________________________________________________________________ + + ACPKM ACPKM ACPKM + K^1 = K ---> K^2 ---...-> K^{l_max-1} ----> K^{l_max} + | | | | + | | | | + v v v v + M^{1} |==========|==========| ... |==========|=======: | + M^{2} |==========|==========| ... |=== | : | + . . . . . . : + : : : : : : : + M^{q} |==========|==========| ... |==========|===== : | + section : + <----------> m_max + N bit + ___________________________________________________________________ + l_max = ceil(m_max/N). + + Figure 9: Internal Re-keying without a Master Key + + + + + +Smyshlyaev Informational [Page 23] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + During the processing of the input message M with the length m in + some encryption mode that uses the ACPKM key transformation of the + initial key K, the message is divided into l = ceil(m / N) sections + (denoted as M = M_1 | M_2 | ... | M_l, where M_i is in V_N for i in + {1, 2, ... , l - 1} and M_l is in V_r, r <= N). The first section of + each message is processed with the section key K^1 = K. To process + the (i + 1)-th section of each message, the section key K^{i+1} is + calculated using the ACPKM transformation as follows: + + K^{i+1} = ACPKM(K^i) = MSB_k(E_{K^i}(D_1) | ... | E_{K^i}(D_J)), + + where J = ceil(k/n) and D_1, D_2, ... , D_J are in V_n and are + calculated as follows: + + D_1 | D_2 | ... | D_J = MSB_{J * n}(D), + + where D is the following constant in V_{1024}: + + D = ( 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 + | 88 | 89 | 8a | 8b | 8c | 8d | 8e | 8f + | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 + | 98 | 99 | 9a | 9b | 9c | 9d | 9e | 9f + | a0 | a1 | a2 | a3 | a4 | a5 | a6 | a7 + | a8 | a9 | aa | ab | ac | ad | ae | af + | b0 | b1 | b2 | b3 | b4 | b5 | b6 | b7 + | b8 | b9 | ba | bb | bc | bd | be | bf + | c0 | c1 | c2 | c3 | c4 | c5 | c6 | c7 + | c8 | c9 | ca | cb | cc | cd | ce | cf + | d0 | d1 | d2 | d3 | d4 | d5 | d6 | d7 + | d8 | d9 | da | db | dc | dd | de | df + | e0 | e1 | e2 | e3 | e4 | e5 | e6 | e7 + | e8 | e9 | ea | eb | ec | ed | ee | ef + | f0 | f1 | f2 | f3 | f4 | f5 | f6 | f7 + | f8 | f9 | fa | fb | fc | fd | fe | ff) + + Note: The constant D is such that D_1, ... , D_J are pairwise + different for any allowed n and k values. + + Note: The highest bit of each octet of the constant D is equal to 1. + This condition is important as, in conjunction with a certain mode + message length limitation, it allows prevention of collisions of + block cipher permutation inputs in cases with key transformation and + message processing (for more details, see Section 4.4 of [AAOS2017]). + + + + + + + + +Smyshlyaev Informational [Page 24] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +6.2.2. CTR-ACPKM Encryption Mode + + This section defines a CTR-ACPKM encryption mode that uses the ACPKM + internal re-keying mechanism for the periodical key transformation. + + The CTR-ACPKM mode can be considered as the base encryption mode CTR + (see [MODES]) extended by the ACPKM re-keying mechanism. + + The CTR-ACPKM encryption mode can be used with the following + parameters: + + o 64 <= n <= 512. + + o 128 <= k <= 512. + + o The number c of bits in a specific part of the block to be + incremented is such that 32 <= c <= 3 / 4 n, where c is a multiple + of 8. + + o The maximum message size m_max = n * 2^{c-1}. + + The CTR-ACPKM mode encryption and decryption procedures are defined + as follows: + + +----------------------------------------------------------------+ + | CTR-ACPKM-Encrypt(N, K, ICN, P) | + |----------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - initial counter nonce ICN in V_{n-c}, | + | - plaintext P = P_1 | ... | P_b, |P| <= m_max. | + | Output: | + | - ciphertext C. | + |----------------------------------------------------------------| + | 1. CTR_1 = ICN | 0^c | + | 2. For j = 2, 3, ... , b do | + | CTR_{j} = Inc_c(CTR_{j-1}) | + | 3. K^1 = K | + | 4. For i = 2, 3, ... , ceil(|P| / N) | + | K^i = ACPKM(K^{i-1}) | + | 5. For j = 1, 2, ... , b do | + | i = ceil(j * n / N), | + | G_j = E_{K^i}(CTR_j) | + | 6. C = P (xor) MSB_{|P|}(G_1 | ... | G_b) | + | 7. Return C | + +----------------------------------------------------------------+ + + + + +Smyshlyaev Informational [Page 25] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + +----------------------------------------------------------------+ + | CTR-ACPKM-Decrypt(N, K, ICN, C) | + |----------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - initial counter nonce ICN in V_{n-c}, | + | - ciphertext C = C_1 | ... | C_b, |C| <= m_max. | + | Output: | + | - plaintext P. | + |----------------------------------------------------------------| + | 1. P = CTR-ACPKM-Encrypt(N, K, ICN, C) | + | 2. Return P | + +----------------------------------------------------------------+ + + The initial counter nonce (ICN) value for each message that is + encrypted under the given initial key K must be chosen in a unique + manner. + +6.2.3. GCM-ACPKM Authenticated Encryption Mode + + This section defines the GCM-ACPKM authenticated encryption mode that + uses the ACPKM internal re-keying mechanism for the periodical key + transformation. + + The GCM-ACPKM mode can be considered as the base authenticated + encryption mode GCM (see [GCM]) extended by the ACPKM re-keying + mechanism. + + The GCM-ACPKM authenticated encryption mode can be used with the + following parameters: + + o n in {128, 256}. + + o 128 <= k <= 512. + + o The number c of bits in a specific part of the block to be + incremented is such that 1 / 4 n <= c <= 1 / 2 n, c is a multiple + of 8. + + o Authentication tag length t. + + o The maximum message size m_max = min{n * (2^{c-1} - 2), 2^{n/2} - + 1}. + + + + + + + +Smyshlyaev Informational [Page 26] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + The GCM-ACPKM mode encryption and decryption procedures are defined + as follows: + + +-------------------------------------------------------------------+ + | GHASH(X, H) | + |-------------------------------------------------------------------| + | Input: | + | - bit string X = X_1 | ... | X_m, X_1, ... , X_m in V_n. | + | Output: | + | - block GHASH(X, H) in V_n. | + |-------------------------------------------------------------------| + | 1. Y_0 = 0^n | + | 2. For i = 1, ... , m do | + | Y_i = (Y_{i-1} (xor) X_i) * H | + | 3. Return Y_m | + +-------------------------------------------------------------------+ + + +-------------------------------------------------------------------+ + | GCTR(N, K, ICB, X) | + |-------------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - initial counter block ICB, | + | - X = X_1 | ... | X_b. | + | Output: | + | - Y in V_{|X|}. | + |-------------------------------------------------------------------| + | 1. If X in V_0, then return Y, where Y in V_0 | + | 2. GCTR_1 = ICB | + | 3. For i = 2, ... , b do | + | GCTR_i = Inc_c(GCTR_{i-1}) | + | 4. K^1 = K | + | 5. For j = 2, ... , ceil(|X| / N) | + | K^j = ACPKM(K^{j-1}) | + | 6. For i = 1, ... , b do | + | j = ceil(i * n / N), | + | G_i = E_{K_j}(GCTR_i) | + | 7. Y = X (xor) MSB_{|X|}(G_1 | ... | G_b) | + | 8. Return Y | + +-------------------------------------------------------------------+ + + + + + + + + + + +Smyshlyaev Informational [Page 27] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + +-------------------------------------------------------------------+ + | GCM-ACPKM-Encrypt(N, K, ICN, P, A) | + |-------------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - initial counter nonce ICN in V_{n-c}, | + | - plaintext P = P_1 | ... | P_b, |P| <= m_max, | + | - additional authenticated data A. | + | Output: | + | - ciphertext C, | + | - authentication tag T. | + |-------------------------------------------------------------------| + | 1. H = E_{K}(0^n) | + | 2. ICB_0 = ICN | 0^{c-1} | 1 | + | 3. C = GCTR(N, K, Inc_c(ICB_0), P) | + | 4. u = n * ceil(|C| / n) - |C| | + | v = n * ceil(|A| / n) - |A| | + | 5. S = GHASH(A | 0^v | C | 0^u | Vec_{n/2}(|A|) | | + | | Vec_{n/2}(|C|), H) | + | 6. T = MSB_t(E_{K}(ICB_0) (xor) S) | + | 7. Return C | T | + +-------------------------------------------------------------------+ + + +-------------------------------------------------------------------+ + | GCM-ACPKM-Decrypt(N, K, ICN, A, C, T) | + |-------------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - initial counter block ICN, | + | - additional authenticated data A, | + | - ciphertext C = C_1 | ... | C_b, |C| <= m_max, | + | - authentication tag T. | + | Output: | + | - plaintext P or FAIL. | + |-------------------------------------------------------------------| + | 1. H = E_{K}(0^n) | + | 2. ICB_0 = ICN | 0^{c-1} | 1 | + | 3. P = GCTR(N, K, Inc_c(ICB_0), C) | + | 4. u = n * ceil(|C| / n) - |C| | + | v = n * ceil(|A| / n) - |A| | + | 5. S = GHASH(A | 0^v | C | 0^u | Vec_{n/2}(|A|) | | + | | Vec_{n/2}(|C|), H) | + | 6. T' = MSB_t(E_{K}(ICB_0) (xor) S) | + | 7. If T = T', then return P; else return FAIL | + +-------------------------------------------------------------------+ + + + + +Smyshlyaev Informational [Page 28] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + The * operation on (pairs of) the 2^n possible blocks corresponds to + the multiplication operation for the binary Galois (finite) field of + 2^n elements defined by the polynomial f as follows (analogous to + [GCM]): + + n = 128: f = a^128 + a^7 + a^2 + a^1 + 1, + + n = 256: f = a^256 + a^10 + a^5 + a^2 + 1. + + The initial counter nonce ICN value for each message that is + encrypted under the given initial key K must be chosen in a unique + manner. + + The key for computing values E_{K}(ICB_0) and H is not updated and is + equal to the initial key K. + +6.3. Constructions that Require a Master Key + + This section describes the block cipher modes that use the ACPKM- + Master re-keying mechanism, which use the initial key K as a master + key, so K is never used directly for data processing but is used for + key derivation. + +6.3.1. ACPKM-Master Key Derivation from the Master Key + + This section defines periodical key transformation with a master key, + which is called the ACPKM-Master re-keying mechanism. This mechanism + can be applied to one of the base modes of operation (CTR, GCM, CBC, + CFB, OMAC modes) for getting an extension that uses periodical key + transformation with a master key. This extension can be considered + as a new mode of operation. + + Additional parameters that define the functioning of modes of + operation that use the ACPKM-Master re-keying mechanism are the + section size N, the change frequency T* of the master keys K*_1, + K*_2, ... (see Figure 10), and the size d of the section key + material. The values of N and T* are measured in bits and are fixed + within a specific protocol based on the requirements of the system + capacity and the key lifetime. The section size N MUST be divisible + by the block size n. The master key frequency T* MUST be divisible + by d and by n. + + + + + + + + + + +Smyshlyaev Informational [Page 29] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + The main idea behind internal re-keying with a master key is + presented in Figure 10: + + Master key frequency T*, + section size N, + maximum message size = m_max. + _____________________________________________________________________ + + ACPKM ACPKM + K*_1 = K----------> K*_2 ---------...-----> K*_l_max + ___|___ ___|___ ___|___ + | | | | | | + v ... v v ... v v ... v + K[1] K[t] K[t+1] K[2*t] K[(l_max-1)t+1] K[l_max*t] + | | | | | | + | | | | | | + v v v v v v + M^{1}||======|...|======||======|...|======||...||======|...|== : || + M^{2}||======|...|======||======|...|======||...||======|...|====: || + ... || | | || | | || || | | : || + M^{q}||======|...|======||==== |...| ||...|| |...| : || + section : + <------> : + N bit m_max + _____________________________________________________________________ + |K[i]| = d, + t = T* / d, + l_max = ceil(m_max / (N * t)). + + + Figure 10: Internal Re-keying with a Master Key + + During the processing of the input message M with the length m in + some mode of operation that uses ACPKM-Master key transformation with + the initial key K and the master key frequency T*, the message M is + divided into l = ceil(m / N) sections (denoted as M = M_1 | M_2 | + ... | M_l, where M_i is in V_N for i in {1, 2, ... , l - 1} and M_l + is in V_r, r <= N). The j-th section of each message is processed + with the key material K[j], j in {1, ... , l}, |K[j]| = d, which is + calculated with the ACPKM-Master algorithm as follows: + + K[1] | ... | K[l] = ACPKM-Master(T*, K, d, l) = CTR-ACPKM-Encrypt + (T*, K, 1^{n/2}, 0^{d*l}). + + Note: The parameters d and l MUST be such that d * l <= n * + 2^{n/2-1}. + + + + + +Smyshlyaev Informational [Page 30] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +6.3.2. CTR-ACPKM-Master Encryption Mode + + This section defines a CTR-ACPKM-Master encryption mode that uses the + ACPKM-Master internal re-keying mechanism for the periodical key + transformation. + + The CTR-ACPKM-Master encryption mode can be considered as the base + encryption mode CTR (see [MODES]) extended by the ACPKM-Master + re-keying mechanism. + + The CTR-ACPKM-Master encryption mode can be used with the following + parameters: + + o 64 <= n <= 512. + + o 128 <= k <= 512. + + o The number c of bits in a specific part of the block to be + incremented is such that 32 <= c <= 3 / 4 n, c is a multiple of 8. + + o The maximum message size m_max = min{N * (n * 2^{n/2-1} / k), n * + 2^c}. + + The key material K[j] that is used for one-section processing is + equal to K^j, where |K^j| = k bits. + + + + + + + + + + + + + + + + + + + + + + + + + + +Smyshlyaev Informational [Page 31] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + The CTR-ACPKM-Master mode encryption and decryption procedures are + defined as follows: + + +----------------------------------------------------------------+ + | CTR-ACPKM-Master-Encrypt(N, K, T*, ICN, P) | + |----------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - master key frequency T*, | + | - initial counter nonce ICN in V_{n-c}, | + | - plaintext P = P_1 | ... | P_b, |P| <= m_max. | + | Output: | + | - ciphertext C. | + |----------------------------------------------------------------| + | 1. CTR_1 = ICN | 0^c | + | 2. For j = 2, 3, ... , b do | + | CTR_{j} = Inc_c(CTR_{j-1}) | + | 3. l = ceil(|P| / N) | + | 4. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) | + | 5. For j = 1, 2, ... , b do | + | i = ceil(j * n / N), | + | G_j = E_{K^i}(CTR_j) | + | 6. C = P (xor) MSB_{|P|}(G_1 | ... |G_b) | + | 7. Return C | + |----------------------------------------------------------------+ + + +----------------------------------------------------------------+ + | CTR-ACPKM-Master-Decrypt(N, K, T*, ICN, C) | + |----------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - master key frequency T*, | + | - initial counter nonce ICN in V_{n-c}, | + | - ciphertext C = C_1 | ... | C_b, |C| <= m_max. | + | Output: | + | - plaintext P. | + |----------------------------------------------------------------| + | 1. P = CTR-ACPKM-Master-Encrypt(N, K, T*, ICN, C) | + | 1. Return P | + +----------------------------------------------------------------+ + + The initial counter nonce ICN value for each message that is + encrypted under the given initial key must be chosen in a unique + manner. + + + + + +Smyshlyaev Informational [Page 32] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +6.3.3. GCM-ACPKM-Master Authenticated Encryption Mode + + This section defines a GCM-ACPKM-Master authenticated encryption mode + that uses the ACPKM-Master internal re-keying mechanism for the + periodical key transformation. + + The GCM-ACPKM-Master authenticated encryption mode can be considered + as the base authenticated encryption mode GCM (see [GCM]) extended by + the ACPKM-Master re-keying mechanism. + + The GCM-ACPKM-Master authenticated encryption mode can be used with + the following parameters: + + o n in {128, 256}. + + o 128 <= k <= 512. + + o The number c of bits in a specific part of the block to be + incremented is such that 1 / 4 n <= c <= 1 / 2 n, c is a multiple + of 8. + + o authentication tag length t. + + o the maximum message size m_max = min{N * ( n * 2^{n/2-1} / k), n * + (2^c - 2), 2^{n/2} - 1}. + + The key material K[j] that is used for the j-th section processing is + equal to K^j, |K^j| = k bits. + + The GCM-ACPKM-Master mode encryption and decryption procedures are + defined as follows: + + +-------------------------------------------------------------------+ + | GHASH(X, H) | + |-------------------------------------------------------------------| + | Input: | + | - bit string X = X_1 | ... | X_m, X_i in V_n for i in {1, ... ,m}| + | Output: | + | - block GHASH(X, H) in V_n | + |-------------------------------------------------------------------| + | 1. Y_0 = 0^n | + | 2. For i = 1, ... , m do | + | Y_i = (Y_{i-1} (xor) X_i) * H | + | 3. Return Y_m | + +-------------------------------------------------------------------+ + + + + + + +Smyshlyaev Informational [Page 33] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + +-------------------------------------------------------------------+ + | GCTR(N, K, T*, ICB, X) | + |-------------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - master key frequency T*, | + | - initial counter block ICB, | + | - X = X_1 | ... | X_b. | + | Output: | + | - Y in V_{|X|}. | + |-------------------------------------------------------------------| + | 1. If X in V_0, then return Y, where Y in V_0 | + | 2. GCTR_1 = ICB | + | 3. For i = 2, ... , b do | + | GCTR_i = Inc_c(GCTR_{i-1}) | + | 4. l = ceil(|X| / N) | + | 5. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) | + | 6. For j = 1, ... , b do | + | i = ceil(j * n / N), | + | G_j = E_{K^i}(GCTR_j) | + | 7. Y = X (xor) MSB_{|X|}(G_1 | ... | G_b) | + | 8. Return Y | + +-------------------------------------------------------------------+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +Smyshlyaev Informational [Page 34] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + +-------------------------------------------------------------------+ + | GCM-ACPKM-Master-Encrypt(N, K, T*, ICN, P, A) | + |-------------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - master key frequency T*, | + | - initial counter nonce ICN in V_{n-c}, | + | - plaintext P = P_1 | ... | P_b, |P| <= m_max. | + | - additional authenticated data A. | + | Output: | + | - ciphertext C, | + | - authentication tag T. | + |-------------------------------------------------------------------| + | 1. K^1 = ACPKM-Master(T*, K, k, 1) | + | 2. H = E_{K^1}(0^n) | + | 3. ICB_0 = ICN | 0^{c-1} | 1 | + | 4. C = GCTR(N, K, T*, Inc_c(ICB_0), P) | + | 5. u = n * ceil(|C| / n) - |C| | + | v = n * ceil(|A| / n) - |A| | + | 6. S = GHASH(A | 0^v | C | 0^u | Vec_{n/2}(|A|) | | + | | Vec_{n/2}(|C|), H) | + | 7. T = MSB_t(E_{K^1}(ICB_0) (xor) S) | + | 8. Return C | T | + +-------------------------------------------------------------------+ + + + + + + + + + + + + + + + + + + + + + + + + + + +Smyshlyaev Informational [Page 35] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + +-------------------------------------------------------------------+ + | GCM-ACPKM-Master-Decrypt(N, K, T*, ICN, A, C, T) | + |-------------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - master key frequency T*, | + | - initial counter nonce ICN in V_{n-c}, | + | - additional authenticated data A. | + | - ciphertext C = C_1 | ... | C_b, |C| <= m_max, | + | - authentication tag T. | + | Output: | + | - plaintext P or FAIL. | + |-------------------------------------------------------------------| + | 1. K^1 = ACPKM-Master(T*, K, k, 1) | + | 2. H = E_{K^1}(0^n) | + | 3. ICB_0 = ICN | 0^{c-1} | 1 | + | 4. P = GCTR(N, K, T*, Inc_c(ICB_0), C) | + | 5. u = n * ceil(|C| / n) - |C| | + | v = n * ceil(|A| / n) - |A| | + | 6. S = GHASH(A | 0^v | C | 0^u | Vec_{n/2}(|A|) | | + | | Vec_{n/2}(|C|), H) | + | 7. T' = MSB_t(E_{K^1}(ICB_0) (xor) S) | + | 8. If T = T', then return P; else return FAIL. | + +-------------------------------------------------------------------+ + + The * operation on (pairs of) the 2^n possible blocks corresponds to + the multiplication operation for the binary Galois (finite) field of + 2^n elements defined by the polynomial f as follows (by analogy with + [GCM]): + + n = 128: f = a^128 + a^7 + a^2 + a^1 + 1, + + n = 256: f = a^256 + a^10 + a^5 + a^2 + 1. + + The initial counter nonce ICN value for each message that is + encrypted under the given initial key must be chosen in a unique + manner. + + + + + + + + + + + + + +Smyshlyaev Informational [Page 36] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +6.3.4. CBC-ACPKM-Master Encryption Mode + + This section defines a CBC-ACPKM-Master encryption mode that uses the + ACPKM-Master internal re-keying mechanism for the periodical key + transformation. + + The CBC-ACPKM-Master encryption mode can be considered as the base + encryption mode CBC (see [MODES]) extended by the ACPKM-Master + re-keying mechanism. + + The CBC-ACPKM-Master encryption mode can be used with the following + parameters: + + o 64 <= n <= 512. + + o 128 <= k <= 512. + + o The maximum message size m_max = N * (n * 2^{n/2-1} / k). + + In the specification of the CBC-ACPKM-Master mode, the plaintext and + ciphertext must be a sequence of one or more complete data blocks. + If the data string to be encrypted does not initially satisfy this + property, then it MUST be padded to form complete data blocks. The + padding methods are out of the scope of this document. An example of + a padding method can be found in Appendix A of [MODES]. + + The key material K[j] that is used for the j-th section processing is + equal to K^j, |K^j| = k bits. + + We use D_{K} to denote the decryption function that is a permutation + inverse to E_{K}. + + + + + + + + + + + + + + + + + + + + +Smyshlyaev Informational [Page 37] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + The CBC-ACPKM-Master mode encryption and decryption procedures are + defined as follows: + + +----------------------------------------------------------------+ + | CBC-ACPKM-Master-Encrypt(N, K, T*, IV, P) | + |----------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - master key frequency T*, | + | - initialization vector IV in V_n, | + | - plaintext P = P_1 | ... | P_b, |P_b| = n, |P| <= m_max. | + | Output: | + | - ciphertext C. | + |----------------------------------------------------------------| + | 1. l = ceil(|P| / N) | + | 2. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) | + | 3. C_0 = IV | + | 4. For j = 1, 2, ... , b do | + | i = ceil(j * n / N), | + | C_j = E_{K^i}(P_j (xor) C_{j-1}) | + | 5. Return C = C_1 | ... | C_b | + |----------------------------------------------------------------+ + + +----------------------------------------------------------------+ + | CBC-ACPKM-Master-Decrypt(N, K, T*, IV, C) | + |----------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - master key frequency T*, | + | - initialization vector IV in V_n, | + | - ciphertext C = C_1 | ... | C_b, |C_b| = n, |C| <= m_max. | + | Output: | + | - plaintext P. | + |----------------------------------------------------------------| + | 1. l = ceil(|C| / N) | + | 2. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) | + | 3. C_0 = IV | + | 4. For j = 1, 2, ... , b do | + | i = ceil(j * n / N) | + | P_j = D_{K^i}(C_j) (xor) C_{j-1} | + | 5. Return P = P_1 | ... | P_b | + +----------------------------------------------------------------+ + + The initialization vector IV for any particular execution of the + encryption process must be unpredictable. + + + + +Smyshlyaev Informational [Page 38] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +6.3.5. CFB-ACPKM-Master Encryption Mode + + This section defines a CFB-ACPKM-Master encryption mode that uses the + ACPKM-Master internal re-keying mechanism for the periodical key + transformation. + + The CFB-ACPKM-Master encryption mode can be considered as the base + encryption mode CFB (see [MODES]) extended by the ACPKM-Master + re-keying mechanism. + + The CFB-ACPKM-Master encryption mode can be used with the following + parameters: + + o 64 <= n <= 512. + + o 128 <= k <= 512. + + o The maximum message size m_max = N * (n * 2^{n/2-1} / k). + + The key material K[j] that is used for the j-th section processing is + equal to K^j, |K^j| = k bits. + + The CFB-ACPKM-Master mode encryption and decryption procedures are + defined as follows: + + +-------------------------------------------------------------+ + | CFB-ACPKM-Master-Encrypt(N, K, T*, IV, P) | + |-------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - master key frequency T*, | + | - initialization vector IV in V_n, | + | - plaintext P = P_1 | ... | P_b, |P| <= m_max. | + | Output: | + | - ciphertext C. | + |-------------------------------------------------------------| + | 1. l = ceil(|P| / N) | + | 2. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) | + | 3. C_0 = IV | + | 4. For j = 1, 2, ... , b - 1 do | + | i = ceil(j * n / N), | + | C_j = E_{K^i}(C_{j-1}) (xor) P_j | + | 5. C_b = MSB_{|P_b|}(E_{K^l}(C_{b-1})) (xor) P_b | + | 6. Return C = C_1 | ... | C_b | + |-------------------------------------------------------------+ + + + + + +Smyshlyaev Informational [Page 39] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + +-------------------------------------------------------------+ + | CFB-ACPKM-Master-Decrypt(N, K, T*, IV, C) | + |-------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - master key frequency T*, | + | - initialization vector IV in V_n, | + | - ciphertext C = C_1 | ... | C_b, |C| <= m_max. | + | Output: | + | - plaintext P. | + |-------------------------------------------------------------| + | 1. l = ceil(|C| / N) | + | 2. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) | + | 3. C_0 = IV | + | 4. For j = 1, 2, ... , b - 1 do | + | i = ceil(j * n / N), | + | P_j = E_{K^i}(C_{j-1}) (xor) C_j | + | 5. P_b = MSB_{|C_b|}(E_{K^l}(C_{b-1})) (xor) C_b | + | 6. Return P = P_1 | ... | P_b | + +-------------------------------------------------------------+ + + The initialization vector IV for any particular execution of the + encryption process must be unpredictable. + +6.3.6. OMAC-ACPKM-Master Authentication Mode + + This section defines an OMAC-ACPKM-Master message authentication code + calculation mode that uses the ACPKM-Master internal re-keying + mechanism for the periodical key transformation. + + The OMAC-ACPKM-Master mode can be considered as the base message + authentication code calculation mode OMAC1, which is also known as + CMAC (see [RFC4493]), extended by the ACPKM-Master re-keying + mechanism. + + The OMAC-ACPKM-Master message authentication code calculation mode + can be used with the following parameters: + + o n in {64, 128, 256}. + + o 128 <= k <= 512. + + o The maximum message size m_max = N * (n * 2^{n/2-1} / (k + n)). + + The key material K[j] that is used for one-section processing is + equal to K^j | K^j_1, where |K^j| = k bits and |K^j_1| = n bits. + + + + +Smyshlyaev Informational [Page 40] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + The following is a specification of the subkey generation process of + OMAC: + + +-------------------------------------------------------------------+ + | Generate_Subkey(K1, r) | + |-------------------------------------------------------------------| + | Input: | + | - key K1. | + | Output: | + | - key SK. | + |-------------------------------------------------------------------| + | 1. If r = n, then return K1 | + | 2. If r < n, then | + | if MSB_1(K1) = 0 | + | return K1 << 1 | + | else | + | return (K1 << 1) (xor) R_n | + +-------------------------------------------------------------------+ + + Here, R_n takes the following values: + + o n = 64: R_{64} = 0^{59} | 11011. + + o n = 128: R_{128} = 0^{120} | 10000111. + + o n = 256: R_{256} = 0^{145} | 10000100101. + + + + + + + + + + + + + + + + + + + + + + + + + +Smyshlyaev Informational [Page 41] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + The OMAC-ACPKM-Master message authentication code calculation mode is + defined as follows: + + +-------------------------------------------------------------------+ + | OMAC-ACPKM-Master(K, N, T*, M) | + |-------------------------------------------------------------------| + | Input: | + | - section size N, | + | - initial key K, | + | - master key frequency T*, | + | - plaintext M = M_1 | ... | M_b, |M| <= m_max. | + | Output: | + | - message authentication code T. | + |-------------------------------------------------------------------| + | 1. C_0 = 0^n | + | 2. l = ceil(|M| / N) | + | 3. K^1 | K^1_1 | ... | K^l | K^l_1 = | + = ACPKM-Master(T*, K, (k + n), l) | + | 4. For j = 1, 2, ... , b - 1 do | + | i = ceil(j * n / N), | + | C_j = E_{K^i}(M_j (xor) C_{j-1}) | + | 5. SK = Generate_Subkey(K^l_1, |M_b|) | + | 6. If |M_b| = n, then M*_b = M_b | + | else M*_b = M_b | 1 | 0^{n - 1 -|M_b|} | + | 7. T = E_{K^l}(M*_b (xor) C_{b-1} (xor) SK) | + | 8. Return T | + +-------------------------------------------------------------------+ + +7. Joint Usage of External and Internal Re-keying + + Both external re-keying and internal re-keying have their own + advantages and disadvantages, which are discussed in Section 1. For + instance, using external re-keying can essentially limit the message + length, while in the case of internal re-keying, the section size, + which can be chosen as the maximal possible for operational + properties, limits the number of separate messages. Therefore, the + choice of re-keying mechanism (either external or internal) depends + on particular protocol features. However, some protocols may have + features that require the advantages of both the external and + internal re-keying mechanisms: for example, the protocol mainly + transmits short messages, but it must additionally support processing + of very long messages. In such situations, it is necessary to use + external and internal re-keying jointly, since these techniques + negate each other's disadvantages. + + For composition of external and internal re-keying techniques, any + mechanism described in Section 5 can be used with any mechanism + described in Section 6. + + + +Smyshlyaev Informational [Page 42] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + For example, consider the GCM-ACPKM mode with external serial + re-keying based on a KDF on a hash function. Denote the number of + messages in each frame (in the case of the implicit approach to the + key lifetime control) for external re-keying as a frame size. + + Let L be a key lifetime limitation. The section size N for internal + re-keying and the frame size q for external re-keying must be chosen + in such a way that q * N must not exceed L. + + Suppose that t messages (ICN_i, P_i, A_i), with initial counter nonce + ICN_i, plaintext P_i, and additional authenticated data A_i will be + processed before renegotiation. + + For authenticated encryption of each message (ICN_i, P_i, A_i), i = + 1, ..., t, the following algorithm can be applied: + + 1. j = ceil(i / q), + 2. K^j = ExtSerialH(K, j), + 3. C_i | T_i = GCM-ACPKM-Encrypt(N, K^j, ICN_i, P_i, A_i). + + Note that nonces ICN_i that are used under the same frame key must be + unique for each message. + +8. Security Considerations + + Re-keying should be used to increase a priori security properties of + ciphers in hostile environments (e.g., with side-channel + adversaries). If efficient attacks on a cipher are known, the cipher + must not be used. Thus, re-keying cannot be used as a patch for + vulnerable ciphers. Base cipher properties must be well analyzed + because the security of re-keying mechanisms is based on the security + of a block cipher as a pseudorandom function. + + Re-keying is not intended to solve any postquantum security issues + for symmetric cryptography, since the reduction of security caused by + Grover's algorithm is not connected with a size of plaintext + transformed by a cipher -- only a negligible (sufficient for key + uniqueness) material is needed -- and the aim of re-keying is to + limit the size of plaintext transformed under one initial key. + + Re-keying can provide backward security only if previous key material + is securely deleted after usage by all parties. + +9. IANA Considerations + + This document has no IANA actions. + + + + + +Smyshlyaev Informational [Page 43] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +10. References + +10.1. Normative References + + [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, + RFC 5652, DOI 10.17487/RFC5652, September 2009, + . + + [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, . + + [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, DOI 10.17487/RFC4303, December 2005, + . + + [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of + Operation: Galois/Counter Mode (GCM) and GMAC", NIST + Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, + November 2007, + . + + [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of + Operation: Methods and Techniques", NIST Special + Publication 800-38A, DOI 10.6028/NIST.SP.800-38A, December + 2001. + + [NISTSP800-108] + National Institute of Standards and Technology, + "Recommendation for Key Derivation Using Pseudorandom + Functions", NIST Special Publication 800-108, October + 2009, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The + AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June + 2006, . + + [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand + Key Derivation Function (HKDF)", RFC 5869, + DOI 10.17487/RFC5869, May 2010, + . + + + +Smyshlyaev Informational [Page 44] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., + Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines + on the Cryptographic Algorithms to Accompany the Usage of + Standards GOST R 34.10-2012 and GOST R 34.11-2012", + RFC 7836, DOI 10.17487/RFC7836, March 2016, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [SSH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) + Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, + January 2006, . + + [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + +10.2. Informative References + + [AAOS2017] Ahmetzyanova, L., Alekseev, E., Oshkin, I., and S. + Smyshlyaev, "Increasing the Lifetime of Symmetric Keys for + the GCM Mode by Internal Re-keying", Cryptology ePrint + Archive, Report 2017/697, 2017, + . + + [AbBell] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a + Key: A Comparative Analysis of the Security of Re-keying + Techniques", ASIACRYPT 2000, Lecture Notes in Computer + Science, Volume 1976, pp. 546-559, + DOI 10.1007/3-540-44448-3_42, October 2000. + + [AESDUKPT] American National Standards Institute, "Retail Financial + Services Symmetric Key Management - Part 3: Derived Unique + Key Per Transaction", ANSI X9.24-3-2017, October 2017. + + [FKK2005] Fu, K., Kamara, S., and T. Kohno, "Key Regression: + Enabling Efficient Key Distribution for Secure Distributed + Storage", November 2005, . + + + + + + + + + + +Smyshlyaev Informational [Page 45] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + [FPS2012] Faust, S., Pietrzak, K., and J. Schipper, "Practical + Leakage-Resilient Symmetric Cryptography", Cryptographic + Hardware and Embedded Systems (CHES), Lecture Notes in + Computer Science, Volume 7428, pp. 213-232, + DOI 10.1007/978-3-642-33027-8_13, 2012, + . + + [FRESHREKEYING] + Dziembowski, S., Faust, S., Herold, G., Journault, A., + Masny, D., and F. Standaert, "Towards Sound Fresh + Re-Keying with Hard (Physical) Learning Problems", + Cryptology ePrint Archive, Report 2016/573, June 2016, + . + + [GGM] Goldreich, O., Goldwasser, S., and S. Micali, "How to + Construct Random Functions", Journal of the Association + for Computing Machinery, Volume 33, No. 4, pp. 792-807, + DOI 10.1145/6490.6503, October 1986, + . + + [KMNT2003] Kim, Y., Maino, F., Narasimha, M., and G. Tsudik, "Secure + Group Services for Storage Area Networks", + IEEE Communications Magazine 41, Number 8, pp. 92-99, + DOI 10.1109/SISW.2002.1183514, August 2003, + . + + [LDC] Heys, H., "A Tutorial on Linear and Differential + Cryptanalysis", 2001, . + + [OWT] Joye, M. and S. Yen, "One-Way Cross-Trees and Their + Applications", Public Key Cryptography (PKC), Lecture + Notes in Computer Science, Volume 2274, + DOI 10.1007/3-540-45664-3_25, February 2002, + . + + [P3] Alexander, P., "Subject: [Cfrg] Dynamic Key Changes on + Encrypted Sessions. - Draft I-D Attached", message to + the CFRG mailing list, 4 November 2017, + . + + + + + + + + +Smyshlyaev Informational [Page 46] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + [Pietrzak2009] + Pietrzak, K., "A Leakage-Resilient Mode of Operation", + EUROCRYPT 2009, Lecture Notes in Computer Science, Volume + 5479, pp. 462-482, DOI 10.1007/978-3-642-01001-9_27, April + 2009, . + + [SIGNAL] Perrin, T., Ed. and M. Marlinspike, "The Double Ratchet + Algorithm", November 2016, . + + [Sweet32] Bhargavan, K. and G. Leurent, "On the Practical + (In-)Security of 64-bit Block Ciphers: Collision Attacks + on HTTP over TLS and OpenVPN", Proceedings of the 2016 ACM + SIGSAC Conference on Computer and Communications + Security, pp. 456-467, DOI 10.1145/2976749.2978423, + October 2016, . + + [TAHA] Taha, M. and P. Schaumont, "Key Updating for Leakage + Resiliency With Application to AES Modes of Operation", + IEEE Transactions on Information Forensics and Security, + DOI 10.1109/TIFS.2014.2383359, December 2014, + . + + [TEMPEST] Ramsay, C. and J. Lohuis, "TEMPEST attacks against AES. + Covertly stealing keys for 200 euro", June 2017, + . + + [U2F] Chang, D., Mishra, S., Sanadhya, S., and A. Singh, "On + Making U2F Protocol Leakage-Resilient via Re-keying", + Cryptology ePrint Archive, Report 2017/721, August 2017, + . + + + + + + + + + + + + + + + + + + +Smyshlyaev Informational [Page 47] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +Appendix A. Test Examples + +A.1. Test Examples for External Re-keying + +A.1.1. External Re-keying with a Parallel Construction + + External re-keying with a parallel construction based on AES-256 + **************************************************************** + k = 256 + t = 128 + + Initial key: + 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F + 0F 0E 0D 0C 0B 0A 09 08 07 06 05 04 03 02 01 00 + + K^1: + 51 16 8A B6 C8 A8 38 65 54 85 31 A5 D2 BA C3 86 + 64 7D 5C D5 1C 3D 62 98 BC 09 B1 D8 64 EC D9 B1 + + K^2: + 6F ED F5 D3 77 57 48 75 35 2B 5F 4D B6 5B E0 15 + B8 02 92 32 D8 D3 8D 73 FE DC DD C6 C8 36 78 BD + + K^3: + B6 40 24 85 A4 24 BD 35 B4 26 43 13 76 26 70 B6 + 5B F3 30 3D 3B 20 EB 14 D1 3B B7 91 74 E3 DB EC + + ... + + K^126: + 2F 3F 15 1B 53 88 23 CD 7D 03 FC 3D FD B3 57 5E + 23 E4 1C 4E 46 FF 6B 33 34 12 27 84 EF 5D 82 23 + + K^127: + 8E 51 31 FB 0B 64 BB D0 BC D4 C5 7B 1C 66 EF FD + 97 43 75 10 6C AF 5D 5E 41 E0 17 F4 05 63 05 ED + + K^128: + 77 4F BF B3 22 60 C5 3B A3 8E FE B1 96 46 76 41 + 94 49 AF 84 2D 84 65 A7 F4 F7 2C DC A4 9D 84 F9 + + External re-keying with a parallel construction based on SHA-256 + **************************************************************** + k = 256 + t = 128 + + label: + SHA2label + + + +Smyshlyaev Informational [Page 48] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Initial key: + 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F + 0F 0E 0D 0C 0B 0A 09 08 07 06 05 04 03 02 01 00 + + K^1: + C1 A1 4C A0 30 29 BE 43 9F 35 3C 79 1A 51 48 57 + 26 7A CD 5A E8 7D E7 D1 B2 E2 C7 AF A4 29 BD 35 + + K^2: + 03 68 BB 74 41 2A 98 ED C4 7B 94 CC DF 9C F4 9E + A9 B8 A9 5F 0E DC 3C 1E 3B D2 59 4D D1 75 82 D4 + + K^3: + 2F D3 68 D3 A7 8F 91 E6 3B 68 DC 2B 41 1D AC 80 + 0A C3 14 1D 80 26 3E 61 C9 0D 24 45 2A BD B1 AE + + ... + + K^126: + 55 AC 2B 25 00 78 3E D4 34 2B 65 0E 75 E5 8B 76 + C8 04 E9 D3 B6 08 7D C0 70 2A 99 A4 B5 85 F1 A1 + + K^127: + 77 4D 15 88 B0 40 90 E5 8C 6A D7 5D 0F CF 0A 4A + 6C 23 F1 B3 91 B1 EF DF E5 77 64 CD 09 F5 BC AF + + K^128: + E5 81 FF FB 0C 90 88 CD E5 F4 A5 57 B6 AB D2 2E + 94 C3 42 06 41 AB C1 72 66 CC 2F 59 74 9C 86 B3 + +A.1.2. External Re-keying with a Serial Construction + + External re-keying with a serial construction based on AES-256 + ************************************************************** + AES 256 examples: + k = 256 + t = 128 + + Initial key: + 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F + 0F 0E 0D 0C 0B 0A 09 08 07 06 05 04 03 02 01 00 + + K*_1: + 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F + 0F 0E 0D 0C 0B 0A 09 08 07 06 05 04 03 02 01 00 + + + + + + +Smyshlyaev Informational [Page 49] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + K^1: + 66 B8 BD E5 90 6C EC DF FA 8A B2 FD 92 84 EB F0 + 51 16 8A B6 C8 A8 38 65 54 85 31 A5 D2 BA C3 86 + + K*_2: + 64 7D 5C D5 1C 3D 62 98 BC 09 B1 D8 64 EC D9 B1 + 6F ED F5 D3 77 57 48 75 35 2B 5F 4D B6 5B E0 15 + + K^2: + 66 B8 BD E5 90 6C EC DF FA 8A B2 FD 92 84 EB F0 + 51 16 8A B6 C8 A8 38 65 54 85 31 A5 D2 BA C3 86 + + K*_3: + 64 7D 5C D5 1C 3D 62 98 BC 09 B1 D8 64 EC D9 B1 + 6F ED F5 D3 77 57 48 75 35 2B 5F 4D B6 5B E0 15 + + K^3: + 66 B8 BD E5 90 6C EC DF FA 8A B2 FD 92 84 EB F0 + 51 16 8A B6 C8 A8 38 65 54 85 31 A5 D2 BA C3 86 + + ... + + K*_126: + 64 7D 5C D5 1C 3D 62 98 BC 09 B1 D8 64 EC D9 B1 + 6F ED F5 D3 77 57 48 75 35 2B 5F 4D B6 5B E0 15 + + K^126: + 66 B8 BD E5 90 6C EC DF FA 8A B2 FD 92 84 EB F0 + 51 16 8A B6 C8 A8 38 65 54 85 31 A5 D2 BA C3 86 + + K*_127: + 64 7D 5C D5 1C 3D 62 98 BC 09 B1 D8 64 EC D9 B1 + 6F ED F5 D3 77 57 48 75 35 2B 5F 4D B6 5B E0 15 + + K^127: + 66 B8 BD E5 90 6C EC DF FA 8A B2 FD 92 84 EB F0 + 51 16 8A B6 C8 A8 38 65 54 85 31 A5 D2 BA C3 86 + + K*_128: + 64 7D 5C D5 1C 3D 62 98 BC 09 B1 D8 64 EC D9 B1 + 6F ED F5 D3 77 57 48 75 35 2B 5F 4D B6 5B E0 15 + + K^128: + 66 B8 BD E5 90 6C EC DF FA 8A B2 FD 92 84 EB F0 + 51 16 8A B6 C8 A8 38 65 54 85 31 A5 D2 BA C3 86 + + + + + + +Smyshlyaev Informational [Page 50] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + External re-keying with a serial construction based on SHA-256 + ************************************************************** + k = 256 + t = 128 + + Initial key: + 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F + 0F 0E 0D 0C 0B 0A 09 08 07 06 05 04 03 02 01 00 + + label1: + SHA2label1 + + label2: + SHA2label2 + + K*_1: + 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F + 0F 0E 0D 0C 0B 0A 09 08 07 06 05 04 03 02 01 00 + + K^1: + 2D A8 D1 37 6C FD 52 7F F7 36 A4 E2 81 C6 0A 9B + F3 8E 66 97 ED 70 4F B5 FB 10 33 CC EC EE D5 EC + + K*_2: + 14 65 5A D1 7C 19 86 24 9B D3 56 DF CC BE 73 6F + 52 62 4A 9D E3 CC 40 6D A9 48 DA 5C D0 68 8A 04 + + K^2: + 2F EA 8D 57 2B EF B8 89 42 54 1B 8C 1B 3F 8D B1 + 84 F9 56 C7 FE 01 11 99 1D FB 98 15 FE 65 85 CF + + K*_3: + 18 F0 B5 2A D2 45 E1 93 69 53 40 55 43 70 95 8D + 70 F0 20 8C DF B0 5D 67 CD 1B BF 96 37 D3 E3 EB + + K^3: + 53 C7 4E 79 AE BC D1 C8 24 04 BF F6 D7 B1 AC BF + F9 C0 0E FB A8 B9 48 29 87 37 E1 BA E7 8F F7 92 + + ... + + K*_126: + A3 6D BF 02 AA 0B 42 4A F2 C0 46 52 68 8B C7 E6 + 5E F1 62 C3 B3 2F DD EF E4 92 79 5D BB 45 0B CA + + K^126: + 6C 4B D6 22 DC 40 48 0F 29 C3 90 B8 E5 D7 A7 34 + 23 4D 34 65 2C CE 4A 76 2C FE 2A 42 C8 5B FE 9A + + + +Smyshlyaev Informational [Page 51] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + K*_127: + 84 5F 49 3D B8 13 1D 39 36 2B BE D3 74 8F 80 A1 + 05 A7 07 37 BA 15 72 E0 73 49 C2 67 5D 0A 28 A1 + + K^127: + 57 F0 BD 5A B8 2A F3 6B 87 33 CF F7 22 62 B4 D0 + F0 EE EF E1 50 74 E5 BA 13 C1 23 68 87 36 29 A2 + + K*_128: + 52 F2 0F 56 5C 9C 56 84 AF 69 AD 45 EE B8 DA 4E + 7A A6 04 86 35 16 BA 98 E4 CB 46 D2 E8 9A C1 09 + + K^128: + 9B DD 24 7D F3 25 4A 75 E0 22 68 25 68 DA 9D D5 + C1 6D 2D 2B 4F 3F 1F 2B 5E 99 82 7F 15 A1 4F A4 + +A.2. Test Examples for Internal Re-keying + +A.2.1. Internal Re-keying Mechanisms that Do Not Require a Master Key + + CTR-ACPKM mode with AES-256 + *************************** + k = 256 + n = 128 + c = 64 + N = 256 + + Initial 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 + + 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: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 + 00050: 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 + 00060: 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 + + ICN: + 12 34 56 78 90 AB CE F0 A1 B2 C3 D4 E5 F0 01 12 + 23 34 45 56 67 78 89 90 12 13 14 15 16 17 18 19 + + D_1: + 00000: 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F + + + + + +Smyshlyaev Informational [Page 52] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + D_2: + 00000: 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F + + Section_1 + + Section key K^1: + 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 + + Input block CTR_1: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 00 + + Output block G_1: + 00000: FD 7E F8 9A D9 7E A4 B8 8D B8 B5 1C 1C 9D 6D D0 + + Input block CTR_2: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 01 + + Output block G_2: + 00000: 19 98 C5 71 76 37 FB 17 11 E4 48 F0 0C 0D 60 B2 + + Section_2 + + Section key K^2: + 00000: F6 80 D1 21 2F A4 3D F4 EC 3A 91 DE 2A B1 6F 1B + 00010: 36 B0 48 8A 4F C1 2E 09 98 D2 E4 A8 88 E8 4F 3D + + Input block CTR_3: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 02 + + Output block G_3: + 00000: E4 88 89 4F B6 02 87 DB 77 5A 07 D9 2C 89 46 EA + + Input block CTR_4: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 03 + + Output block G_4: + 00000: BC 4F 87 23 DB F0 91 50 DD B4 06 C3 1D A9 7C A4 + + Section_3 + + Section key K^3: + 00000: 8E B9 7E 43 27 1A 42 F1 CA 8E E2 5F 5C C7 C8 3B + 00010: 1A CE 9E 5E D0 6A A5 3B 57 B9 6A CF 36 5D 24 B8 + + Input block CTR_5: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 04 + + + + +Smyshlyaev Informational [Page 53] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Output block G_5: + 00000: 68 6F 22 7D 8F B2 9C BD 05 C8 C3 7D 22 FE 3B B7 + + Input block CTR_6: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 05 + + Output block G_6: + 00000: C0 1B F9 7F 75 6E 12 2F 80 59 55 BD DE 2D 45 87 + + Section_4 + + Section key K^4: + 00000: C5 71 6C C9 67 98 BC 2D 4A 17 87 B7 8A DF 94 AC + 00010: E8 16 F8 0B DB BC AD 7D 60 78 12 9C 0C B4 02 F5 + + Block number 7: + + Input block CTR_7: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 06 + + Output block G_7: + 00000: 03 DE 34 74 AB 9B 65 8A 3B 54 1E F8 BD 2B F4 7D + + + The result G = G_1 | G_2 | G_3 | G_4 | G_5 | G_6 | G_7: + 00000: FD 7E F8 9A D9 7E A4 B8 8D B8 B5 1C 1C 9D 6D D0 + 00010: 19 98 C5 71 76 37 FB 17 11 E4 48 F0 0C 0D 60 B2 + 00020: E4 88 89 4F B6 02 87 DB 77 5A 07 D9 2C 89 46 EA + 00030: BC 4F 87 23 DB F0 91 50 DD B4 06 C3 1D A9 7C A4 + 00040: 68 6F 22 7D 8F B2 9C BD 05 C8 C3 7D 22 FE 3B B7 + 00050: C0 1B F9 7F 75 6E 12 2F 80 59 55 BD DE 2D 45 87 + 00060: 03 DE 34 74 AB 9B 65 8A 3B 54 1E F8 BD 2B F4 7D + + The result ciphertext C = P (xor) MSB_{|P|}(G): + 00000: EC 5C CB DE 8C 18 D3 B8 72 56 68 D0 A7 37 F4 58 + 00010: 19 89 E7 42 32 62 9D 60 99 7D E2 4B C0 E3 9F B8 + 00020: F5 AA BA 0B E3 64 F0 53 EE F0 BC 15 C2 76 4C EA + 00030: 9E 7C C3 76 BD 87 19 C9 77 0F CA 2D E2 A3 7C B5 + 00040: 5B 2B 77 1B F8 3A 05 17 BE 04 2D 82 28 FE 2A 95 + 00050: 84 4E 9F 08 FD F7 B8 94 4C B7 AA B7 DE 3C 67 B4 + 00060: 56 B8 43 FC 32 31 DE 46 D5 AB 14 F8 AC 09 C7 39 + + + + + + + + + + +Smyshlyaev Informational [Page 54] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + GCM-ACPKM mode with AES-128 + *************************** + k = 128 + n = 128 + c = 32 + N = 256 + + Initial key K: + 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + Additional data A: + 00000: 11 22 33 + + Plaintext: + 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + ICN: + 00000: 00 00 00 00 00 00 00 00 00 00 00 00 + + Number of sections: 2 + + Section key K^1: + 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + Section key K^2: + 00000: 15 1A 9F B0 B6 AC C5 97 6A FB 50 31 D1 DE C8 41 + + Encrypted GCTR_1 | GCTR_2 | GCTR_3: + 00000: 03 88 DA CE 60 B6 A3 92 F3 28 C2 B9 71 B2 FE 78 + 00010: F7 95 AA AB 49 4B 59 23 F7 FD 89 FF 94 8B C1 E0 + 00020: D6 B3 12 46 E9 CE 9F F1 3A B3 42 7E E8 91 96 AD + + Ciphertext C: + 00000: 03 88 DA CE 60 B6 A3 92 F3 28 C2 B9 71 B2 FE 78 + 00010: F7 95 AA AB 49 4B 59 23 F7 FD 89 FF 94 8B C1 E0 + 00020: D6 B3 12 46 E9 CE 9F F1 3A B3 42 7E E8 91 96 AD + + GHASH input: + 00000: 11 22 33 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00010: 03 88 DA CE 60 B6 A3 92 F3 28 C2 B9 71 B2 FE 78 + 00020: F7 95 AA AB 49 4B 59 23 F7 FD 89 FF 94 8B C1 E0 + 00030: D6 B3 12 46 E9 CE 9F F1 3A B3 42 7E E8 91 96 AD + 00040: 00 00 00 00 00 00 00 18 00 00 00 00 00 00 01 80 + + GHASH output S: + 00000: E8 ED E9 94 9A DD 55 30 B0 F4 4E F5 00 FC 3E 3C + + + +Smyshlyaev Informational [Page 55] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Authentication tag T: + 00000: B0 0F 15 5A 60 A3 65 51 86 8B 53 A2 A4 1B 7B 66 + + The result C | T: + 00000: 03 88 DA CE 60 B6 A3 92 F3 28 C2 B9 71 B2 FE 78 + 00010: F7 95 AA AB 49 4B 59 23 F7 FD 89 FF 94 8B C1 E0 + 00020: D6 B3 12 46 E9 CE 9F F1 3A B3 42 7E E8 91 96 AD + 00030: B0 0F 15 5A 60 A3 65 51 86 8B 53 A2 A4 1B 7B 66 + +A.2.2. Internal Re-keying Mechanisms with a Master Key + + CTR-ACPKM-Master mode with AES-256 + ********************************** + k = 256 + n = 128 + c for CTR-ACPKM mode = 64 + c for CTR-ACPKM-Master mode = 64 + N = 256 + T* = 512 + + Initial 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 + + Initial vector ICN: + 00000: 12 34 56 78 90 AB CE F0 A1 B2 C3 D4 E5 F0 01 12 + + 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: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 + 00050: 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 + 00060: 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 + + K^1 | K^2 | K^3 | K^4: + 00000: 9F 10 BB F1 3A 79 FB BD 4A 4C A8 64 C4 90 74 64 + 00010: 39 FE 50 6D 4B 86 9B 21 03 A3 B6 A4 79 28 3C 60 + 00020: 77 91 17 50 E0 D1 77 E5 9A 13 78 2B F1 89 08 D0 + 00030: AB 6B 59 EE 92 49 05 B3 AB C7 A4 E3 69 65 76 C3 + 00040: E8 76 2B 30 8B 08 EB CE 3E 93 9A C2 C0 3E 76 D4 + 00050: 60 9A AB D9 15 33 13 D3 CF D3 94 E7 75 DF 3A 94 + 00060: F2 EE 91 45 6B DC 3D E4 91 2C 87 C3 29 CF 31 A9 + 00070: 2F 20 2E 5A C4 9A 2A 65 31 33 D6 74 8C 4F F9 12 + + + + + + +Smyshlyaev Informational [Page 56] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Section_1 + + K^1: + 00000: 9F 10 BB F1 3A 79 FB BD 4A 4C A8 64 C4 90 74 64 + 00010: 39 FE 50 6D 4B 86 9B 21 03 A3 B6 A4 79 28 3C 60 + + Input block CTR_1: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 00 + + Output block G_1: + 00000: 8C A2 B6 82 A7 50 65 3F 8E BF 08 E7 9F 99 4D 5C + + Input block CTR_2: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 01 + + Output block G_2: + 00000: F6 A6 A5 BA 58 14 1E ED 23 DC 31 68 D2 35 89 A1 + + + Section_2 + + K^2: + 00000: 77 91 17 50 E0 D1 77 E5 9A 13 78 2B F1 89 08 D0 + 00010: AB 6B 59 EE 92 49 05 B3 AB C7 A4 E3 69 65 76 C3 + + Input block CTR_3: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 02 + + Output block G_3: + 00000: 4A 07 5F 86 05 87 72 94 1D 8E 7D F8 32 F4 23 71 + + Input block CTR_4: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 03 + + Output block G_4: + 00000: 23 35 66 AF 61 DD FE A7 B1 68 3F BA B0 52 4A D7 + + + Section_3 + + K^3: + 00000: E8 76 2B 30 8B 08 EB CE 3E 93 9A C2 C0 3E 76 D4 + 00010: 60 9A AB D9 15 33 13 D3 CF D3 94 E7 75 DF 3A 94 + + Input block CTR_5: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 04 + + + + + +Smyshlyaev Informational [Page 57] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Output block G_5: + 00000: A8 09 6D BC E8 BB 52 FC DE 6E 03 70 C1 66 95 E8 + + Input block CTR_6: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 05 + + Output block G_6: + 00000: C6 E3 6E 8E 5B 82 AA C4 A6 6C 14 8D B1 F6 9B EF + + + Section_4 + + K^4: + 00000: F2 EE 91 45 6B DC 3D E4 91 2C 87 C3 29 CF 31 A9 + 00010: 2F 20 2E 5A C4 9A 2A 65 31 33 D6 74 8C 4F F9 12 + + Input block CTR_7: + 00000: 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 06 + + Output block G_7: + 00000: 82 2B E9 07 96 37 44 95 75 36 3F A7 07 F8 40 22 + + + The result G = G_1 | G_2 | G_3 | G_4 | G_5 | G_6 | G_7: + 00000: 8C A2 B6 82 A7 50 65 3F 8E BF 08 E7 9F 99 4D 5C + 00010: F6 A6 A5 BA 58 14 1E ED 23 DC 31 68 D2 35 89 A1 + 00020: 4A 07 5F 86 05 87 72 94 1D 8E 7D F8 32 F4 23 71 + 00030: 23 35 66 AF 61 DD FE A7 B1 68 3F BA B0 52 4A D7 + 00040: A8 09 6D BC E8 BB 52 FC DE 6E 03 70 C1 66 95 E8 + 00050: C6 E3 6E 8E 5B 82 AA C4 A6 6C 14 8D B1 F6 9B EF + 00060: 82 2B E9 07 96 37 44 95 75 36 3F A7 07 F8 40 22 + + The result ciphertext C = P (xor) MSB_{|P|}(G): + 00000: 9D 80 85 C6 F2 36 12 3F 71 51 D5 2B 24 33 D4 D4 + 00010: F6 B7 87 89 1C 41 78 9A AB 45 9B D3 1E DB 76 AB + 00020: 5B 25 6C C2 50 E1 05 1C 84 24 C6 34 DC 0B 29 71 + 00030: 01 06 22 FA 07 AA 76 3E 1B D3 F3 54 4F 58 4A C6 + 00040: 9B 4D 38 DA 9F 33 CB 56 65 A2 ED 8F CB 66 84 CA + 00050: 82 B6 08 F9 D3 1B 00 7F 6A 82 EB 87 B1 E7 B9 DC + 00060: D7 4D 9E 8F 0F 9D FF 59 9B C9 35 A7 16 DA 73 66 + + + + + + + + + + + +Smyshlyaev Informational [Page 58] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + GCM-ACPKM-Master mode with AES-256 + ********************************** + k = 192 + n = 128 + c for the CTR-ACPKM mode = 64 + c for the GCM-ACPKM-Master mode = 32 + T* = 384 + N = 256 + + Initial key K: + 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00010: 00 00 00 00 00 00 00 00 + + Additional data A: + 00000: 11 22 33 + + Plaintext: + 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + ICN: + 00000: 00 00 00 00 00 00 00 00 00 00 00 00 + + Number of sections: 3 + + K^1 | K^2 | K^3: + 00000: 93 BA AF FB 35 FB E7 39 C1 7C 6A C2 2E EC F1 8F + 00010: 7B 89 F0 BF 8B 18 07 05 96 48 68 9F 36 A7 65 CC + 00020: CD 5D AC E2 0D 47 D9 18 D7 86 D0 41 A8 3B AB 99 + 00030: F5 F8 B1 06 D2 71 78 B1 B0 08 C9 99 0B 72 E2 87 + 00040: 5A 2D 3C BE F1 6E 67 3C + + Encrypted GCTR_1 | ... | GCTR_5 + 00000: 43 FA 71 81 64 B1 E3 D7 1E 7B 65 39 A7 02 1D 52 + 00010: 69 9B 9E 1B 43 24 B7 52 95 74 E7 90 F2 BE 60 E8 + 00020: 11 62 C9 90 2A 2B 77 7F D9 6A D6 1A 99 E0 C6 DE + 00030: 4B 91 D4 29 E3 1A 8C 11 AF F0 BC 47 F6 80 AF 14 + 00040: 40 1C C1 18 14 63 8E 76 24 83 37 75 16 34 70 08 + + Ciphertext C: + 00000: 43 FA 71 81 64 B1 E3 D7 1E 7B 65 39 A7 02 1D 52 + 00010: 69 9B 9E 1B 43 24 B7 52 95 74 E7 90 F2 BE 60 E8 + 00020: 11 62 C9 90 2A 2B 77 7F D9 6A D6 1A 99 E0 C6 DE + 00030: 4B 91 D4 29 E3 1A 8C 11 AF F0 BC 47 F6 80 AF 14 + 00040: 40 1C C1 18 14 63 8E 76 24 83 37 75 16 34 70 08 + + + +Smyshlyaev Informational [Page 59] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + GHASH input: + 00000: 11 22 33 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00010: 43 FA 71 81 64 B1 E3 D7 1E 7B 65 39 A7 02 1D 52 + 00020: 69 9B 9E 1B 43 24 B7 52 95 74 E7 90 F2 BE 60 E8 + 00030: 11 62 C9 90 2A 2B 77 7F D9 6A D6 1A 99 E0 C6 DE + 00040: 4B 91 D4 29 E3 1A 8C 11 AF F0 BC 47 F6 80 AF 14 + 00050: 40 1C C1 18 14 63 8E 76 24 83 37 75 16 34 70 08 + 00060: 00 00 00 00 00 00 00 18 00 00 00 00 00 00 02 80 + + GHASH output S: + 00000: 6E A3 4B D5 6A C5 40 B7 3E 55 D5 86 D1 CC 09 7D + + Authentication tag T: + 00050: CC 3A BA 11 8C E7 85 FD 77 78 94 D4 B5 20 69 F8 + + The result C | T: + 00000: 43 FA 71 81 64 B1 E3 D7 1E 7B 65 39 A7 02 1D 52 + 00010: 69 9B 9E 1B 43 24 B7 52 95 74 E7 90 F2 BE 60 E8 + 00020: 11 62 C9 90 2A 2B 77 7F D9 6A D6 1A 99 E0 C6 DE + 00030: 4B 91 D4 29 E3 1A 8C 11 AF F0 BC 47 F6 80 AF 14 + 00040: 40 1C C1 18 14 63 8E 76 24 83 37 75 16 34 70 08 + 00050: CC 3A BA 11 8C E7 85 FD 77 78 94 D4 B5 20 69 F8 + + + CBC-ACPKM-Master mode with AES-256 + ********************************** + k = 256 + n = 128 + c for the CTR-ACPKM mode = 64 + N = 256 + T* = 512 + + Initial 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 + + Initial vector IV: + 00000: 12 34 56 78 90 AB CE F0 A1 B2 C3 D4 E5 F0 01 12 + + 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: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 + 00050: 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 + 00060: 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 + + + + +Smyshlyaev Informational [Page 60] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + K^1 | K^2 | K^3 | K^4: + 00000: 9F 10 BB F1 3A 79 FB BD 4A 4C A8 64 C4 90 74 64 + 00010: 39 FE 50 6D 4B 86 9B 21 03 A3 B6 A4 79 28 3C 60 + 00020: 77 91 17 50 E0 D1 77 E5 9A 13 78 2B F1 89 08 D0 + 00030: AB 6B 59 EE 92 49 05 B3 AB C7 A4 E3 69 65 76 C3 + 00040: E8 76 2B 30 8B 08 EB CE 3E 93 9A C2 C0 3E 76 D4 + 00050: 60 9A AB D9 15 33 13 D3 CF D3 94 E7 75 DF 3A 94 + 00060: F2 EE 91 45 6B DC 3D E4 91 2C 87 C3 29 CF 31 A9 + 00070: 2F 20 2E 5A C4 9A 2A 65 31 33 D6 74 8C 4F F9 12 + + Section_1 + + K^1: + 00000: 9F 10 BB F1 3A 79 FB BD 4A 4C A8 64 C4 90 74 64 + 00010: 39 FE 50 6D 4B 86 9B 21 03 A3 B6 A4 79 28 3C 60 + + Plaintext block P_1: + 00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88 + + Input block P_1 (xor) C_0: + 00000: 03 16 65 3C C5 CD B9 F0 5E 5C 1E 18 5E 5A 98 9A + + Output block C_1: + 00000: 59 CB 5B CA C2 69 2C 60 0D 46 03 A0 C7 40 C9 7C + + Plaintext block P_2: + 00000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A + + Input block P_2 (xor) C_1: + 00000: 59 DA 79 F9 86 3C 4A 17 85 DF A9 1B 0B AE 36 76 + + Output block C_2: + 00000: 80 B6 02 74 54 8B F7 C9 78 1F A1 05 8B F6 8B 42 + + Section_2 + + K^2: + 00000: 77 91 17 50 E0 D1 77 E5 9A 13 78 2B F1 89 08 D0 + 00010: AB 6B 59 EE 92 49 05 B3 AB C7 A4 E3 69 65 76 C3 + + Plaintext block P_3: + 00000: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 + + Input block P_3 (xor) C_2: + 00000: 91 94 31 30 01 ED 80 41 E1 B5 1A C9 65 09 81 42 + + Output block C_3: + 00000: 8C 24 FB CF 68 15 B1 AF 65 FE 47 75 95 B4 97 59 + + + +Smyshlyaev Informational [Page 61] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Plaintext block P_4: + 00000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 + + Input block P_4 (xor) C_3: + 00000: AE 17 BF 9A 0E 62 39 36 CF 45 8B 9B 6A BE 97 48 + + Output block C_4: + 00000: 19 65 A5 00 58 0D 50 23 72 1B E9 90 E1 83 30 E9 + + Section_3 + + K^3: + 00000: E8 76 2B 30 8B 08 EB CE 3E 93 9A C2 C0 3E 76 D4 + 00010: 60 9A AB D9 15 33 13 D3 CF D3 94 E7 75 DF 3A 94 + + Plaintext block P_5: + 00000: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 + + Input block P_5 (xor) C_4: + 00000: 2A 21 F0 66 2F 85 C9 89 C9 D7 07 6F EB 83 21 CB + + Output block C_5: + 00000: 56 D8 34 F4 6F 0F 4D E6 20 53 A9 5C B5 F6 3C 14 + + Plaintext block P_6: + 00000: 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 + + Input block P_6 (xor) C_5: + 00000: 12 8D 52 83 E7 96 E7 5D EC BD 56 56 B5 E7 1E 27 + + Output block C_6: + 00000: 66 68 2B 8B DD 6E B2 7E DE C7 51 D6 2F 45 A5 45 + + Section_4 + + K^4: + 00000: F2 EE 91 45 6B DC 3D E4 91 2C 87 C3 29 CF 31 A9 + 00010: 2F 20 2E 5A C4 9A 2A 65 31 33 D6 74 8C 4F F9 12 + + Plaintext block P_7: + 00000: 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 + + Input block P_7 (xor) C_6: + 00000: 33 0E 5C 03 44 C4 09 B2 30 38 5B D6 3E 67 96 01 + + Output block C_7: + 00000: 7F 4D 87 F9 CA E9 56 09 79 C4 FA FE 34 0B 45 34 + + + + +Smyshlyaev Informational [Page 62] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Ciphertext C: + 00000: 59 CB 5B CA C2 69 2C 60 0D 46 03 A0 C7 40 C9 7C + 00010: 80 B6 02 74 54 8B F7 C9 78 1F A1 05 8B F6 8B 42 + 00020: 8C 24 FB CF 68 15 B1 AF 65 FE 47 75 95 B4 97 59 + 00030: 19 65 A5 00 58 0D 50 23 72 1B E9 90 E1 83 30 E9 + 00040: 56 D8 34 F4 6F 0F 4D E6 20 53 A9 5C B5 F6 3C 14 + 00050: 66 68 2B 8B DD 6E B2 7E DE C7 51 D6 2F 45 A5 45 + 00060: 7F 4D 87 F9 CA E9 56 09 79 C4 FA FE 34 0B 45 34 + + + CFB-ACPKM-Master mode with AES-256 + ********************************** + k = 256 + n = 128 + c for the CTR-ACPKM mode = 64 + N = 256 + T* = 512 + + Initial 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 + + Initial vector IV: + 00000: 12 34 56 78 90 AB CE F0 A1 B2 C3 D4 E5 F0 01 12 + + 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: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 + 00050: 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 + 00060: 55 66 77 88 99 AA BB CC + + K^1 | K^2 | K^3 | K^4 + 00000: 9F 10 BB F1 3A 79 FB BD 4A 4C A8 64 C4 90 74 64 + 00010: 39 FE 50 6D 4B 86 9B 21 03 A3 B6 A4 79 28 3C 60 + 00020: 77 91 17 50 E0 D1 77 E5 9A 13 78 2B F1 89 08 D0 + 00030: AB 6B 59 EE 92 49 05 B3 AB C7 A4 E3 69 65 76 C3 + 00040: E8 76 2B 30 8B 08 EB CE 3E 93 9A C2 C0 3E 76 D4 + 00050: 60 9A AB D9 15 33 13 D3 CF D3 94 E7 75 DF 3A 94 + 00060: F2 EE 91 45 6B DC 3D E4 91 2C 87 C3 29 CF 31 A9 + 00070: 2F 20 2E 5A C4 9A 2A 65 31 33 D6 74 8C 4F F9 12 + + + + + + + + +Smyshlyaev Informational [Page 63] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Section_1 + + K^1: + 00000: 9F 10 BB F1 3A 79 FB BD 4A 4C A8 64 C4 90 74 64 + 00010: 39 FE 50 6D 4B 86 9B 21 03 A3 B6 A4 79 28 3C 60 + + Plaintext block P_1: + 00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88 + + Encrypted block E_{K^1}(C_0): + 00000: 1C 39 9D 59 F8 5D 91 91 A9 D2 12 9F 63 15 90 03 + + Output block C_1 = E_{K^1}(C_0) (xor) P_1: + 00000: 0D 1B AE 1D AD 3B E6 91 56 3C CF 53 D8 BF 09 8B + + Plaintext block P_2: + 00000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A + + Encrypted block E_{K^1}(C_1): + 00000: 6B A2 C5 42 52 69 C6 0B 15 14 06 87 90 46 F6 2E + + Output block C_2 = E_{K^1}(C_1) (xor) P_2: + 00000: 6B B3 E7 71 16 3C A0 7C 9D 8D AC 3C 5C A8 09 24 + + Section_2 + + K^2: + 00000: 77 91 17 50 E0 D1 77 E5 9A 13 78 2B F1 89 08 D0 + 00010: AB 6B 59 EE 92 49 05 B3 AB C7 A4 E3 69 65 76 C3 + + Plaintext block P_3: + 00000: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 + + Encrypted block E_{K^2}(C_2): + 00000: 95 45 5F DB C3 9E 0A 13 9F CB 10 F5 BD 79 A3 88 + + Output block C_3 = E_{K^2}(C_2) (xor) P_3: + 00000: 84 67 6C 9F 96 F8 7D 9B 06 61 AB 39 53 86 A9 88 + + Plaintext block P_4: + 00000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 + + Encrypted block E_{K^2}(C_3): + 00000: E0 AA 32 5D 80 A4 47 95 BA 42 BF 63 F8 4A C8 B2 + + Output block C_4 = E_{K^2}(C_3) (xor) P_4: + 00000: C2 99 76 08 E6 D3 CF 0C 10 F9 73 8D 07 40 C8 A3 + + + + +Smyshlyaev Informational [Page 64] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Section_3 + + K^3: + 00000: E8 76 2B 30 8B 08 EB CE 3E 93 9A C2 C0 3E 76 D4 + 00010: 60 9A AB D9 15 33 13 D3 CF D3 94 E7 75 DF 3A 94 + + Plaintext block P_5: + 00000: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 + + Encrypted block E_{K^3}(C_4): + 00000: FE 42 8C 70 C2 51 CE 13 36 C1 BF 44 F8 49 66 89 + + Output block C_5 = E_{K^3}(C_4) (xor) P_5: + 00000: CD 06 D9 16 B5 D9 57 B9 8D 0D 51 BB F2 49 77 AB + + Plaintext block P_6: + 00000: 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 + + Encrypted block E_{K^3}(C_5): + 00000: 01 24 80 87 86 18 A5 43 11 0A CC B5 0A E5 02 A3 + + Output block C_6 = E_{K^3}(C_5) (xor) P_6: + 00000: 45 71 E6 F0 0E 81 0F F8 DD E4 33 BF 0A F4 20 90 + + Section_4 + + K^4: + 00000: F2 EE 91 45 6B DC 3D E4 91 2C 87 C3 29 CF 31 A9 + 00010: 2F 20 2E 5A C4 9A 2A 65 31 33 D6 74 8C 4F F9 12 + + Plaintext block P_7: + 00000: 55 66 77 88 99 AA BB CC + + Encrypted block MSB_{|P_7|}(E_{K^4}(C_6)): + 00000: 97 5C 96 37 55 1E 8C 7F + + Output block C_7 = MSB_{|P_7|}(E_{K^4}(C_6)) (xor) P_7 + 00000: C2 3A E1 BF CC B4 37 B3 + + Ciphertext C: + 00000: 0D 1B AE 1D AD 3B E6 91 56 3C CF 53 D8 BF 09 8B + 00010: 6B B3 E7 71 16 3C A0 7C 9D 8D AC 3C 5C A8 09 24 + 00020: 84 67 6C 9F 96 F8 7D 9B 06 61 AB 39 53 86 A9 88 + 00030: C2 99 76 08 E6 D3 CF 0C 10 F9 73 8D 07 40 C8 A3 + 00040: CD 06 D9 16 B5 D9 57 B9 8D 0D 51 BB F2 49 77 AB + 00050: 45 71 E6 F0 0E 81 0F F8 DD E4 33 BF 0A F4 20 90 + 00060: C2 3A E1 BF CC B4 37 B3 + + + + +Smyshlyaev Informational [Page 65] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + OMAC-ACPKM-Master mode with AES-256 + *********************************** + k = 256 + n = 128 + c for the CTR-ACPKM mode = 64 + N = 256 + T* = 768 + + Initial 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 + + Plaintext M: + 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: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 + + K^1 | K^1_1 | K^2 | K^2_1 | K^3 | K^3_1: + 00000: 9F 10 BB F1 3A 79 FB BD 4A 4C A8 64 C4 90 74 64 + 00010: 39 FE 50 6D 4B 86 9B 21 03 A3 B6 A4 79 28 3C 60 + 00020: 77 91 17 50 E0 D1 77 E5 9A 13 78 2B F1 89 08 D0 + 00030: AB 6B 59 EE 92 49 05 B3 AB C7 A4 E3 69 65 76 C3 + 00040: 9D CC 66 42 0D FF 45 5B 21 F3 93 F0 D4 D6 6E 67 + 00050: BB 1B 06 0B 87 66 6D 08 7A 9D A7 49 55 C3 5B 48 + 00060: F2 EE 91 45 6B DC 3D E4 91 2C 87 C3 29 CF 31 A9 + 00070: 2F 20 2E 5A C4 9A 2A 65 31 33 D6 74 8C 4F F9 12 + 00080: 78 21 C7 C7 6C BD 79 63 56 AC F8 8E 69 6A 00 07 + + Section_1 + + K^1: + 00000: 9F 10 BB F1 3A 79 FB BD 4A 4C A8 64 C4 90 74 64 + 00010: 39 FE 50 6D 4B 86 9B 21 03 A3 B6 A4 79 28 3C 60 + + K^1_1: + 00000: 77 91 17 50 E0 D1 77 E5 9A 13 78 2B F1 89 08 D0 + + Plaintext block M_1: + 00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88 + + Input block M_1 (xor) C_0: + 00000: 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88 + + Output block C_1: + 00000: 0B A5 89 BF 55 C1 15 42 53 08 89 76 A0 FE 24 3E + + + + +Smyshlyaev Informational [Page 66] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + Plaintext block M_2: + 00000: 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A + + Input block M_2 (xor) C_1: + 00000: 0B B4 AB 8C 11 94 73 35 DB 91 23 CD 6C 10 DB 34 + + Output block C_2: + 00000: 1C 53 DD A3 6D DC E1 17 ED 1F 14 09 D8 6A F3 2C + + Section_2 + + K^2: + 00000: AB 6B 59 EE 92 49 05 B3 AB C7 A4 E3 69 65 76 C3 + 00010: 9D CC 66 42 0D FF 45 5B 21 F3 93 F0 D4 D6 6E 67 + + K^2_1: + 00000: BB 1B 06 0B 87 66 6D 08 7A 9D A7 49 55 C3 5B 48 + + Plaintext block M_3: + 00000: 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 + + Input block M_3 (xor) C_2: + 00000: 0D 71 EE E7 38 BA 96 9F 74 B5 AF C5 36 95 F9 2C + + Output block C_3: + 00000: 4E D4 BC A6 CE 6D 6D 16 F8 63 85 13 E0 48 59 75 + + Plaintext block M_4: + 00000: 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 + + Input block M_4 (xor) C_3: + 00000: 6C E7 F8 F3 A8 1A E5 8F 52 D8 49 FD 1F 42 59 64 + + Output block C_4: + 00000: B6 83 E3 96 FD 30 CD 46 79 C1 8B 24 03 82 1D 81 + + Section_3 + + K^3: + 00000: F2 EE 91 45 6B DC 3D E4 91 2C 87 C3 29 CF 31 A9 + 00010: 2F 20 2E 5A C4 9A 2A 65 31 33 D6 74 8C 4F F9 12 + + K^3_1: + 00000: 78 21 C7 C7 6C BD 79 63 56 AC F8 8E 69 6A 00 07 + + MSB1(K1) == 0 -> K2 = K1 << 1 + + + + + +Smyshlyaev Informational [Page 67] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + + K1: + 00000: 78 21 C7 C7 6C BD 79 63 56 AC F8 8E 69 6A 00 07 + + K2: + 00000: F0 43 8F 8E D9 7A F2 C6 AD 59 F1 1C D2 D4 00 0E + + Plaintext M_5: + 00000: 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 + + Using K1, padding is not required + + Input block M_5 (xor) C_4: + 00000: FD E6 71 37 E6 05 2D 8F 94 A1 9D 55 60 E8 0C A4 + + Output block C_5: + 00000: B3 AD B8 92 18 32 05 4C 09 21 E7 B8 08 CF A0 B8 + + Message authentication code T: + 00000: B3 AD B8 92 18 32 05 4C 09 21 E7 B8 08 CF A0 B8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Smyshlyaev Informational [Page 68] + +RFC 8645 Re-keying Mechanisms for Symmetric Keys August 2019 + + +Acknowledgments + + We thank Mihir Bellare, Scott Fluhrer, Dorothy Cooley, Yoav Nir, Jim + Schaad, Paul Hoffman, Dmitry Belyavsky, Yaron Sheffer, Alexey + Melnikov, and Spencer Dawkins for their useful comments. + +Contributors + + Russ Housley + Vigil Security, LLC + housley@vigilsec.com + + Evgeny Alekseev + CryptoPro + alekseev@cryptopro.ru + + Ekaterina Smyshlyaeva + CryptoPro + ess@cryptopro.ru + + Shay Gueron + University of Haifa, Israel + Intel Corporation, Israel Development Center, Israel + shay.gueron@gmail.com + + Daniel Fox Franke + Akamai Technologies + dfoxfranke@gmail.com + + Lilia Ahmetzyanova + CryptoPro + lah@cryptopro.ru + +Author's Address + + Stanislav Smyshlyaev (editor) + CryptoPro + 18, Suschevskiy val + Moscow 127018 + Russian Federation + + Phone: +7 (495) 995-48-20 + Email: svs@cryptopro.ru + + + + + + + + +Smyshlyaev Informational [Page 69] + -- cgit v1.2.3