idnits 2.17.1 draft-irtf-cfrg-re-keying-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 18 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 8, 2017) is 2421 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1394 == Missing Reference: '2t' is mentioned on line 1144, but not defined -- Looks like a reference, but probably isn't: '2' on line 1394 ** Obsolete normative reference: RFC 6347 (ref. 'DTLS') (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CFRG S. Smyshlyaev, Ed. 3 Internet-Draft CryptoPro 4 Intended status: Informational September 8, 2017 5 Expires: March 12, 2018 7 Re-keying Mechanisms for Symmetric Keys 8 draft-irtf-cfrg-re-keying-06 10 Abstract 12 A certain maximum amount of data can be safely encrypted when 13 encryption is performed under a single key. This amount is called 14 "key lifetime". This specification describes a variety of methods to 15 increase the lifetime of symmetric keys. It provides external and 16 internal re-keying mechanisms based on hash functions and on block 17 ciphers, that can be used with modes of operations such as CTR, GCM, 18 CCM, CBC, CFB and OMAC. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 12, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 56 3. Basic Terms and Definitions . . . . . . . . . . . . . . . . . 5 57 4. Choosing Constructions and Security Parameters . . . . . . . 6 58 5. External Re-keying Mechanisms . . . . . . . . . . . . . . . . 8 59 5.1. Methods of Key Lifetime Control . . . . . . . . . . . . . 12 60 5.2. Parallel Constructions . . . . . . . . . . . . . . . . . 12 61 5.2.1. Parallel Construction Based on a KDF on a Block 62 Cipher . . . . . . . . . . . . . . . . . . . . . . . 13 63 5.2.2. Parallel Construction Based on HKDF . . . . . . . . . 13 64 5.3. Serial Constructions . . . . . . . . . . . . . . . . . . 14 65 5.3.1. Serial Construction Based on a KDF on a Block Cipher 14 66 5.3.2. Serial Construction Based on HKDF . . . . . . . . . . 15 67 6. Internal Re-keying Mechanisms . . . . . . . . . . . . . . . . 15 68 6.1. Methods of Key Lifetime Control . . . . . . . . . . . . . 18 69 6.2. Constructions that Do Not Require Master Key . . . . . . 18 70 6.2.1. ACPKM Re-keying Mechanisms . . . . . . . . . . . . . 18 71 6.2.2. CTR-ACPKM Encryption Mode . . . . . . . . . . . . . . 20 72 6.2.3. GCM-ACPKM Authenticated Encryption Mode . . . . . . . 21 73 6.2.4. CCM-ACPKM Authenticated Encryption Mode . . . . . . . 24 74 6.3. Constructions that Require Master Key . . . . . . . . . . 25 75 6.3.1. ACPKM-Master Key Derivation from the Master Key . . . 26 76 6.3.2. CTR-ACPKM-Master Encryption Mode . . . . . . . . . . 28 77 6.3.3. GCM-ACPKM-Master Authenticated Encryption Mode . . . 30 78 6.3.4. CCM-ACPKM-Master Authenticated Encryption Mode . . . 32 79 6.3.5. CBC-ACPKM-Master Encryption Mode . . . . . . . . . . 33 80 6.3.6. CFB-ACPKM-Master Encryption Mode . . . . . . . . . . 35 81 6.3.7. OMAC-ACPKM-Master Authentication Mode . . . . . . . . 37 82 7. Joint Usage of External and Internal Re-keying . . . . . . . 38 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 39 86 9.2. Informative References . . . . . . . . . . . . . . . . . 40 87 Appendix A. Test examples . . . . . . . . . . . . . . . . . . . 40 88 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 45 89 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 45 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45 92 1. Introduction 94 A certain maximum amount of data can be safely encrypted when 95 encryption is performed under a single key. This amount is called 96 "key lifetime" and can be calculated from the following 97 considerations: 99 1. Methods based on the combinatorial properties of the used block 100 cipher mode of operation 102 These methods do not depend on the underlying block cipher. 103 Common modes restrictions derived from such methods are of 104 order 2^{n/2}. [Sweet32] is an example of attack that is 105 based on such methods. 107 2. Methods based on side-channel analysis issues 109 In most cases these methods do not depend on the used 110 encryption modes and weakly depend on the used block cipher 111 features. Limitations resulting from these considerations are 112 usually the most restrictive ones. [TEMPEST] is an example of 113 attack that is based on such methods. 115 3. Methods based on the properties of the used block cipher 117 The most common methods of this type are linear and 118 differential cryptanalysis [LDC]. In most cases these methods 119 do not depend on the used modes of operation. In case of 120 secure block ciphers, bounds resulting from such methods are 121 roughly the same as the natural bounds of 2^n, and are 122 dominated by the other bounds above. Therefore, they can be 123 excluded from the considerations here. 125 As a result, it is important to replace a key as soon as the total 126 size of the processed plaintext under that key reaches the lifetime 127 limitation. A specific value of the key lifetime should be 128 determined in accordance with some safety margin for protocol 129 security and the methods outlined above. 131 Suppose L is a key lifetime limitation in some protocol P. For 132 simplicity, assume that all messages have the same length m. Hence, 133 the number of messages q that can be processed with a single key K 134 should be such that m * q <= L. This can be depicted graphically as 135 a rectangle with sides m and q which is enclosed by area L (see 136 Figure 1). 138 +------------------------+ 139 | L | 140 | +--------m---------+ | 141 | |==================| | 142 | |==================| | 143 | q==================| | m * q <= L 144 | |==================| | 145 | |==================| | 146 | +------------------+ | 147 +------------------------+ 149 Figure 1: Graphic display of the key lifetime limitation 151 In practice, such amount of data that corresponds to limitation L may 152 not be enough. The simplest and obvious way in this situation is a 153 regular renegotiation of an initial key after processing this 154 threshold amount of data L. However, this reduces the total 155 performance, since it usually entails termination of application data 156 transmission, additional service messages, the use of random number 157 generator and many other additional calculations, including resource- 158 intensive public key cryptography. 160 This specification presents two approaches to extend the lifetime of 161 a key while avoiding renegotiation: external and internal re-keying. 163 External re-keying is performed by a protocol, and it is independent 164 of the underlying block cipher and the mode of operation. External 165 re-keying can use parallel and serial constructions. In the parallel 166 case, data processing keys K^1, K^2, ... are generated directly from 167 the initial key K independently of each other. In the serial case, 168 every data processing key depends on the state that is updated after 169 the generation of each new data processing key. 171 Internal re-keying is built into the mode, and it depends heavily on 172 the properties of the mode of operation and the block size. 174 The re-keying approaches extend the key lifetime for a single initial 175 key by providing the possibility to limit the leakages (via side 176 channels) and by improving combinatorial properties of the used block 177 cipher mode of operation. 179 In practical applications, re-keying can be useful for protocols that 180 need to operate in hostile environments or under restricted resource 181 conditions (e.g., that require lightweight cryptography, where 182 ciphers have a small block size, that imposes strict combinatorial 183 limitations). Moreover, mechanisms that use external and internal 184 re-keying may provide some properties of forward security and 185 potentially some protection against future attacks (by limiting the 186 number of plaintext-ciphertext pairs that an adversary can collect). 188 2. Conventions Used in This Document 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in [RFC2119]. 194 3. Basic Terms and Definitions 196 This document uses the following terms and definitions for the sets 197 and operations on the elements of these sets: 199 V* the set of all bit strings of a finite length (hereinafter 200 referred to as strings), including the empty string; 201 substrings and string components are enumerated from right to 202 left starting from one; 204 V_s the set of all bit strings of length s, where s is a non- 205 negative integer; 207 |X| the bit length of the bit string X; 209 A | B concatenation of strings A and B both belonging to V*, i.e., 210 a string in V_{|A|+|B|}, where the left substring in V_|A| is 211 equal to A, and the right substring in V_|B| is equal to B; 213 (xor) exclusive-or of two bit strings of the same length; 215 Z_{2^n} ring of residues modulo 2^n; 217 Int_s: V_s -> Z_{2^s} the transformation that maps a string a = 218 (a_s, ... , a_1), a in V_s, into the integer Int_s(a) = 219 2^{s-1} * a_s + ... + 2 * a_2 + a_1; 221 Vec_s: Z_{2^s} -> V_s the transformation inverse to the mapping 222 Int_s; 224 MSB_i: V_s -> V_i the transformation that maps the string a = (a_s, 225 ... , a_1) in V_s, into the string MSB_i(a) = (a_s, ... , 226 a_{s-i+1}) in V_i; 228 LSB_i: V_s -> V_i the transformation that maps the string a = (a_s, 229 ... , a_1) in V_s, into the string LSB_i(a) = (a_i, ... , 230 a_1) in V_i; 232 Inc_c: V_s -> V_s the transformation that maps the string a = (a_s, 233 ... , a_1) in V_s, into the string Inc_c(a) = MSB_{|a|- 234 c}(a) | Vec_c(Int_c(LSB_c(a)) + 1(mod 2^c)) in V_s; 236 a^s denotes the string in V_s that consists of s 'a' bits; 238 E_{K}: V_n -> V_n the block cipher permutation under the key K in 239 V_k; 241 ceil(x) the smallest integer that is greater than or equal to x; 243 k the bit-length of the K; k is assumed to be divisible by 8; 245 n the block size of the block cipher (in bits); n is assumed to 246 be divisible by 8; 248 b the number of data blocks in the plaintext P (b = 249 ceil(|P|/n)); 251 N the section size (the number of bits that are processed with 252 one section key before this key is transformed); 254 A plaintext message P and the corresponding ciphertext C are divided 255 into b = ceil(|P|/n) blocks, denoted P = P_1 | P_2 | ... | P_b and C 256 = C_1 | C_2 | ... | C_b, respectively. The first b-1 blocks P_i and 257 C_i are in V_n, for i = 1, 2, ... , b-1. The b-th block P_b, C_b may 258 be an incomplete block, i.e., in V_r, where r <= n if not otherwise 259 specified. 261 4. Choosing Constructions and Security Parameters 263 External re-keying is an approach assuming that a key is transformed 264 after encrypting a limited number of entire messages. External re- 265 keying method is chosen at the protocol level, regardless of the 266 underlying block cipher or the encryption mode. External re-keying 267 is recommended for protocols that process relatively short messages 268 or for protocols that have a way to divide a long message into 269 manageable pieces. Through external re-keying the number of messages 270 that can be securely processed with a single initial key K is 271 substantially increased without loss in message length. 273 External re-keying has the following advantages: 275 1. it increases the lifetime of an initial key by increasing the 276 number of messages processed with this key; 278 2. it has negligible affect on the performance, when the number of 279 messages processed under one initial key is sufficiently large; 281 3. it provides forward and backward security of data processing 282 keys. 284 However, the use of external re-keying has the following 285 disadvantage: in case of restrictive key lifetime limitations the 286 message sizes can become inconvenient due to impossibility of 287 processing sufficiently large messages, so it could be necessary to 288 perform additional fragmentation at the protocol level. E.g. if the 289 key lifetime L is 1 GB and the message length m = 3 GB, then this 290 message cannot be processed as a whole and it should be divided into 291 three fragments that will be processed separately. 293 Internal re-keying is an approach assuming that a key is transformed 294 during each separate message processing. Such procedures are 295 integrated into the base modes of operations, so every internal re- 296 keying mechanism is defined for the particular operation mode and the 297 block size of the used cipher. Internal re-keying is recommended for 298 protocols that process long messages: the size of each single message 299 can be substantially increased without loss in number of messages 300 that can be securely processed with a single initial key. 302 Internal re-keying has the following advantages: 304 1. it increases the lifetime of an initial key by increasing the 305 size of the messages processed with one initial key; 307 2. it has minimal impact on performance; 309 3. internal re-keying mechanisms without a master key does not 310 affect short messages transformation at all; 312 4. it is transparent (works like any mode of operation): does not 313 require changes of IV's and restarting MACing. 315 However, the use of internal re-keying has the following 316 disadvantages: 318 1. a specific method must not be chosen independently of a mode of 319 operation; 321 2. internal re-keying mechanisms without a master key do not provide 322 backward security of data processing keys. 324 Any block cipher modes of operations with internal re-keying can be 325 jointly used with any external re-keying mechanisms. Such joint 326 usage increases both the number of messages processed with one 327 initial key and their maximum possible size. 329 If the adversary has access to the data processing interface the use 330 of the same cryptographic primitives both for data processing and re- 331 keying transformation decreases the code size but can lead to some 332 possible vulnerabilities. This vulnerability can be eliminated by 333 using different primitives for data processing and re-keying, 334 however, in this case the security of the whole scheme cannot be 335 reduced to standard notions like PRF or PRP, so security estimations 336 become more difficult and unclear. 338 Summing up the above-mentioned issues briefly: 340 1. If a protocol assumes processing long records (e.g., [CMS]), 341 internal re-keying should be used. If a protocol assumes 342 processing a significant amount of ordered records, which can be 343 considered as a single data stream (e.g., [TLS], [SSH]), internal 344 re-keying may also be used. 346 2. For protocols which allow out-of-order delivery and lost records 347 (e.g., [DTLS], [ESP]) external re-keying should be used. If at 348 the same time records are long enough, internal re-keying should 349 be additionally used during each separate message processing. 351 For external re-keying: 353 1. If it is desirable to separate transformations used for data 354 processing and for key update, hash function based re-keying 355 should be used. 357 2. If parallel data processing is required, then parallel external 358 re-keying should be used. 360 For internal re-keying: 362 1. If the property of forward and backward security is desirable for 363 data processing keys and if additional key material can be easily 364 obtained for the data processing stage, internal re-keying with a 365 master key should be used. 367 5. External Re-keying Mechanisms 369 This section presents an approach to increase the initial key 370 lifetime by using a transformation of a data processing key (frame 371 key) after processing a limited number of entire messages (frame). 372 It provides external parallel and serial re-keying mechanisms (see 373 [AbBell]). These mechanisms use initial key K only for frame key 374 generation and never use it directly for data processing. Such 375 mechanisms operate outside of the base modes of operations and do not 376 change them at all, therefore they are called "external re-keying" 377 mechanisms in this document. 379 External re-keying mechanisms are recommended for usage in protocols 380 that process quite small messages, since the maximum gain in 381 increasing the initial key lifetime is achieved by increasing the 382 number of messages. 384 External re-keying increases the initial key lifetime through the 385 following approach. Suppose there is a protocol P with some mode of 386 operation (base encryption or authentication mode). Let L1 be a key 387 lifetime limitation induced by side-channel analysis methods (side- 388 channel limitation), let L2 be a key lifetime limitation induced by 389 methods based on the combinatorial properties of a used mode of 390 operation (combinatorial limitation) and let q1, q2 be the total 391 numbers of messages of length m, that can be safely processed with an 392 initial key K according to these limitations. 394 Let L = min(L1, L2), q = min (q1, q2), q * m <= L. As L1 limitation 395 is usually much stronger than L2 limitation (L1 < L2), the final key 396 lifetime restriction is equal to the most restrictive limitation L1. 397 Thus, as displayed in Figure 2, without re-keying only q1 (q1 * m <= 398 L1) messages can be safely processed. 400 <--------m-------> 401 +----------------+ ^ ^ 402 |================| | | 403 |================| | | 404 K-->|================| q1| 405 |================| | | 406 |==============L1| | | 407 +----------------+ v | 408 | | | 409 | | | 410 | | q2 411 | | | 412 | | | 413 | | | 414 | | | 415 | | | 416 | | | 417 | | | 418 | | | 419 | L2| | 420 +----------------+ v 422 Figure 2: Basic principles of message processing without external re-keying 424 Suppose that the safety margin for the protocol P is fixed and the 425 external re-keying approach is applied to the initial key K to 426 generate the sequence of frame keys. The frame keys are generated in 427 such a way that the leakage of a previous frame key does not have any 428 impact on the following one, so the side channel limitation L1 goes 429 off. Thus, the resulting key lifetime limitation of the initial key 430 K can be calculated on the basis of a new combinatorial limitation 431 L2'. It is proven (see [AbBell]) that the security of the mode of 432 operation that uses external re-keying leads to an increase when 433 compared to base mode without re-keying (thus, L2 < L2'). Hence, as 434 displayed in Figure 3, the resulting key lifetime limitation in case 435 of using external re-keying can be increased up to L2'. 437 <--------m-------> 438 K +----------------+ 439 | |================| 440 v |================| 441 K^1--> |================| 442 | |================| 443 | |==============L1| 444 | +----------------+ 445 | |================| 446 v |================| 447 K^2--> |================| 448 | |================| 449 | |==============L1| 450 | +----------------+ 451 | |================| 452 v |================| 453 ... | . . . | 454 | | 455 | | 456 | L2| 457 +----------------+ 458 | | 459 ... ... 460 | L2'| 461 +----------------+ 463 Figure 3: Basic principles of message processing with external re-keying 465 Note: the key transformation process is depicted in a simplified 466 form. A specific approach (parallel and serial) is described below. 468 Consider an example. Let the message size in a protocol P be equal 469 to 1 KB. Suppose L1 = 128 MB and L2 = 1 TB. Thus, if an external 470 re-keying mechanism is not used, the initial key K must be 471 renegotiated after processing 128 MB / 1 KB = 131072 messages. 473 If an external re-keying mechanism is used, the key lifetime 474 limitation L1 goes off. Hence the resulting key lifetime limitation 475 L2' can be set to more then 1 TB. Thus if an external re-keying 476 mechanism is used, more then 1 TB / 1 KB = 2^30 messages can be 477 processed before the initial key K is renegotiated. This is 8192 478 times greater than the number of messages that can be processed, when 479 external re-keying mechanism is not used. 481 5.1. Methods of Key Lifetime Control 483 Suppose L is an amount of data that can be safely processed with one 484 section key. For i in {1, 2, ... , t} the frame key K^i (see 485 Figure 4 and Figure 5) should be transformed after processing q_i 486 messages, where q_i can be calculated in accordance with one of the 487 following two approaches: 489 o Explicit approach: 490 q_i is such that |M^{i,1}| + ... + |M^{i,q_i}| <= L, |M^{i,1}| + 491 ... + |M^{i,q_i+1}| > L. 492 This approach allows to use the frame key K^i in almost optimal 493 way but it can be applied only in case when messages cannot be 494 lost or reordered (e.g., TLS records). 496 o Implicit approach: 497 q_i = L / m_max, i = 1, ... , t. 498 The amount of data processed with one frame key K^i is calculated 499 under the assumption that every message has the maximum length 500 m_max. Hence this amount can be considerably less than the key 501 lifetime limitation L. On the other hand, this approach can be 502 applied in case when messages may be lost or reordered (e.g., DTLS 503 records). 505 5.2. Parallel Constructions 507 The main idea behind external re-keying with a parallel construction 508 is presented in Figure 4: 510 Maximum message size = m_max. 511 _____________________________________________________________ 513 m_max 514 <----------------> 515 M^{1,1} |=== | 516 M^{1,2} |=============== | 517 +->K^1--> ... ... 518 | M^{1,q_1} |======== | 519 | 520 | 521 | M^{2,1} |================| 522 | M^{2,2} |===== | 523 K-----|->K^2--> ... ... 524 | M^{2,q_2} |========== | 525 | 526 ... 527 | M^{t,1} |============ | 528 | M^{t,2} |============= | 529 +->K^t--> ... ... 530 M^{t,q_t} |========== | 532 _____________________________________________________________ 534 Figure 4: External parallel re-keying mechanisms 536 The frame key K^i, i = 1, ... , t-1, is updated after processing a 537 certain amount of messages (see Section 5.1). 539 5.2.1. Parallel Construction Based on a KDF on a Block Cipher 541 ExtParallelC re-keying mechanism is based on the key derivation 542 function on a block cipher and is used to generate t frame keys as 543 follows: 545 K^1 | K^2 | ... | K^t = ExtParallelC(K, t * k) = MSB_{t * 546 k}(E_{K}(Vec_n(0)) | 547 E_{K}(Vec_n(1)) | ... | E_{K}(Vec_n(R - 1))), 549 where R = ceil(t * k/n). 551 5.2.2. Parallel Construction Based on HKDF 553 ExtParallelH re-keying mechanism is based on the key derivation 554 function HKDF-Expand, described in [RFC5869], and is used to generate 555 t frame keys as follows: 557 K^1 | K^2 | ... | K^t = ExtParallelH(K, t * k) = HKDF-Expand(K, 558 label, t * k), 560 where label is a string (may be a zero-length string) that is defined 561 by a specific protocol. 563 5.3. Serial Constructions 565 The main idea behind external re-keying with a serial construction is 566 presented in Figure 5: 568 Maximum message size = m_max. 569 _____________________________________________________________ 570 m_max 571 <----------------> 572 M^{1,1} |=== | 573 M^{1,2} |=============== | 574 K*_1 = K --->K^1--> ... ... 575 | M^{1,q_1} |======== | 576 | 577 | 578 | M^{2,1} |================| 579 v M^{2,2} |===== | 580 K*_2 ------->K^2--> ... ... 581 | M^{2,q_2} |========== | 582 | 583 ... 584 | M^{t,1} |============ | 585 v M^{t,2} |============= | 586 K*_t ------->K^t--> ... ... 587 M^{t,q_t} |========== | 589 _____________________________________________________________ 591 Figure 5: External serial re-keying mechanisms 593 The frame key K^i, i = 1, ... , t - 1, is updated after processing a 594 certain amount of messages (see Section 5.1). 596 5.3.1. Serial Construction Based on a KDF on a Block Cipher 598 The frame key K^i is calculated using ExtSerialC transformation as 599 follows: 601 K^i = ExtSerialC(K, i) = 602 MSB_k(E_{K*_i}(Vec_n(0)) |E_{K*_i}(Vec_n(1)) | ... | 603 E_{K*_i}(Vec_n(J - 1))), 605 where J = ceil(k / n), i = 1, ... , t, K*_i is calculated as follows: 607 K*_1 = K, 609 K*_{j+1} = MSB_k(E_{K*_j}(Vec_n(J)) | E_{K*_j}(Vec_n(J + 1)) | 610 ... | 611 E_{K*_j}(Vec_n(2 * J - 1))), 613 where j = 1, ... , t - 1. 615 5.3.2. Serial Construction Based on HKDF 617 The frame key K^i is calculated using ExtSerialH transformation as 618 follows: 620 K^i = ExtSerialH(K, i) = HKDF-Expand(K*_i, label1, k), 622 where i = 1, ... , t, HKDF-Expand is the HMAC-based key derivation 623 function, described in [RFC5869], K*_i is calculated as follows: 625 K*_1 = K, 627 K*_{j+1} = HKDF-Expand(K*_j, label2, k), where j = 1, ... , t - 1, 629 where label1 and label2 are different strings from V* that are 630 defined by a specific protocol (see, for example, TLS 1.3 updating 631 traffic keys algorithm [TLSDraft]). 633 6. Internal Re-keying Mechanisms 635 This section presents an approach to increase the key lifetime by 636 using a transformation of a data processing key (section key) during 637 each separate message processing. Each message is processed starting 638 with the same key (the first section key) and each section key is 639 updated after processing N bits of message (section). 641 This section provides internal re-keying mechanisms called ACPKM 642 (Advanced Cryptographic Prolongation of Key Material) and ACPKM- 643 Master that do not use a master key and use a master key 644 respectively. Such mechanisms are integrated into the base modes of 645 operation and actually form new modes of operation, therefore they 646 are called "internal re-keying" mechanisms in this document. 648 Internal re-keying mechanisms are recommended to be used in protocols 649 that process large single messages (e.g., CMS messages), since the 650 maximum gain in increasing the key lifetime is achieved by increasing 651 the length of a message, while it provides almost no increase in the 652 number of messages that can be processed with one initial key. 654 Internal re-keying increases the key lifetime through the following 655 approach. Suppose protocol P uses some base mode of operation. Let 656 L1 and L2 be a side channel and combinatorial limitations 657 respectively and for some fixed amount of messages q let m1, m2 be 658 the lengths of messages, that can be safely processed with a single 659 initial key K according to these limitations. 661 Thus, by analogy with the Section 5 without re-keying the final key 662 lifetime restriction, as displayed in Figure 6, is equal to L1 and 663 only q messages of the length m1 can be safely processed. 665 K 666 | 667 v 668 ^ +----------------+------------------------------------+ 669 | |==============L1| L2| 670 | |================| | 671 q |================| | 672 | |================| | 673 | |================| | 674 v +----------------+------------------------------------+ 675 <-------m1-------> 676 <----------------------------m2-----------------------> 678 Figure 6: Basic principles of message processing without internal re-keying 680 Suppose that the safety margin for the protocol P is fixed and 681 internal re-keying approach is applied to the base mode of operation. 682 Suppose further that every message is processed with a section key, 683 which is transformed after processing N bits of data, where N is a 684 parameter. If q * N does not exceed L1 then the side channel 685 limitation L1 goes off and the resulting key lifetime limitation of 686 the initial key K can be calculated on the basis of a new 687 combinatorial limitation L2'. The security of the mode of operation 688 that uses internal re-keying increases when compared to base mode of 689 operation without re-keying (thus, L2 < L2'). Hence, as displayed in 690 Figure 7, the resulting key lifetime limitation in case of using 691 internal re-keying can be increased up to L2'. 693 K-----> K^1-------------> K^2 -----------> . . . 694 | | 695 v v 696 ^ +----------------+----------------+-------------------+--...--+ 697 | |==============L1|==============L1|====== L2| L2'| 698 | |================|================|====== | | 699 q |================|================|====== . . . | | 700 | |================|================|====== | | 701 | |================|================|====== | | 702 v +----------------+----------------+-------------------+--...--+ 703 <-------N--------> 705 Figure 7: Basic principles of message processing with internal re-keying 707 Note: the key transformation process is depicted in a simplified 708 form. A specific approach (ACPKM and ACPKM-Master re-keying 709 mechanisms) is described below. 711 Since the performance of encryption can slightly decrease for rather 712 small values of N, the parameter N should be selected for a 713 particular protocol as maximum possible to provide necessary key 714 lifetime for the security models that are considered. 716 Consider an example. Suppose L1 = 128 MB and L2 = 10 TB. Let the 717 message size in the protocol be large/unlimited (may exhaust the 718 whole key lifetime L2). The most restrictive resulting key lifetime 719 limitation is equal to 128 MB. 721 Thus, there is a need to put a limit on the maximum message size 722 m_max. For example, if m_max = 32 MB, it may happen that the 723 renegotiation of initial key K would be required after processing 724 only four messages. 726 If an internal re-keying mechanism with section size N = 1 MB is 727 used, more than L1 / N = 128 MB / 1 MB = 128 messages can be 728 processed before the renegotiation of initial key K (instead of 4 729 messages in case when an internal re-keying mechanism is not used). 730 Note that only one section of each message is processed with the 731 section key K^i, and, consequently, the key lifetime limitation L1 732 goes off. Hence the resulting key lifetime limitation L2' can be set 733 to more then 10 TB (in the case when a single large message is 734 processed using the initial key K). 736 6.1. Methods of Key Lifetime Control 738 Suppose L is an amount of data that can be safely processed with one 739 section key, N is a section size (fixed parameter). Suppose M^{i}_1 740 is the first section of message M^{i}, i = 1, ... , q (see Figure 8 741 and Figure 9), then the parameter q can be calculated in accordance 742 with one of the following two approaches: 744 o Explicit approach: 745 q_i is such that |M^{1}_1| + ... + |M^{q}_1| <= L, |M^{1}_1| + ... 746 + |M^{q+1}_1| > L 747 This approach allows to use the section key K^i in an almost 748 optimal way but it can be applied only in case when messages 749 cannot be lost or reordered (e.g., TLS records). 751 o Implicit approach: 752 q = L / N. 753 The amount of data processed with one section key K^i is 754 calculated under the assumption that the length of every message 755 is equal or greater than section size N and so it can be 756 considerably less than the key lifetime limitation L. On the 757 other hand, this approach can be applied in case when messages may 758 be lost or reordered (e.g., DTLS records). 760 6.2. Constructions that Do Not Require Master Key 762 This section describes the block cipher modes that use the ACPKM re- 763 keying mechanism, which does not use a master key: an initial key is 764 used directly for the encryption of the data. 766 6.2.1. ACPKM Re-keying Mechanisms 768 This section defines periodical key transformation without a master 769 key, which is called ACPKM re-keying mechanism. This mechanism can 770 be applied to one of the basic encryption modes (CTR and GCM block 771 cipher modes) for getting an extension of this encryption mode that 772 uses periodical key transformation without a master key. This 773 extension can be considered as a new encryption mode. 775 An additional parameter that defines functioning of base encryption 776 modes with the ACPKM re-keying mechanism is the section size N. The 777 value of N is measured in bits and is fixed within a specific 778 protocol based on the requirements of the system capacity and the key 779 lifetime. The section size N MUST be divisible by the block size n. 781 The main idea behind internal re-keying without a master key is 782 presented in Figure 8: 784 Section size = const = N, 785 maximum message size = m_max. 786 ____________________________________________________________________ 788 ACPKM ACPKM ACPKM 789 K^1 = K ---> K^2 ---...-> K^{l_max-1} ----> K^{l_max} 790 | | | | 791 | | | | 792 v v v v 793 M^{1} |==========|==========| ... |==========|=======: | 794 M^{2} |==========|==========| ... |=== | : | 795 . . . . . . : 796 : : : : : : : 797 M^{q} |==========|==========| ... |==========|===== : | 798 section : 799 <----------> m_max 800 N bit 801 ___________________________________________________________________ 802 l_max = ceil(m_max/N). 804 Figure 8: Internal re-keying without a master key 806 During the processing of the input message M with the length m in 807 some encryption mode that uses ACPKM key transformation of the 808 initial key K the message is divided into l = ceil(m / N) sections 809 (denoted as M = M_1 | M_2 | ... | M_l, where M_i is in V_N for i in 810 {1, 2, ... , l - 1} and M_l is in V_r, r <= N). The first section of 811 each message is processed with the section key K^1 = K. To process 812 the (i + 1)-th section of each message the section key K^{i+1} is 813 calculated using ACPKM transformation as follows: 815 K^{i+1} = ACPKM(K^i) = MSB_k(E_{K^i}(D_1) | ... | E_{K^i}(D_J)), 817 where J = ceil(k/n) and D_1, D_2, ... , D_J are in V_n and are 818 calculated as follows: 820 D_1 | D_2 | ... | D_J = MSB_{J * n}(D), 822 where D is the following constant in V_{1024}: 824 D = ( 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 825 | 88 | 89 | 8a | 8b | 8c | 8d | 8e | 8f 826 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 827 | 98 | 99 | 9a | 9b | 9c | 9d | 9e | 9f 828 | a0 | a1 | a2 | a3 | a4 | a5 | a6 | a7 829 | a8 | a9 | aa | ab | ac | ad | ae | af 830 | b0 | b1 | b2 | b3 | b4 | b5 | b6 | b7 831 | b8 | b9 | ba | bb | bc | bd | be | bf 832 | c0 | c1 | c2 | c3 | c4 | c5 | c6 | c7 833 | c8 | c9 | ca | cb | cc | cd | ce | cf 834 | d0 | d1 | d2 | d3 | d4 | d5 | d6 | d7 835 | d8 | d9 | da | db | dc | dd | de | df 836 | e0 | e1 | e2 | e3 | e4 | e5 | e6 | e7 837 | e8 | e9 | ea | eb | ec | ed | ee | ef 838 | f0 | f1 | f2 | f3 | f4 | f5 | f6 | f7 839 | f8 | f9 | fa | fb | fc | fd | fe | ff ) 841 N o t e : The constant D is such that D_1, ... , D_J are pairwise 842 different for any allowed n and k values. 844 N o t e : The constant D is such that the highest bit of its each 845 octet is equal to 1. This condition is important, as in conjunction 846 with message length limitation it allows to prevent collisions of 847 block cipher permutation inputs in cases of key transformation and 848 message processing. 850 6.2.2. CTR-ACPKM Encryption Mode 852 This section defines a CTR-ACPKM encryption mode that uses internal 853 ACPKM re-keying mechanism for the periodical key transformation. 855 The CTR-ACPKM mode can be considered as the basic encryption mode CTR 856 (see [MODES]) extended by the ACPKM re-keying mechanism. 858 The CTR-ACPKM encryption mode can be used with the following 859 parameters: 861 o 64 <= n <= 512; 863 o 128 <= k <= 512; 865 o the number of bits c in a specific part of the block to be 866 incremented is such that 32 <= c <= 3 / 4 n, c is a multiple of 8; 868 o the maximum message size m_max = n * 2^{c-1}. 870 The CTR-ACPKM mode encryption and decryption procedures are defined 871 as follows: 873 +----------------------------------------------------------------+ 874 | CTR-ACPKM-Encrypt(N, K, ICN, P) | 875 |----------------------------------------------------------------| 876 | Input: | 877 | - section size N, | 878 | - initial key K, | 879 | - initial counter nonce ICN in V_{n-c}, | 880 | - plaintext P = P_1 | ... | P_b, |P| <= m_max. | 881 | Output: | 882 | - ciphertext C. | 883 |----------------------------------------------------------------| 884 | 1. CTR_1 = ICN | 0^c | 885 | 2. For j = 2, 3, ... , b do | 886 | CTR_{j} = Inc_c(CTR_{j-1}) | 887 | 3. K^1 = K | 888 | 4. For i = 2, 3, ... , ceil(|P| / N) | 889 | K^i = ACPKM(K^{i-1}) | 890 | 5. For j = 1, 2, ... , b do | 891 | i = ceil(j * n / N), | 892 | G_j = E_{K^i}(CTR_j) | 893 | 6. C = P (xor) MSB_{|P|}(G_1 | ... | G_b) | 894 | 7. Return C | 895 +----------------------------------------------------------------+ 897 +----------------------------------------------------------------+ 898 | CTR-ACPKM-Decrypt(N, K, ICN, C) | 899 |----------------------------------------------------------------| 900 | Input: | 901 | - section size N, | 902 | - initial key K, | 903 | - initial counter nonce ICN in V_{n-c}, | 904 | - ciphertext C = C_1 | ... | C_b, |C| <= m_max. | 905 | Output: | 906 | - plaintext P. | 907 |----------------------------------------------------------------| 908 | 1. P = CTR-ACPKM-Encrypt(N, K, ICN, C) | 909 | 2. Return P | 910 +----------------------------------------------------------------+ 912 The initial counter nonce ICN value for each message that is 913 encrypted under the given initial key K must be chosen in a unique 914 manner. 916 6.2.3. GCM-ACPKM Authenticated Encryption Mode 918 This section defines GCM-ACPKM authenticated encryption mode that 919 uses internal ACPKM re-keying mechanism for the periodical key 920 transformation. 922 The GCM-ACPKM mode can be considered as the basic authenticated 923 encryption mode GCM (see [GCM]) extended by the ACPKM re-keying 924 mechanism. 926 The GCM-ACPKM authenticated encryption mode can be used with the 927 following parameters: 929 o n in {128, 256}; 931 o 128 <= k <= 512; 933 o the number of bits c in a specific part of the block to be 934 incremented is such that 1 / 4 n <= c <= 1 / 2 n, c is a multiple 935 of 8; 937 o authentication tag length t; 939 o the maximum message size m_max = min{n * (2^{c-1} - 2), 2^{n/2} - 940 1}. 942 The GCM-ACPKM mode encryption and decryption procedures are defined 943 as follows: 945 +-------------------------------------------------------------------+ 946 | GHASH(X, H) | 947 |-------------------------------------------------------------------| 948 | Input: | 949 | - bit string X = X_1 | ... | X_m, X_1, ... , X_m in V_n. | 950 | Output: | 951 | - block GHASH(X, H) in V_n. | 952 |-------------------------------------------------------------------| 953 | 1. Y_0 = 0^n | 954 | 2. For i = 1, ... , m do | 955 | Y_i = (Y_{i-1} (xor) X_i) * H | 956 | 3. Return Y_m | 957 +-------------------------------------------------------------------+ 959 +-------------------------------------------------------------------+ 960 | GCTR(N, K, ICB, X) | 961 |-------------------------------------------------------------------| 962 | Input: | 963 | - section size N, | 964 | - initial key K, | 965 | - initial counter block ICB, | 966 | - X = X_1 | ... | X_b. | 967 | Output: | 968 | - Y in V_{|X|}. | 969 |-------------------------------------------------------------------| 970 | 1. If X in V_0 then return Y, where Y in V_0 | 971 | 2. GCTR_1 = ICB | 972 | 3. For i = 2, ... , b do | 973 | GCTR_i = Inc_c(GCTR_{i-1}) | 974 | 4. K^1 = K | 975 | 5. For j = 2, ... , ceil(|X| / N) | 976 | K^j = ACPKM(K^{j-1}) | 977 | 6. For i = 1, ... , b do | 978 | j = ceil(i * n / N), | 979 | G_i = E_{K_j}(GCTR_i) | 980 | 7. Y = X (xor) MSB_{|X|}(G_1 | ... | G_b) | 981 | 8. Return Y | 982 +-------------------------------------------------------------------+ 984 +-------------------------------------------------------------------+ 985 | GCM-ACPKM-Encrypt(N, K, ICN, P, A) | 986 |-------------------------------------------------------------------| 987 | Input: | 988 | - section size N, | 989 | - initial key K, | 990 | - initial counter nonce ICN in V_{n-c}, | 991 | - plaintext P = P_1 | ... | P_b, |P| <= m_max, | 992 | - additional authenticated data A. | 993 | Output: | 994 | - ciphertext C, | 995 | - authentication tag T. | 996 |-------------------------------------------------------------------| 997 | 1. H = E_{K}(0^n) | 998 | 2. ICB_0 = ICN | 0^{c-1} | 1 | 999 | 3. C = GCTR(N, K, Inc_c(ICB_0), P) | 1000 | 4. u = n * ceil(|C| / n) - |C| | 1001 | v = n * ceil(|A| / n) - |A| | 1002 | 5. S = GHASH(A | 0^v | C | 0^u | Vec_{n/2}(|A|) | | 1003 | | Vec_{n/2}(|C|), H) | 1004 | 6. T = MSB_t(E_{K}(ICB_0) (xor) S) | 1005 | 7. Return C | T | 1006 +-------------------------------------------------------------------+ 1008 +-------------------------------------------------------------------+ 1009 | GCM-ACPKM-Decrypt(N, K, ICN, A, C, T) | 1010 |-------------------------------------------------------------------| 1011 | Input: | 1012 | - section size N, | 1013 | - initial key K, | 1014 | - initial counter block ICN, | 1015 | - additional authenticated data A, | 1016 | - ciphertext C = C_1 | ... | C_b, |C| <= m_max, | 1017 | - authentication tag T. | 1018 | Output: | 1019 | - plaintext P or FAIL. | 1020 |-------------------------------------------------------------------| 1021 | 1. H = E_{K}(0^n) | 1022 | 2. ICB_0 = ICN | 0^{c-1} | 1 | 1023 | 3. P = GCTR(N, K, Inc_c(ICB_0), C) | 1024 | 4. u = n * ceil(|C| / n) - |C| | 1025 | v = n * ceil(|A| / n) - |A| | 1026 | 5. S = GHASH(A | 0^v | C | 0^u | Vec_{n/2}(|A|) | | 1027 | | Vec_{n/2}(|C|), H) | 1028 | 6. T' = MSB_t(E_{K}(ICB_0) (xor) S) | 1029 | 7. If T = T' then return P; else return FAIL | 1030 +-------------------------------------------------------------------+ 1032 The * operation on (pairs of) the 2^n possible blocks corresponds to 1033 the multiplication operation for the binary Galois (finite) field of 1034 2^n elements defined by the polynomial f as follows (by analogy with 1035 [GCM]): 1037 n = 128: f = a^128 + a^7 + a^2 + a^1 + 1, 1039 n = 256: f = a^256 + a^10 + a^5 + a^2 + 1. 1041 The initial vector IV value for each message that is encrypted under 1042 the given initial key K must be chosen in a unique manner. 1044 The key for computing values E_{K}(ICB_0) and H is not updated and is 1045 equal to the initial key K. 1047 6.2.4. CCM-ACPKM Authenticated Encryption Mode 1049 This section defines a CCM-ACPKM authenticated encryption block 1050 cipher mode that uses internal ACPKM re-keying mechanism for the 1051 periodical key transformation. 1053 The CCM-ACPKM mode can be considered as the basic authenticated 1054 encryption mode CCM (see [RFC3610]) extended by the ACPKM re-keying 1055 mechanism. 1057 Since [RFC3610] defines CCM authenticated encryption mode only for 1058 128-bit block size, the CCM-ACPKM authenticated encryption mode can 1059 be used only with the parameter n = 128. However, the CCM-ACPKM 1060 design principles can easily be applied to other block sizes, but 1061 these modes will require their own specifications. 1063 The CCM-ACPKM authenticated encryption mode differs from CCM mode in 1064 keys that are used for encryption during CBC-MAC calculation (see 1065 Section 2.2 of [RFC3610]) and for key stream blocks generation (see 1066 Section 2.3 of [RFC3610]). 1068 The CCM mode uses the same key K for block cipher encryption 1069 operations, while the CCM-ACPKM mode uses the section keys K^1, K^2, 1070 ... , which are generated from the initial key K as follows: 1072 K^1 = K, 1073 K^{i+1} = ACPKM(K^i). 1075 The section keys K^1, K^2, ... are used as follows. 1077 CBC-MAC calculation: under a separate message processing during the 1078 first N / n block cipher encryption operations the section key K^1 is 1079 used, the section key K^2 is used for the next N / n block cipher 1080 encryption operations and so on. For example, if N = 2n, then CBC- 1081 MAC calculation for a sequence of t blocks B_0, B_1, ... , B_t is as 1082 follows: 1084 X_1 = E(K^1, B_0), 1085 X_2 = E(K^1, X_1 XOR B_1), 1086 X_3 = E(K^2, X_2 XOR B_2), 1087 X_4 = E(K^2, X_3 XOR B_3), 1088 X_5 = E(K^3, X_4 XOR B_4), 1089 ... 1090 T = first-M-bytes(X_{t+1}). 1092 The key stream blocks generation: under a separate message processing 1093 during the first N / n block cipher encryption operations the section 1094 key K^1 is used, the section key K^2 is used for the next N / n block 1095 cipher encryption operations and so on. For example, if N = 2n, then 1096 the key stream blocks are generated as follows: 1098 S_0 = E(K^1, A_0), 1099 S_1 = E(K^1, A_1), 1100 S_2 = E(K^2, A_2), 1101 S_3 = E(K^2, A_3), 1102 S_4 = E(K^3, A_4), 1103 ... 1105 6.3. Constructions that Require Master Key 1107 This section describes the block cipher modes that use the ACPKM- 1108 Master re-keying mechanism, which use the initial key K as a master 1109 key, so K is never used directly for data processing but is used for 1110 key derivation. 1112 6.3.1. ACPKM-Master Key Derivation from the Master Key 1114 This section defines periodical key transformation with a master key, 1115 which is called ACPKM-Master re-keying mechanism. This mechanism can 1116 be applied to one of the basic modes of operation (CTR, GCM, CBC, 1117 CFB, OMAC modes) for getting an extension that uses periodical key 1118 transformation with a master key. This extension can be considered 1119 as a new mode of operation. 1121 Additional parameters that define the functioning of modes of 1122 operation that use the ACPKM-Master re-keying mechanism are the 1123 section size N, the change frequency T* of the master keys K*_1, 1124 K*_2, ... (see Figure 9) and the size d of the section key material. 1125 The values of N and T* are measured in bits and are fixed within a 1126 specific protocol, based on the requirements of the system capacity 1127 and the key lifetime. The section size N MUST also be divisible by 1128 the block size n. The master key frequency T* MUST be divisible by d 1129 and by n. 1131 The main idea behind internal re-keying with a master key is 1132 presented in Figure 9: 1134 Master key frequency T*, 1135 section size N, 1136 maximum message size = m_max. 1137 __________________________________________________________________________________ 1139 ACPKM ACPKM 1140 K*_1 = K--------------> K*_2 ---------...---------> K*_l_max 1141 ___|___ ___|___ ___|___ 1142 | | | | | | 1143 v ... v v ... v v ... v 1144 K[1] K[t] K[t+1] K[2t] K[(l_max-1)t+1] K[l_max*t] 1145 | | | | | | 1146 | | | | | | 1147 v v v v v v 1148 M^{1}||========|...|========||========|...|========||...||========|...|== : || 1149 M^{2}||========|...|========||========|...|========||...||========|...|======: || 1150 ... || | | || | | || || | | : || 1151 M^{q}||========|...|========||==== |...| ||...|| |...| : || 1152 section : 1153 <--------> : 1154 N bit m_max 1155 __________________________________________________________________________________ 1156 |K[i]| = d, 1157 t = T* / d, 1158 l_max = ceil(m_max / (N * t)). 1160 Figure 9: Internal re-keying with a master key 1162 During the processing of the input message M with the length m in 1163 some mode of operation that uses ACPKM-Master key transformation with 1164 the initial key K and the master key frequency T* the message M is 1165 divided into l = ceil(m / N) sections (denoted as M = M_1 | M_2 | 1166 ... | M_l, where M_i is in V_N for i in {1, 2, ... , l - 1} and M_l 1167 is in V_r, r <= N). The j-th section of each message is processed 1168 with the key material K[j], j in {1, ... , l}, |K[j]| = d, that is 1169 calculated with the ACPKM-Master algorithm as follows: 1171 K[1] | ... | K[l] = ACPKM-Master(T*, K, d, l) = CTR-ACPKM-Encrypt 1172 (T*, K, 1^{n/2}, 0^{d*l}). 1174 Note: the parameters d and l MUST be such that d * l <= n * 1175 2^{n/2-1}. 1177 6.3.2. CTR-ACPKM-Master Encryption Mode 1179 This section defines a CTR-ACPKM-Master encryption mode that uses 1180 internal ACPKM-Master re-keying mechanism for the periodical key 1181 transformation. 1183 The CTR-ACPKM-Master encryption mode can be considered as the basic 1184 encryption mode CTR (see [MODES]) extended by the ACPKM-Master re- 1185 keying mechanism. 1187 The CTR-ACPKM-Master encryption mode can be used with the following 1188 parameters: 1190 o 64 <= n <= 512; 1192 o 128 <= k <= 512; 1194 o the number of bits c in a specific part of the block to be 1195 incremented is such that 32 <= c <= 3 / 4 n, c is a multiple of 8; 1197 o the maximum message size m_max = min{N * (n * 2^{n/2-1} / k), n * 1198 2^c}. 1200 The key material K[j] that is used for one section processing is 1201 equal to K^j, |K^j| = k bits. 1203 The CTR-ACPKM-Master mode encryption and decryption procedures are 1204 defined as follows: 1206 +----------------------------------------------------------------+ 1207 | CTR-ACPKM-Master-Encrypt(N, K, T*, ICN, P) | 1208 |----------------------------------------------------------------| 1209 | Input: | 1210 | - section size N, | 1211 | - initial key K, | 1212 | - master key frequency T*, | 1213 | - initial counter nonce ICN in V_{n-c}, | 1214 | - plaintext P = P_1 | ... | P_b, |P| <= m_max. | 1215 | Output: | 1216 | - ciphertext C. | 1217 |----------------------------------------------------------------| 1218 | 1. CTR_1 = ICN | 0^c | 1219 | 2. For j = 2, 3, ... , b do | 1220 | CTR_{j} = Inc_c(CTR_{j-1}) | 1221 | 3. l = ceil(|P| / N) | 1222 | 4. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) | 1223 | 5. For j = 1, 2, ... , b do | 1224 | i = ceil(j * n / N), | 1225 | G_j = E_{K^i}(CTR_j) | 1226 | 6. C = P (xor) MSB_{|P|}(G_1 | ... |G_b) | 1227 | 7. Return C | 1228 |----------------------------------------------------------------+ 1230 +----------------------------------------------------------------+ 1231 | CTR-ACPKM-Master-Decrypt(N, K, T*, ICN, C) | 1232 |----------------------------------------------------------------| 1233 | Input: | 1234 | - section size N, | 1235 | - initial key K, | 1236 | - master key frequency T*, | 1237 | - initial counter nonce ICN in V_{n-c}, | 1238 | - ciphertext C = C_1 | ... | C_b, |C| <= m_max. | 1239 | Output: | 1240 | - plaintext P. | 1241 |----------------------------------------------------------------| 1242 | 1. P = CTR-ACPKM-Master-Encrypt(N, K, T*, ICN, C) | 1243 | 1. Return P | 1244 +----------------------------------------------------------------+ 1246 The initial counter nonce ICN value for each message that is 1247 encrypted under the given initial key must be chosen in a unique 1248 manner. 1250 6.3.3. GCM-ACPKM-Master Authenticated Encryption Mode 1252 This section defines a GCM-ACPKM-Master authenticated encryption mode 1253 that uses internal ACPKM-Master re-keying mechanism for the 1254 periodical key transformation. 1256 The GCM-ACPKM-Master authenticated encryption mode can be considered 1257 as the basic authenticated encryption mode GCM (see [GCM]) extended 1258 by the ACPKM-Master re-keying mechanism. 1260 The GCM-ACPKM-Master authenticated encryption mode can be used with 1261 the following parameters: 1263 o n in {128, 256}; 1265 o 128 <= k <= 512; 1267 o the number of bits c in a specific part of the block to be 1268 incremented is such that 1 / 4 n <= c <= 1 / 2 n, c is a multiple 1269 of 8; 1271 o authentication tag length t; 1273 o the maximum message size m_max = min{N * ( n * 2^{n/2-1} / k), n * 1274 (2^c - 2), 2^{n/2} - 1}. 1276 The key material K[j] that is used for the j-th section processing is 1277 equal to K^j, |K^j| = k bits. 1279 The GCM-ACPKM-Master mode encryption and decryption procedures are 1280 defined as follows: 1282 +-------------------------------------------------------------------+ 1283 | GHASH(X, H) | 1284 |-------------------------------------------------------------------| 1285 | Input: | 1286 | - bit string X = X_1 | ... | X_m, X_i in V_n for i in {1, ... ,m}| 1287 | Output: | 1288 | - block GHASH(X, H) in V_n | 1289 |-------------------------------------------------------------------| 1290 | 1. Y_0 = 0^n | 1291 | 2. For i = 1, ... , m do | 1292 | Y_i = (Y_{i-1} (xor) X_i) * H | 1293 | 3. Return Y_m | 1294 +-------------------------------------------------------------------+ 1296 +-------------------------------------------------------------------+ 1297 | GCTR(N, K, T*, ICB, X) | 1298 |-------------------------------------------------------------------| 1299 | Input: | 1300 | - section size N, | 1301 | - initial key K, | 1302 | - master key frequency T*, | 1303 | - initial counter block ICB, | 1304 | - X = X_1 | ... | X_b. | 1305 | Output: | 1306 | - Y in V_{|X|}. | 1307 |-------------------------------------------------------------------| 1308 | 1. If X in V_0 then return Y, where Y in V_0 | 1309 | 2. GCTR_1 = ICB | 1310 | 3. For i = 2, ... , b do | 1311 | GCTR_i = Inc_c(GCTR_{i-1}) | 1312 | 4. l = ceil(|X| / N) | 1313 | 5. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) | 1314 | 6. For j = 1, ... , b do | 1315 | i = ceil(j * n / N), | 1316 | G_j = E_{K^i}(GCTR_j) | 1317 | 7. Y = X (xor) MSB_{|X|}(G_1 | ... | G_b) | 1318 | 8. Return Y | 1319 +-------------------------------------------------------------------+ 1321 +-------------------------------------------------------------------+ 1322 | GCM-ACPKM-Master-Encrypt(N, K, T*, ICN, P, A) | 1323 |-------------------------------------------------------------------| 1324 | Input: | 1325 | - section size N, | 1326 | - initial key K, | 1327 | - master key frequency T*, | 1328 | - initial counter nonce ICN in V_{n-c}, | 1329 | - plaintext P = P_1 | ... | P_b, |P| <= m_max. | 1330 | - additional authenticated data A. | 1331 | Output: | 1332 | - ciphertext C, | 1333 | - authentication tag T. | 1334 |-------------------------------------------------------------------| 1335 | 1. K^1 = ACPKM-Master(T*, K, k, 1) | 1336 | 2. H = E_{K^1}(0^n) | 1337 | 3. ICB_0 = ICN | 0^{c-1} | 1 | 1338 | 4. C = GCTR(N, K, T*, Inc_c(ICB_0), P) | 1339 | 5. u = n * ceil(|C| / n) - |C| | 1340 | v = n * ceil(|A| / n) - |A| | 1341 | 6. S = GHASH(A | 0^v | C | 0^u | Vec_{n/2}(|A|) | | 1342 | | Vec_{n/2}(|C|), H) | 1343 | 7. T = MSB_t(E_{K^1}(ICB_0) (xor) S) | 1344 | 8. Return C | T | 1345 +-------------------------------------------------------------------+ 1347 +-------------------------------------------------------------------+ 1348 | GCM-ACPKM-Master-Decrypt(N, K, T*, ICN, A, C, T) | 1349 |-------------------------------------------------------------------| 1350 | Input: | 1351 | - section size N, | 1352 | - initial key K, | 1353 | - master key frequency T*, | 1354 | - initial counter nonce ICN in V_{n-c}, | 1355 | - additional authenticated data A. | 1356 | - ciphertext C = C_1 | ... | C_b, |C| <= m_max, | 1357 | - authentication tag T. | 1358 | Output: | 1359 | - plaintext P or FAIL. | 1360 |-------------------------------------------------------------------| 1361 | 1. K^1 = ACPKM-Master(T*, K, k, 1) | 1362 | 2. H = E_{K^1}(0^n) | 1363 | 3. ICB_0 = ICN | 0^{c-1} | 1 | 1364 | 4. P = GCTR(N, K, T*, Inc_c(ICB_0), C) | 1365 | 5. u = n * ceil(|C| / n) - |C| | 1366 | v = n * ceil(|A| / n) - |A| | 1367 | 6. S = GHASH(A | 0^v | C | 0^u | Vec_{n/2}(|A|) | | 1368 | | Vec_{n/2}(|C|), H) | 1369 | 7. T' = MSB_t(E_{K^1}(ICB_0) (xor) S) | 1370 | 8. IF T = T' then return P; else return FAIL. | 1371 +-------------------------------------------------------------------+ 1373 The * operation on (pairs of) the 2^n possible blocks corresponds to 1374 the multiplication operation for the binary Galois (finite) field of 1375 2^n elements defined by the polynomial f as follows (by analogy with 1376 [GCM]): 1378 n = 128: f = a^128 + a^7 + a^2 + a^1 + 1, 1380 n = 256: f = a^256 + a^10 + a^5 + a^2 + 1. 1382 The initial vector IV value for each message that is encrypted under 1383 the given initial key must be chosen in a unique manner. 1385 6.3.4. CCM-ACPKM-Master Authenticated Encryption Mode 1387 This section defines a CCM-ACPKM-Master authenticated encryption mode 1388 of operations that uses internal ACPKM-Master re-keying mechanism for 1389 the periodical key transformation. 1391 The CCM-ACPKM-Master authenticated encryption mode is differed from 1392 CCM-ACPKM mode in the way the keys K^1, K^2, ... are generated. For 1393 CCM-ACPKM-Master mode the keys are generated as follows: K^i = K[i], 1394 where |K^i|=k and K[1] | K[2] | ... | K[l] = ACPKM-Master( T*, K, k, 1395 l ). 1397 6.3.5. CBC-ACPKM-Master Encryption Mode 1399 This section defines a CBC-ACPKM-Master encryption mode that uses 1400 internal ACPKM-Master re-keying mechanism for the periodical key 1401 transformation. 1403 The CBC-ACPKM-Master encryption mode can be considered as the basic 1404 encryption mode CBC (see [MODES]) extended by the ACPKM-Master re- 1405 keying mechanism. 1407 The CBC-ACPKM-Master encryption mode can be used with the following 1408 parameters: 1410 o 64 <= n <= 512; 1412 o 128 <= k <= 512; 1414 o the maximum message size m_max = N * (n * 2^{n/2-1} / k). 1416 In the specification of the CBC-ACPKM-Master mode the plaintext and 1417 ciphertext must be a sequence of one or more complete data blocks. 1418 If the data string to be encrypted does not initially satisfy this 1419 property, then it MUST be padded to form complete data blocks. The 1420 padding methods are out of the scope of this document. An example of 1421 a padding method can be found in Appendix A of [MODES]. 1423 The key material K[j] that is used for the j-th section processing is 1424 equal to K^j, |K^j| = k bits. 1426 We will denote by D_{K} the decryption function which is a 1427 permutation inverse to the E_{K}. 1429 The CBC-ACPKM-Master mode encryption and decryption procedures are 1430 defined as follows: 1432 +----------------------------------------------------------------+ 1433 | CBC-ACPKM-Master-Encrypt(N, K, T*, IV, P) | 1434 |----------------------------------------------------------------| 1435 | Input: | 1436 | - section size N, | 1437 | - initial key K, | 1438 | - master key frequency T*, | 1439 | - initialization vector IV in V_n, | 1440 | - plaintext P = P_1 | ... | P_b, |P_b| = n, |P| <= m_max. | 1441 | Output: | 1442 | - ciphertext C. | 1443 |----------------------------------------------------------------| 1444 | 1. l = ceil(|P| / N) | 1445 | 2. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) | 1446 | 3. C_0 = IV | 1447 | 4. For j = 1, 2, ... , b do | 1448 | i = ceil(j * n / N), | 1449 | C_j = E_{K^i}(P_j (xor) C_{j-1}) | 1450 | 5. Return C = C_1 | ... | C_b | 1451 |----------------------------------------------------------------+ 1453 +----------------------------------------------------------------+ 1454 | CBC-ACPKM-Master-Decrypt(N, K, T*, IV, C) | 1455 |----------------------------------------------------------------| 1456 | Input: | 1457 | - section size N, | 1458 | - initial key K, | 1459 | - master key frequency T*, | 1460 | - initialization vector IV in V_n, | 1461 | - ciphertext C = C_1 | ... | C_b, |C_b| = n, |C| <= m_max. | 1462 | Output: | 1463 | - plaintext P. | 1464 |----------------------------------------------------------------| 1465 | 1. l = ceil(|C| / N) | 1466 | 2. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) | 1467 | 3. C_0 = IV | 1468 | 4. For j = 1, 2, ... , b do | 1469 | i = ceil(j * n / N) | 1470 | P_j = D_{K^i}(C_j) (xor) C_{j-1} | 1471 | 5. Return P = P_1 | ... | P_b | 1472 +----------------------------------------------------------------+ 1474 The initialization vector IV for each message that is encrypted under 1475 the given initial key does not need to be secret, but must be 1476 unpredictable. 1478 6.3.6. CFB-ACPKM-Master Encryption Mode 1480 This section defines a CFB-ACPKM-Master encryption mode that uses 1481 internal ACPKM-Master re-keying mechanism for the periodical key 1482 transformation. 1484 The CFB-ACPKM-Master encryption mode can be considered as the basic 1485 encryption mode CFB (see [MODES]) extended by the ACPKM-Master re- 1486 keying mechanism. 1488 The CFB-ACPKM-Master encryption mode can be used with the following 1489 parameters: 1491 o 64 <= n <= 512; 1493 o 128 <= k <= 512; 1495 o the maximum message size m_max = N * (n * 2^{n/2-1} / k). 1497 The key material K[j] that is used for the j-th section processing is 1498 equal to K^j, |K^j| = k bits. 1500 The CFB-ACPKM-Master mode encryption and decryption procedures are 1501 defined as follows: 1503 +-------------------------------------------------------------+ 1504 | CFB-ACPKM-Master-Encrypt(N, K, T*, IV, P) | 1505 |-------------------------------------------------------------| 1506 | Input: | 1507 | - section size N, | 1508 | - initial key K, | 1509 | - master key frequency T*, | 1510 | - initialization vector IV in V_n, | 1511 | - plaintext P = P_1 | ... | P_b, |P| <= m_max. | 1512 | Output: | 1513 | - ciphertext C. | 1514 |-------------------------------------------------------------| 1515 | 1. l = ceil(|P| / N) | 1516 | 2. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) | 1517 | 3. C_0 = IV | 1518 | 4. For j = 1, 2, ... , b - 1 do | 1519 | i = ceil(j * n / N), | 1520 | C_j = E_{K^i}(C_{j-1}) (xor) P_j | 1521 | 5. C_b = MSB_{|P_b|}(E_{K^l}(C_{b-1})) (xor) P_b | 1522 | 6. Return C = C_1 | ... | C_b | 1523 |-------------------------------------------------------------+ 1525 +-------------------------------------------------------------+ 1526 | CFB-ACPKM-Master-Decrypt(N, K, T*, IV, C) | 1527 |-------------------------------------------------------------| 1528 | Input: | 1529 | - section size N, | 1530 | - initial key K, | 1531 | - master key frequency T*, | 1532 | - initialization vector IV in V_n, | 1533 | - ciphertext C = C_1 | ... | C_b, |C| <= m_max. | 1534 | Output: | 1535 | - plaintext P. | 1536 |-------------------------------------------------------------| 1537 | 1. l = ceil(|C| / N) | 1538 | 2. K^1 | ... | K^l = ACPKM-Master(T*, K, k, l) | 1539 | 3. C_0 = IV | 1540 | 4. For j = 1, 2, ... , b - 1 do | 1541 | i = ceil(j * n / N), | 1542 | P_j = E_{K^i}(C_{j-1}) (xor) C_j | 1543 | 5. P_b = MSB_{|C_b|}(E_{K^l}(C_{b-1})) (xor) C_b | 1544 | 6. Return P = P_1 | ... | P_b | 1545 +-------------------------------------------------------------+ 1547 The initialization vector IV for each message that is encrypted under 1548 the given initial key need not to be secret, but must be 1549 unpredictable. 1551 6.3.7. OMAC-ACPKM-Master Authentication Mode 1553 This section defines an OMAC-ACPKM-Master message authentication code 1554 calculation mode that uses internal ACPKM-Master re-keying mechanism 1555 for the periodical key transformation. 1557 The OMAC-ACPKM-Master mode can be considered as the basic message 1558 authentication code calculation mode OMAC, which is also known as 1559 CMAC (see [RFC4493]), extended by the ACPKM-Master re-keying 1560 mechanism. 1562 The OMAC-ACPKM-Master message authentication code calculation mode 1563 can be used with the following parameters: 1565 o n in {64, 128, 256}; 1567 o 128 <= k <= 512; 1569 o the maximum message size m_max = N * (n * 2^{n/2-1} / (k + n)). 1571 The key material K[j] that is used for one section processing is 1572 equal to K^j | K^j_1, where |K^j| = k and |K^j_1| = n. 1574 The following is a specification of the subkey generation process of 1575 OMAC: 1577 +-------------------------------------------------------------------+ 1578 | Generate_Subkey(K1, r) | 1579 |-------------------------------------------------------------------| 1580 | Input: | 1581 | - key K1. | 1582 | Output: | 1583 | - key SK. | 1584 |-------------------------------------------------------------------| 1585 | 1. If r = n then return K1 | 1586 | 2. If r < n then | 1587 | if MSB_1(K1) = 0 | 1588 | return K1 << 1 | 1589 | else | 1590 | return (K1 << 1) (xor) R_n | 1591 | | 1592 +-------------------------------------------------------------------+ 1594 Where R_n takes the following values: 1596 o n = 64: R_{64} = 0^{59} | 11011; 1597 o n = 128: R_{128} = 0^{120} | 10000111; 1599 o n = 256: R_{256} = 0^{145} | 10000100101. 1601 The OMAC-ACPKM-Master message authentication code calculation mode is 1602 defined as follows: 1604 +----------------------------------------------------------------------+ 1605 | OMAC-ACPKM-Master(K, N, T*, M) | 1606 |----------------------------------------------------------------------| 1607 | Input: | 1608 | - section size N, | 1609 | - initial key K, | 1610 | - master key frequency T*, | 1611 | - plaintext M = M_1 | ... | M_b, |M| <= m_max. | 1612 | Output: | 1613 | - message authentication code T. | 1614 |----------------------------------------------------------------------| 1615 | 1. C_0 = 0^n | 1616 | 2. l = ceil(|M| / N) | 1617 | 3. K^1 | K^1_1 | ... | K^l | K^l_1 = ACPKM-Master(T*, K, (k + n), l) | 1618 | 4. For j = 1, 2, ... , b - 1 do | 1619 | i = ceil(j * n / N), | 1620 | C_j = E_{K^i}(M_j (xor) C_{j-1}) | 1621 | 5. SK = Generate_Subkey(K^l_1, |M_b|) | 1622 | 6. If |M_b| = n then M*_b = M_b | 1623 | else M*_b = M_b | 1 | 0^{n - 1 -|M_b|} | 1624 | 7. T = E_{K^l}(M*_b (xor) C_{b-1} (xor) SK) | 1625 | 8. Return T | 1626 +----------------------------------------------------------------------+ 1628 7. Joint Usage of External and Internal Re-keying 1630 Any mechanism described in Section 5 can be used with any mechanism 1631 described in Section 6. 1633 8. Security Considerations 1635 Re-keying should be used to increase "a priori" security properties 1636 of ciphers in hostile environments (e.g., with side-channel 1637 adversaries). If some efficient attacks are known for a cipher, it 1638 must not be used. So re-keying cannot be used as a patch for 1639 vulnerable ciphers. Base cipher properties must be well analyzed, 1640 because the security of re-keying mechanisms is based on the security 1641 of a block cipher as a pseudorandom function. 1643 Re-keying is not intended to solve any post-quantum security issues 1644 for symmetric crypto, since the reduction of security caused by 1645 Grover's algorithm is not connected with a size of plaintext 1646 transformed by a cipher - only a negligible (sufficient for key 1647 uniqueness) material is needed; and the aim of re-keying is to limit 1648 a size of plaintext transformed on one initial key. 1650 Re-keying can provide backward security only if previous traffic keys 1651 are securely deleted by all parties that have the keys. 1653 9. References 1655 9.1. Normative References 1657 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1658 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1659 . 1661 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1662 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1663 January 2012, . 1665 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 1666 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1667 . 1669 [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of 1670 Operation (GCM)", Submission to NIST 1671 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 1672 gcm/gcm-spec.pdf, January 2004. 1674 [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of 1675 Operation: Methods and Techniques", NIST Special 1676 Publication 800-38A, December 2001. 1678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1679 Requirement Levels", BCP 14, RFC 2119, 1680 DOI 10.17487/RFC2119, March 1997, 1681 . 1683 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1684 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 1685 2003, . 1687 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 1688 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 1689 2006, . 1691 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1692 Key Derivation Function (HKDF)", RFC 5869, 1693 DOI 10.17487/RFC5869, May 2010, 1694 . 1696 [SSH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1697 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 1698 January 2006, . 1700 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1701 (TLS) Protocol Version 1.2", RFC 5246, 1702 DOI 10.17487/RFC5246, August 2008, 1703 . 1705 [TLSDraft] 1706 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1707 Version 1.3", 2017, 1708 . 1710 9.2. Informative References 1712 [AbBell] Michel Abdalla and Mihir Bellare, "Increasing the Lifetime 1713 of a Key: A Comparative Analysis of the Security of Re- 1714 keying Techniques", ASIACRYPT2000, LNCS 1976, pp. 546-559, 1715 2000. 1717 [LDC] Howard M. Heys, "A Tutorial on Linear and Differential 1718 Cryptanalysis", 2017, 1719 . 1721 [Sweet32] Karthikeyan Bhargavan, Gaetan Leurent, "On the Practical 1722 (In-)Security of 64-bit Block Ciphers: Collision Attacks 1723 on HTTP over TLS and OpenVPN", Cryptology ePrint 1724 Archive Report 2016/798, 2016, 1725 . 1727 [TEMPEST] By Craig Ramsay, Jasper Lohuis, "TEMPEST attacks against 1728 AES. Covertly stealing keys for 200 euro", 2017, 1729 . 1732 Appendix A. Test examples 1734 CTR-ACPKM mode with AES-256 1735 ********* 1736 c = 64 1737 k = 256 1738 N = 256 1739 n = 128 1741 D_1 1742 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 1744 D_2 1745 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F 1747 Initial key K: 1748 88 99 AA BB CC DD EE FF 00 11 22 33 44 55 66 77 1749 FE DC BA 98 76 54 32 10 01 23 45 67 89 AB CD EF 1751 Plain text P: 1752 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88 1753 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 1754 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 1755 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 1756 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 1757 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 1758 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 1760 ICN: 1761 12 34 56 78 90 AB CE F0 1763 ACPKM's iteration 1 1764 Process block 1 1765 Input block (ctr) 1766 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 00 1768 Output block (ctr) 1769 FD 7E F8 9A D9 7E A4 B8 8D B8 B5 1C 1C 9D 6D D0 1771 Plain text 1772 11 22 33 44 55 66 77 00 FF EE DD CC BB AA 99 88 1774 Cipher text 1775 EC 5C CB DE 8C 18 D3 B8 72 56 68 D0 A7 37 F4 58 1777 Process block 2 1778 Input block (ctr) 1779 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 01 1781 Output block (ctr) 1782 19 98 C5 71 76 37 FB 17 11 E4 48 F0 0C 0D 60 B2 1784 Plain text 1785 00 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 1786 Cipher text 1787 19 89 E7 42 32 62 9D 60 99 7D E2 4B C0 E3 9F B8 1789 Input block (ctr) 1790 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 1792 Output block (ctr) 1793 F6 80 D1 21 2F A4 3D F4 EC 3A 91 DE 2A B1 6F 1B 1795 Input block (ctr) 1796 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F 1798 Output block (ctr) 1799 36 B0 48 8A 4F C1 2E 09 98 D2 E4 A8 88 E8 4F 3D 1801 Updated key: 1802 F6 80 D1 21 2F A4 3D F4 EC 3A 91 DE 2A B1 6F 1B 1803 36 B0 48 8A 4F C1 2E 09 98 D2 E4 A8 88 E8 4F 3D 1805 ACPKM's iteration 2 1806 Process block 1 1807 Input block (ctr) 1808 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 02 1810 Output block (ctr) 1811 E4 88 89 4F B6 02 87 DB 77 5A 07 D9 2C 89 46 EA 1813 Plain text 1814 11 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 1816 Cipher text 1817 F5 AA BA 0B E3 64 F0 53 EE F0 BC 15 C2 76 4C EA 1819 Process block 2 1820 Input block (ctr) 1821 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 03 1823 Output block (ctr) 1824 BC 4F 87 23 DB F0 91 50 DD B4 06 C3 1D A9 7C A4 1826 Plain text 1827 22 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 1829 Cipher text 1830 9E 7C C3 76 BD 87 19 C9 77 0F CA 2D E2 A3 7C B5 1832 Input block (ctr) 1833 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 1834 Output block (ctr) 1835 8E B9 7E 43 27 1A 42 F1 CA 8E E2 5F 5C C7 C8 3B 1837 Input block (ctr) 1838 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F 1840 Output block (ctr) 1841 1A CE 9E 5E D0 6A A5 3B 57 B9 6A CF 36 5D 24 B8 1843 Updated key: 1844 8E B9 7E 43 27 1A 42 F1 CA 8E E2 5F 5C C7 C8 3B 1845 1A CE 9E 5E D0 6A A5 3B 57 B9 6A CF 36 5D 24 B8 1847 ACPKM's iteration 3 1848 Process block 1 1849 Input block (ctr) 1850 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 04 1852 Output block (ctr) 1853 68 6F 22 7D 8F B2 9C BD 05 C8 C3 7D 22 FE 3B B7 1855 Plain text 1856 33 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 1858 Cipher text 1859 5B 2B 77 1B F8 3A 05 17 BE 04 2D 82 28 FE 2A 95 1861 Process block 2 1862 Input block (ctr) 1863 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 05 1865 Output block (ctr) 1866 C0 1B F9 7F 75 6E 12 2F 80 59 55 BD DE 2D 45 87 1868 Plain text 1869 44 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 1871 Cipher text 1872 84 4E 9F 08 FD F7 B8 94 4C B7 AA B7 DE 3C 67 B4 1874 Input block (ctr) 1875 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 1877 Output block (ctr) 1878 C5 71 6C C9 67 98 BC 2D 4A 17 87 B7 8A DF 94 AC 1880 Input block (ctr) 1881 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F 1882 Output block (ctr) 1883 E8 16 F8 0B DB BC AD 7D 60 78 12 9C 0C B4 02 F5 1885 Updated key: 1886 C5 71 6C C9 67 98 BC 2D 4A 17 87 B7 8A DF 94 AC 1887 E8 16 F8 0B DB BC AD 7D 60 78 12 9C 0C B4 02 F5 1889 ACPKM's iteration 4 1890 Process block 1 1891 Input block (ctr) 1892 12 34 56 78 90 AB CE F0 00 00 00 00 00 00 00 06 1894 Output block (ctr) 1895 03 DE 34 74 AB 9B 65 8A 3B 54 1E F8 BD 2B F4 7D 1897 Plain text 1898 55 66 77 88 99 AA BB CC EE FF 0A 00 11 22 33 44 1900 Cipher text 1901 56 B8 43 FC 32 31 DE 46 D5 AB 14 F8 AC 09 C7 39 1903 Input block (ctr) 1904 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 1906 Output block (ctr) 1907 74 1E B5 88 D6 AB DA B6 89 AA FD BA A9 3E A2 46 1909 Input block (ctr) 1910 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F 1912 Output block (ctr) 1913 16 3A A6 C2 3C E7 C3 74 CD 38 BF C6 FE 8C C5 FF 1915 Updated key: 1916 74 1E B5 88 D6 AB DA B6 89 AA FD BA A9 3E A2 46 1917 16 3A A6 C2 3C E7 C3 74 CD 38 BF C6 FE 8C C5 FF 1919 Encrypted src 1920 EC 5C CB DE 8C 18 D3 B8 72 56 68 D0 A7 37 F4 58 1921 19 89 E7 42 32 62 9D 60 99 7D E2 4B C0 E3 9F B8 1922 F5 AA BA 0B E3 64 F0 53 EE F0 BC 15 C2 76 4C EA 1923 9E 7C C3 76 BD 87 19 C9 77 0F CA 2D E2 A3 7C B5 1924 5B 2B 77 1B F8 3A 05 17 BE 04 2D 82 28 FE 2A 95 1925 84 4E 9F 08 FD F7 B8 94 4C B7 AA B7 DE 3C 67 B4 1926 56 B8 43 FC 32 31 DE 46 D5 AB 14 F8 AC 09 C7 39 1928 Appendix B. Contributors 1930 o Russ Housley 1931 Vigil Security, LLC 1932 housley@vigilsec.com 1934 o Evgeny Alekseev 1935 CryptoPro 1936 alekseev@cryptopro.ru 1938 o Ekaterina Smyshlyaeva 1939 CryptoPro 1940 ess@cryptopro.ru 1942 o Shay Gueron 1943 University of Haifa, Israel 1944 Intel Corporation, Israel Development Center, Israel 1945 shay.gueron@gmail.com 1947 o Daniel Fox Franke 1948 Akamai Technologies 1949 dfoxfranke@gmail.com 1951 o Lilia Ahmetzyanova 1952 CryptoPro 1953 lah@cryptopro.ru 1955 Appendix C. Acknowledgments 1957 We thank Mihir Bellare, Scott Fluhrer, Dorothy Cooley, Yoav Nir, Jim 1958 Schaad, Paul Hoffman and Dmitry Belyavsky for their useful comments. 1960 Author's Address 1962 Stanislav Smyshlyaev (editor) 1963 CryptoPro 1964 18, Suschevsky val 1965 Moscow 127018 1966 Russian Federation 1968 Phone: +7 (495) 995-48-20 1969 Email: svs@cryptopro.ru