idnits 2.17.1 draft-madden-jose-siv-mode-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 22, 2017) is 2288 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Madden 3 Internet-Draft ForgeRock 4 Intended status: Standards Track December 22, 2017 5 Expires: June 25, 2018 7 Synthetic IV (SIV) encryption modes for JWE 8 draft-madden-jose-siv-mode-02 10 Abstract 12 This document defines how to use Synthetic Initialization Vector 13 (SIV) encryption and key-wrapping modes with JSON Web Encryption 14 (JWE), and registers identifiers for SIV-based key-wrapping and 15 content encryption algorithms. SIV provides either deterministic 16 authenticated encryption and key-wrapping, or nonce-based misuse- 17 resistant authenticated encryption depending on usage. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 25, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 55 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 4 57 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Generic SIV Construction . . . . . . . . . . . . . . . . 5 60 2.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . 6 61 2.1.2. Decryption . . . . . . . . . . . . . . . . . . . . . 7 62 2.2. SIV Key Wrapping . . . . . . . . . . . . . . . . . . . . 8 63 2.2.1. A128SIVKW . . . . . . . . . . . . . . . . . . . . . . 9 64 2.2.2. A128SIVKW-HS256 . . . . . . . . . . . . . . . . . . . 9 65 2.2.3. A192SIVKW-HS384 . . . . . . . . . . . . . . . . . . . 9 66 2.2.4. A256SIVKW-HS512 . . . . . . . . . . . . . . . . . . . 10 67 2.3. SIV Content Encryption . . . . . . . . . . . . . . . . . 10 68 2.3.1. A128SIV . . . . . . . . . . . . . . . . . . . . . . . 11 69 2.3.2. A128SIV-HS256 . . . . . . . . . . . . . . . . . . . . 11 70 2.3.3. A192SIV-HS384 . . . . . . . . . . . . . . . . . . . . 11 71 2.3.4. A256SIV-HS512 . . . . . . . . . . . . . . . . . . . . 12 72 3. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 5.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 5.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Appendix A. Test Cases . . . . . . . . . . . . . . . . . . . . . 16 78 A.1. Test Cases for A128SIVKW . . . . . . . . . . . . . . . . 16 79 A.2. Test Cases for A192SIVKW-HS384 . . . . . . . . . . . . . 17 80 A.3. Test Cases for A128SIV-HS256 . . . . . . . . . . . . . . 18 81 A.4. Test Cases for A256SIV-HS512 . . . . . . . . . . . . . . 19 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 This specification registers cryptographic algorithms and identifiers 87 to be used with JSON Web Encryption (JWE) [RFC7516] for key-wrapping, 88 deterministic authenticated encryption and nonce-based misuse- 89 resistant authenticated content encryption based on the Synthetic 90 Initialization Vector (SIV, or "Synthetic IV") [RFC5297] block cipher 91 mode of operation. As a content encryption method, SIV mode takes as 92 input a key, the JWE Protected Header, an optional nonce (IV), and 93 the plaintext payload, and produces a ciphertext having the same 94 length as the plaintext and an authentication tag that also serves as 95 the synthetic initialization vector. As a JWE Algorithm, SIV key 96 wrapping is a drop-in replacement for AES Key Wrap. 98 This extends [RFC7518]. 100 1.1. Requirements Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 1.2. Motivation 108 The motivations from [RFC5297] apply here. 110 Compared to the existing JWE AES Key Wrap algorithm [RFC7516] 111 (Section 4.4), SIV provides a provable security bound, and a more 112 efficient construction. To wrap a 128-bit key, AES Key Wrap requires 113 12 calls to the AES block cipher, while SIV (with CMAC and as 114 described in this specification) requires just 3. AES Key Wrap has 115 an authentication strength of 64 bits ([SP800-38F], 116 Appendix A.3)--that is, a randomly selected bit-string of appropriate 117 length has a 1 in 2^64 chance of being a valid ciphertext, and this 118 probability will increase as more guesses are made. The SIV modes 119 specified in this document all provide authentication strength of at 120 least 128 bits. 122 For Content Encryption with a nonce, SIV is similar in performance to 123 other two-pass authenticated encryption methods, such as 124 AES_CBC_HMAC_SHA2, for short messages and typically slower than the 125 one-pass AES GCM. However, while the security of AES GCM collapses 126 catastrophically if a key-nonce pair is reused [SP800-38D] 127 (Appendix A), in SIV an attacker would only learn whether the same 128 plaintext (and the same associated data) has been encrypted with the 129 same key and nonce. This property, known as nonce-reuse misuse 130 resistant authenticated encryption (MRAE), provides a measure of 131 safety in the face of programming errors or poor quality nonce 132 generation, such as misconfigured or compromised random data 133 generators, or accidental reuse due to logic errors in deterministic 134 nonce generation algorithms (for instance, reusing nonces after a 135 restart). 137 For randomly-generated IVs, AES-GCM can only safely encrypt less than 138 2^32 messages with the same key, before the risk of an accidental 139 repetition becomes too high [SP800-38D] (Section 8.3). This limit 140 can be easily reached in practice. For instance, an application 141 producing JWE-encrypted tokens at a rate of 1000 per second will need 142 to rotate the key at most every 49 days. For SIV (and CBC) this 143 limit is around 2^48 (for short messages), which would allow the same 144 application to keep using one key for almost 9000 years. 146 Where the content or associated data of a JWE is known to contain a 147 non-repeating value or key (such as a unique JWT ID [RFC7519] or a 148 high-resolution time-stamp), then the nonce MAY be omitted, resulting 149 in a more compact serialisation. 151 For constrained devices, the abstract SIV scheme can be instantiated 152 with AES in CTR mode for confidentiality, and AES-CMAC [RFC4493] for 153 authentication. In this instantiation the mode requires only an AES 154 encryption circuit, providing similar benefits (and comparable 155 performance) to AES CCM mode [RFC3610], but with the added robustness 156 of nonce misuse resistance. The MRAE property is particularly 157 attractive for devices that have limited access to high-quality 158 sources of entropy, for instance in the Internet of Things (IoT). 160 Finally, SIV allows a single construction to be used for both 161 authenticated content encryption and key wrapping, and the 162 construction itself is simple to describe and implement correctly 163 from standard building blocks. 165 The main drawback of SIV is that it cannot be performed on-line as 166 data is produced. The full data must be processed to produce an 167 authentication tag (and synthetic IV) before any part can be 168 encrypted. It is therefore most suitable for relatively short 169 content such as JWTs [RFC7519]. 171 1.3. Notational Conventions 173 BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per 174 Section 2 of [RFC7515]. 176 UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation 177 of STRING, where STRING is a sequence of zero or more Unicode 178 [UNICODE] characters. 180 ASCII(STRING) denotes the octets of the ASCII [RFC20] representation 181 of STRING, where STRING is a sequence of zero or more ASCII 182 characters. 184 The concatenation of two values A and B is denoted as A || B. 186 1.4. Terminology 188 These terms defined by the JSON Web Signature (JWS) [RFC7515] 189 specification are incorporated into this specification: "Base64url 190 Encoding" 191 These terms defined by the JSON Web Encryption (JWE) [RFC7516] 192 specification are incorporated into this specification: "JSON Web 193 Encryption (JWE)", "Additional Authenticated Data (AAD)", 194 "Authentication Tag", "Content Encryption Key (CEK)", "JWE 195 Authentication Tag", "JWE Ciphertext", "JWE Encrypted Key", "JWE 196 Initialization Vector", "JWE Protected Header", and "Key Wrapping". 198 These terms defined by the Internet Security Glossary, Version 2 199 [RFC4949] are incorporated into this specification: "Ciphertext", 200 "Message Authentication Code (MAC)", and "Plaintext". 202 2. Algorithms 204 2.1. Generic SIV Construction 206 This section defines a family of authenticated encryption algorithms 207 built using a combination of AES in Counter (CTR) mode and either 208 CMAC or HMAC-SHA2 operations. The presentation here is based on the 209 abstract SIV scheme in Section 4 of [SIV]. The generic construction 210 is parameterised by the size of the key and the instantiation of the 211 MAC algorithm. We use MAC(K, M) to denote the application of the MAC 212 algorithm to the given message M using the given key K. We use AES- 213 CTR(K, IV, M) to denote the application of AES in CTR mode to the 214 message M, using the key K and Initialization Vector IV. 216 Rather than adopting the S2V construction of [RFC5297] for providing 217 multiple Additional Authentication Data (AAD) blocks to the MAC, we 218 instead adopt a simpler method based on the base64url-encoded compact 219 serialisation of the JWE Protected Header and IV separated by dots, 220 and the unencoded plaintext octets. This encoding uniquely 221 determines the components of the AAD while being simpler, and uses 222 encoded components that are already produced if the Compact 223 Serialization is being used. As stated in Section 5 of [SIV], the 224 motivation for the S2V construction is efficiency rather than 225 security, and any unambiguous encoding will suffice. It is expected 226 that a simpler construction will aid adoption of these safer 227 encryption modes in situations where performance is not of paramount 228 importance. 230 [[CREF1: There is an I-D defining an AES-GCM-SIV mode currently in 231 progress (https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-05). 232 This is a much more high-performance SIV mode than the ones defined 233 in this document. I have left it out of this specification because 234 it is more complex to implement and still in draft form. A further 235 I-D/RFC could be proposed to also add that mode for in this same 236 framework, but I believe the modes defined in the present I-D will be 237 useful for many years to come, especially on constrained devices. 238 --N. Madden]] 239 For the CMAC-based algorithms, we only define modes for an overall 240 128-bit security level. That is, the expected effort for an attacker 241 to either produce an authentication tag forgery, recover either the 242 encryption or MAC keys, or to compromise the privacy of a any SIV- 243 encrypted JWE, is on the order of 2^128 operations. For the HMAC- 244 based algorithms we define modes at overall 128-bit, 192-bit and 245 256-bit security levels. The reason for this is that AES-CMAC is 246 only capable of producing a maximum authentication tag of 128 bits 247 and so cannot provide more than 128 bits of protection against 248 authentication tag forgery. 250 2.1.1. Encryption 252 The authenticated encryption algorithm takes as input for octet 253 strings: a secret key K, a plaintext P, additional authenticated data 254 AAD (computed as per Steps 13-14 of Section 5.1 of [RFC7516]), and an 255 optional initialization vector IV. It produces the ciphertext value 256 E and an authentication tag T as outputs. The data in the plaintext 257 are encrypted, and the additional authenticated data are 258 authenticated, but not encrypted. 260 Encryption is performed using the following steps: 262 1. The secondary keys MAC_KEY and ENC_KEY are generated from the 263 input key K as follows. Each of these two keys is an octet 264 string. 266 MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in 267 order. 269 ENC_KEY consists of the final ENC_KEY_LEN octets of K, in 270 order. 272 The number of octets in the input key K MUST be the sum of 273 MAC_KEY_LEN and ENC_KEY_LEN. 275 2. If a nonce is to be used, then the IV SHOULD be a 128-bit value 276 generated randomly or pseudorandomly. 278 3. A message Authentication Tag T is computed as: 280 T = MAC(MAC_KEY, ASCII(AAD || '.' || BASE64URL(IV) || '.') || 281 plaintext). 283 If no IV (nonce) is being used, then an empty octet sequence MUST 284 be used instead. 286 4. The Synthetic IV, SIV, is set to the first 16 octets of T, in 287 order. 289 5. The plaintext is encrypted using AES-CTR with ENC_KEY as the key 290 and SIV as the IV. We denote the ciphertext output of this step 291 as E. 293 6. The ciphertext E and the Authentication Tag T are returned as the 294 outputs of the authenticated encryption. 296 The encryption process can be illustrated as follows. Here K, P, 297 AAD, IV, SIV, T, and E denote the key, plaintext, Additional 298 Authenticated Data, Initialization Vector, Synthetic IV, 299 Authentication Tag, and ciphertext, respectively. 301 MAC_KEY = initial MAC_KEY_LEN octets of K, 303 ENC_KEY = final ENC_KEY_LEN octets of K, 305 T = MAC(MAC_KEY, ASCII(AAD || '.' || BASE64URL(IV) || '.') || P), 307 SIV = initial 16 octets of T, 309 E = AES-CTR(ENC_KEY, SIV, P). 311 2.1.2. Decryption 313 Decryption is performed using the following steps: 315 1. The secondary keys MAC_KEY and ENC_KEY are generated from the 316 input key K as in Step 1 of Section 2.1.1. 318 2. The Synthetic IV is set to the first 16 octets of the 319 Authentication Tag T. If the Authentication Tag is missing or 320 not of the expected length for the algorithm (which is always at 321 least 16 octets) then decryption MUST halt with an indication of 322 failure. 324 3. The plaintext P is decrypted using AES-CTR with ENC_KEY as the 325 key, SIV as the IV, and the ciphertext, E. 327 4. The Authentication Tag T is checked by recomputing the tag T' as 328 in Step 3 of Section 2.1.1. If T and T' are identical then H and 329 P are considered valid and processing is continued. Otherwise, 330 all of the data used in the MAC computation MUST be discarded and 331 the decryption operation MUST halt with an indication of failure. 332 Tag comparison MUST use a constant-time octet string comparison 333 operation using the known length of the Authentication Tag as 334 specified by the algorithm in use. 336 5. The plaintext P is returned. 338 2.2. SIV Key Wrapping 340 The following JWE algorithms are defined here (to be applied as 341 values of "alg" parameter): 343 +-----------------+-------------------------------------------------+ 344 | "alg" Param | Key Management Algorithm | 345 | Value | | 346 +-----------------+-------------------------------------------------+ 347 | A128SIVKW | AES SIV Key Wrap using CMAC and 256 bit key. | 348 | A128SIVKW-HS256 | AES SIV Key Wrap using HMAC-SHA-256-128 and 256 | 349 | | bit key. | 350 | A192SIVKW-HS384 | AES SIV Key Wrap using HMAC-SHA-384-192 and 384 | 351 | | bit key. | 352 | A256SIVKW-HS512 | AES SIV Key Wrap using HMAC-SHA-512-256 and 512 | 353 | | bit key. | 354 +-----------------+-------------------------------------------------+ 356 All of the key wrapping modes use the generic construction from 357 Section 2.1, with the following inputs: 359 The plaintext P is the octets of the Content Encryption Key (CEK) 360 to be wrapped. 362 The input key K is the Key Encryption Key (KEK). 364 The IV is an empty octet sequence. 366 The AAD is the UTF8 octets of the value of the "alg" parameter 367 (e.g., "A128SIVKW"). 369 In all cases the output ciphertext length will be the same as the 370 input plaintext CEK, in octets. The authentication tag will either 371 be 16, 24 or 32 octets long depending on the algorithm. 373 The JWE Encrypted Key value is the Ciphertext output. 375 The Authentication Tag output is represented in base64url encoded 376 form as the "tag" (authentication tag) Header Parameter value, as in 377 Section 4.7.1.2 of [RFC7518]. This specification extends that header 378 value to allow authentication tags of 192 or 256 bits. NB: this has 379 the added advantage of binding the wrapped key into the JWE 380 authenticated data, which would otherwise not happen. 382 2.2.1. A128SIVKW 384 This algorithm uses the CMAC message authentication code [RFC4493] to 385 provide message authentication and the synthetic IV. 387 The parameters are as follows: 389 The input key K is 32 octets long. 391 MAC_KEY_LEN is 16 octets. 393 ENC_KEY_LEN is 16 octets. 395 MAC is CMAC. 397 The output tag length is 16 octets. 399 2.2.2. A128SIVKW-HS256 401 This algorithm uses the HMAC-SHA-256-128 message authentication code 402 as defined in [RFC4868] to provide message authentication and the 403 synthetic IV. 405 The parameters are as follows: 407 The input key K is 32 octets long. 409 MAC_KEY_LEN is 16 octets. 411 ENC_KEY_LEN is 16 octets. 413 MAC is HMAC-SHA-256-128. 415 The output tag length is 16 octets. 417 2.2.3. A192SIVKW-HS384 419 This algorithm uses the HMAC-SHA-384-192 message authentication code 420 as defined in [RFC4868] to provide message authentication and the 421 synthetic IV. 423 The parameters are as follows: 425 The input key K is 48 octets long. 427 MAC_KEY_LEN is 24 octets. 429 ENC_KEY_LEN is 24 octets. 431 MAC is HMAC-SHA-384-192. 433 The output tag length is 24 octets. 435 2.2.4. A256SIVKW-HS512 437 This algorithm uses the HMAC-SHA-512-256 message authentication code 438 as defined in [RFC4868] to provide message authentication and the 439 synthetic IV. 441 The parameters are as follows: 443 The input key K is 64 octets long. 445 MAC_KEY_LEN is 32 octets. 447 ENC_KEY_LEN is 32 octets. 449 MAC is HMAC-SHA-512-256. 451 The output tag length is 32 octets. 453 2.3. SIV Content Encryption 455 The following content encryption methods are defined here (to be 456 applied as values of the "enc" parameter): 458 +-----------------+-------------------------------------------------+ 459 | "enc" Param | Content Encryption Method | 460 | Value | | 461 +-----------------+-------------------------------------------------+ 462 | A128SIV | AES SIV using CMAC and 256 bit key. | 463 | A128SIV-HS256 | AES SIV using HMAC-SHA-256-128 and 256 bit key. | 464 | A192SIV-HS384 | AES SIV using HMAC-SHA-384-192 and 384 bit key. | 465 | A256SIV-HS512 | AES SIV using HMAC-SHA-512-256 and 512 bit key. | 466 +-----------------+-------------------------------------------------+ 468 All of the SIV content encryption methods use the generic 469 construction from Section 2.1, with the following inputs: 471 The plaintext P is the octets of JWE plaintext. 473 The input key K is the Content Encryption Key (CEK). 475 The IV is either a randomly or pseudorandomly generated 16 octet 476 value, or an empty octet string. 478 The AAD is the UTF8 octets of the JWE Protected Header. 480 In all cases the output ciphertext length will be the same as the 481 input plaintext, in octets. The authentication tag will either be 482 16, 24 or 32 octets long depending on the algorithm. The Ciphertext 483 and Authentication Tag outputs become the JWE Ciphertext and JWE 484 Authentication Tag values respectively. 486 2.3.1. A128SIV 488 This algorithm uses the CMAC message authentication code [RFC4493] to 489 provide message authentication and the synthetic IV. 491 The parameters are as follows: 493 The input key K is 32 octets long. 495 MAC_KEY_LEN is 16 octets. 497 ENC_KEY_LEN is 16 octets. 499 MAC is CMAC. 501 The output tag length is 16 octets. 503 2.3.2. A128SIV-HS256 505 This algorithm uses the HMAC-SHA-256-128 message authentication code 506 as defined in [RFC4868] to provide message authentication and the 507 synthetic IV. 509 The parameters are as follows: 511 The input key K is 32 octets long. 513 MAC_KEY_LEN is 16 octets. 515 ENC_KEY_LEN is 16 octets. 517 MAC is HMAC-SHA-256-128. 519 The output tag length is 16 octets. 521 2.3.3. A192SIV-HS384 523 This algorithm uses the HMAC-SHA-384-192 message authentication code 524 as defined in [RFC4868] to provide message authentication and the 525 synthetic IV. 527 The parameters are as follows: 529 The input key K is 48 octets long. 531 MAC_KEY_LEN is 24 octets. 533 ENC_KEY_LEN is 24 octets. 535 MAC is HMAC-SHA-384-192. 537 The output tag length is 24 octets. 539 2.3.4. A256SIV-HS512 541 This algorithm uses the HMAC-SHA-512-256 message authentication code 542 as defined in [RFC4868] to provide message authentication and the 543 synthetic IV. 545 The parameters are as follows: 547 The input key K is 64 octets long. 549 MAC_KEY_LEN is 32 octets. 551 ENC_KEY_LEN is 32 octets. 553 MAC is HMAC-SHA-512-256. 555 The output tag length is 32 octets. 557 3. IANA considerations 559 The following are added to JSON Web Signature and Encryption 560 Algorithms registry: 562 o Algorithm Name: "A128SIVKW" 563 o Algorithm Description: AES SIV Key Wrap with CMAC using 256 bit 564 key 565 o Algorithm Usage Location(s): "alg" 566 o JOSE Implementation Requirements: Recommended 567 o Change Controller: IESG 568 o Specification Document(s): Section 2.2.1 570 o Algorithm Name: "A128SIVKW-HS256" 571 o Algorithm Description: AES SIV Key Wrap with HMAC-SHA-256-128 572 using 256 bit key 573 o Algorithm Usage Location(s): "alg" 574 o JOSE Implementation Requirements: Recommended 575 o Change Controller: IESG 576 o Specification Document(s): Section 2.2.2 578 o Algorithm Name: "A192SIVKW-HS384" 579 o Algorithm Description: AES SIV Key Wrap with HMAC-SHA-384-192 580 using 384 bit key 581 o Algorithm Usage Location(s): "alg" 582 o JOSE Implementation Requirements: Optional 583 o Change Controller: IESG 584 o Specification Document(s): Section 2.2.3 586 o Algorithm Name: "A256SIVKW-HS512" 587 o Algorithm Description: AES SIV Key Wrap with HMAC-SHA-512-256 588 using 512 bit key 589 o Algorithm Usage Location(s): "alg" 590 o JOSE Implementation Requirements: Optional 591 o Change Controller: IESG 592 o Specification Document(s): Section 2.2.4 594 o Algorithm Name: "A128SIV" 595 o Algorithm Description: AES SIV with CMAC using 256 bit key 596 o Algorithm Usage Location(s): "enc" 597 o JOSE Implementation Requirements: Recommended 598 o Change Controller: IESG 599 o Specification Document(s): Section 2.3.1 601 o Algorithm Name: "A128SIV-HS256" 602 o Algorithm Description: AES SIV with HMAC-SHA-256-128 using 256 bit 603 key 604 o Algorithm Usage Location(s): "enc" 605 o JOSE Implementation Requirements: Recommended 606 o Change Controller: IESG 607 o Specification Document(s): Section 2.3.2 609 o Algorithm Name: "A192SIV-HS284" 610 o Algorithm Description: AES SIV with HMAC-SHA-384-192 using 384 bit 611 key 612 o Algorithm Usage Location(s): "enc" 613 o JOSE Implementation Requirements: Optional 614 o Change Controller: IESG 615 o Specification Document(s): Section 2.3.3 617 o Algorithm Name: "A256SIV-HS512" 618 o Algorithm Description: AES SIV with HMAC-SHA-512-256 using 512 bit 619 key 620 o Algorithm Usage Location(s): "enc" 621 o JOSE Implementation Requirements: Optional 622 o Change Controller: IESG 623 o Specification Document(s): Section 2.3.4 625 4. Security Considerations 627 The security considerations of [RFC5297] apply here. 629 In total, no more than 16 * 2^48 octets of data (approx. 4 exabytes) 630 should be encrypted with the same key in any SIV mode. For example, 631 when using SIV128KW to wrap 128-bit keys, then no more than 2^48 632 messages should be encrypted with the same key encryption key (KEK). 633 This is over 281 trillion messages, so is expected to provide 634 sufficient capacity for extremely long-lived or high-usage keys. 636 When using SIV for content encryption, it is RECOMMENDED to always 637 use a nonce or a random IV of at least 128 bits for every message. 638 While SIV minimises the information that is lost in case of a nonce 639 reuse, the security of the cipher is still considerably weaker than 640 it would be otherwise. In technical terms, SIV mode does not achieve 641 semantic security if unique nonces are not used for each message, 642 achieving only the weaker notion of deterministic authenticated 643 encryption (DAE). 645 SIV uses AES in CTR mode for encryption, which produces ciphertexts 646 that are exactly the same length as the plaintext. If the length of 647 the plaintext is sensitive (for instance, when there are only a small 648 number of possibilities for the plaintext and they are all of 649 different lengths) then the application should pad such values to 650 some minimum/fixed size before encryption. If such padding is 651 performed, then it MUST be applied before calling the AES-SIV 652 encryption modes defined in this specification, so that the padding 653 is included in the authentication tag. When decrypting, 654 authentication tag validation in Step 4 of Section 2.1.2 MUST be 655 performed before any validation or processing of the padding is 656 performed. 658 Care should be taken when combining JWE plaintext compression with 659 SIV encryption for a related reason: compression varies the size of 660 the plaintext based on the (confidential) content of that plaintext. 661 In SIV mode (and other cipher modes, such as GCM and, to a lesser 662 extent, CBC), this will vary the size of the ciphertext by the same 663 amount. If an attacker is able to control any part of the content of 664 the plaintext then they may be able to infer confidential parts of 665 the same plaintext according to variations in the size of the 666 compressed and encrypted ciphertext. It is therefore recommended not 667 to use compression with SIV mode encryption (or any encryption) 668 unless the expected information leakage is acceptable. 670 5. References 672 5.1. Normative References 674 [RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20, 675 October 1969. 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, 679 DOI 10.17487/RFC2119, March 1997, 680 . 682 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 683 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 684 2003, . 686 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 687 384, and HMAC-SHA-512 with IPsec", RFC 4868, 688 DOI 10.17487/RFC4868, May 2007, 689 . 691 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 692 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 693 2015, . 695 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 696 RFC 7516, DOI 10.17487/RFC7516, May 2015, 697 . 699 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 700 DOI 10.17487/RFC7518, May 2015, 701 . 703 5.2. Informative References 705 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 706 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 707 2003, . 709 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 710 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 711 2006, . 713 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 714 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 715 . 717 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 718 Authenticated Encryption Using the Advanced Encryption 719 Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 720 2008, . 722 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 723 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 724 . 726 [SIV] Rogaway, P. and T. Shrimpton, "Deterministic 727 Authenticated-Encryption. A Provable-Security Treatment of 728 the Key-Wrap Problem.", IACR ePrint 2006/221, August 2007. 730 [SP800-38D] 731 Dworkin, M., "Recommendation for Block Cipher Modes of 732 Operation: Galois/Counter Mode (GCM) and GMAC.", NIST 733 Special Publication 800-38D, November 2007. 735 [SP800-38F] 736 Dworkin, M., "Recommentation for Block Cipher Modes of 737 Operation: Methods for Key Wrapping.", NIST Special 738 Publication 800-38F, December 2012. 740 [UNICODE] The Unicode Consortium, "The Unicode Standard", 1991-, 741 . 743 Appendix A. Test Cases 745 The following test cases can be used to validate implementations of 746 the AES SIV algorithms defined in this specification. 748 The variable names are those defined in Section 2.1.1. All values 749 are hexadecimal. 751 A.1. Test Cases for A128SIVKW 753 NB: K here is the KEK, and P is the CEK to be wrapped, T is the 754 output "tag" value, and E is the wrapped CEK. 756 A128SIVKW 758 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 759 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 761 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 763 ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 765 P = 0f 0e 0d 0c 0b 0a 09 08 07 06 05 04 03 02 01 00 767 IV = 769 AAD = 41 31 32 38 53 49 56 4b 57 771 T = c3 eb 04 f1 c7 07 8b 92 e0 dc f6 fe 17 f5 82 46 773 SIV = c3 eb 04 f1 c7 07 8b 92 e0 dc f6 fe 17 f5 82 46 775 E = ef 96 fd 87 24 ea f9 9b 54 15 8a fa 20 5f 77 de 777 A.2. Test Cases for A192SIVKW-HS384 779 NB: K here is the KEK, and P is the CEK to be wrapped, T is the 780 output "tag" value, and E is the wrapped CEK. 782 A192SIVKW-HS384 784 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 785 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 786 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 788 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 789 10 11 12 13 14 15 16 17 791 ENC_KEY = 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 792 28 29 2a 2b 2c 2d 2e 2f 794 P = 17 16 15 14 13 12 11 10 0f 0e 0d 0c 0b 0a 09 08 795 07 06 05 04 03 02 01 00 797 IV = 799 AAD = 41 31 39 32 53 49 56 4b 57 2d 48 53 33 38 34 801 T = 27 86 b6 03 3b b1 4f f7 cb 85 6d ae 69 6e 3d 98 802 ff e2 0b 59 77 b3 e5 36 804 SIV = c3 eb 04 f1 c7 07 8b 92 e0 dc f6 fe 17 f5 82 46 806 E = 65 c5 52 72 4e d3 4f 9e ab 20 32 4d af 0d 2d 31 807 7f df 69 13 06 c5 0a c8 809 A.3. Test Cases for A128SIV-HS256 810 A128SIV-HS256 812 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 813 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 815 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 817 ENC_KEY = 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 819 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 820 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 821 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 822 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 823 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 824 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 825 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 826 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 828 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 830 AAD = 7b 22 61 6c 67 22 3a 22 64 69 72 22 2c 22 65 6e 831 63 22 3a 22 41 31 32 38 53 49 56 2d 48 53 32 35 832 36 22 7d 834 T = 5e cd e7 ca 4a eb 39 bc 05 11 2b a9 00 17 a3 76 836 SIV = 5e cd e7 ca 4a eb 39 bc 05 11 2b a9 00 17 a3 76 838 E = 22 70 54 15 99 71 ca d6 01 8c d9 30 29 e6 e5 20 839 5d 0a d3 d2 1e 8c 10 ce 6f 84 36 e3 68 20 24 42 840 59 e8 ae bd 55 16 ce 37 ab 5a 44 3b 22 0a 94 a0 841 03 7f 4a ad 4d 11 57 db 55 cb 6a 01 70 8b 05 0d 842 6f 39 ad b4 d8 3b 5c 77 ac 16 6a 98 cc 0e 0a 75 843 93 f6 34 6e 67 b1 9d 4c 43 17 11 95 7b b5 e3 8b 844 ee cb df 2e 7f 49 c0 ba c3 58 5b 90 32 b4 bc ca 845 08 6b 51 a8 c5 d3 81 a7 fd d8 c3 fb 99 6e 25 46 847 A.4. Test Cases for A256SIV-HS512 848 A256SIV-HS512 850 K = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 851 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 852 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 853 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 855 MAC_KEY = 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 856 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 858 ENC_KEY = 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 859 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 861 P = 41 20 63 69 70 68 65 72 20 73 79 73 74 65 6d 20 862 6d 75 73 74 20 6e 6f 74 20 62 65 20 72 65 71 75 863 69 72 65 64 20 74 6f 20 62 65 20 73 65 63 72 65 864 74 2c 20 61 6e 64 20 69 74 20 6d 75 73 74 20 62 865 65 20 61 62 6c 65 20 74 6f 20 66 61 6c 6c 20 69 866 6e 74 6f 20 74 68 65 20 68 61 6e 64 73 20 6f 66 867 20 74 68 65 20 65 6e 65 6d 79 20 77 69 74 68 6f 868 75 74 20 69 6e 63 6f 6e 76 65 6e 69 65 6e 63 65 870 IV = 1a f3 8c 2d c2 b9 6f fd d8 66 94 09 23 41 bc 04 872 AAD = 7b 22 61 6c 67 22 3a 22 64 69 72 22 2c 22 65 6e 873 63 22 3a 22 41 32 35 36 53 49 56 2d 48 53 35 31 874 32 22 7d 876 T = f9 e5 2d 5c 58 9d 3a f8 3f 98 3f ce 3b 98 aa ae 877 97 aa 0c 02 e1 80 a4 ec a3 0b 5e 7b 47 97 a5 b2 879 SIV = f9 e5 2d 5c 58 9d 3a f8 3f 98 3f ce 3b 98 aa ae 881 E = cc 05 71 16 ad 3d 44 9b 50 ba 7b bd b4 42 f7 08 882 20 fe bc d0 58 0e 8d 4d e0 f3 61 70 6b db b6 17 883 a6 d6 a9 56 e5 69 cc 74 d3 16 7d 2c a2 a6 54 2e 884 e7 69 64 9c db 4d 9b 68 b7 01 74 f8 a4 4e eb 9e 885 a0 26 8a 3c 48 e9 c8 88 56 c4 2c eb 36 95 d2 90 886 39 18 34 5d d2 f8 17 20 bb ce be 24 bf f1 74 68 887 26 bb c9 c8 11 92 9d 45 ce dd 63 49 2d ed b6 c0 888 b2 b5 bd c4 93 a6 0f e6 c7 c6 e7 fd 94 90 3d 03 890 Author's Address 891 Neil Madden 892 ForgeRock 893 Broad Quay House 894 Prince Street 895 Bristol BS1 4DJ 896 United Kingdom 898 Email: neil.madden@forgerock.com