idnits 2.17.00 (12 Aug 2021) /tmp/idnits37710/draft-hudson-camellia-cts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 19, 2010) is 4200 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) ** Downref: Normative reference to an Informational RFC: RFC 3713 -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-38B' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-108' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRYPTOENG' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos Working Group G. Hudson, Ed. 3 Internet-Draft MIT Kerberos Consortium 4 Expires: May 23, 2011 November 19, 2010 6 Camellia Encryption for Kerberos 5 7 draft-hudson-camellia-cts-00 9 Abstract 11 This document specifies two encryption types and two corresponding 12 checksum types for the Kerberos cryptosystem suite. The new types 13 use the Camellia block cipher in CBC-mode with ciphertext stealing 14 and the CMAC algorithm for integrity protection. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 23, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 1. Introduction 56 The Camellia block cipher, described in [RFC3713], has a 128-bit 57 block size and a 128-bit, 192-bit, or 256-bit key size, similar to 58 AES. This document specifies Kerberos encryption and checksum types 59 for Camellia using 128-bit or 256-bit keys. The new types conform to 60 the framework specified in [RFC3961], but do not use the simplified 61 profile. 63 Like the simplified profile, the new types use key derivation to 64 produce keys for encryption, integrity protection, and checksum 65 operations. Instead of the [RFC3961] section 5.1 key derivation 66 function, the new types use a key derivation function from the family 67 specified in [SP800-108]. 69 The new types use the CMAC algorithm for integrity protection and 70 checksum operations. As a consequence, they do not rely on a hash 71 algorithm except when generating keys from strings. 73 Like the AES encryption types [RFC3962], the new encryption types use 74 CBC mode with ciphertext stealing to avoid the need for padding. 75 They also use the same PBKDF2 algorithm for key generation from 76 strings, with a modification to the salt string to ensure that 77 different keys are generated for Camellia and AES encryption types. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Protocol Key Representation 85 The Camellia key space is dense, so we use random octet strings 86 directly as keys. The first bit of the Camellia bit string is the 87 high bit of the first byte of the random octet string. 89 3. Key Generation from Strings 91 We use a variation on the key generation algorithm specified in 92 [RFC3962] section 4. 94 First, to ensure that different long-term keys are used with Camellia 95 and AES, we prepend the enctype name to the salt string, separated by 96 a null byte. The enctype name is "camellia128-cts-cmac" or 97 "camellia256-cts-cmac" (without the quotes). 99 Second, the final key derivation step uses the algorithm described in 100 Section 4 instead of the key derivation algorithm used by the 101 simplified profile. 103 Third, if no string-to-key parameters are specified, the default 104 number of iterations is raised to 32768. 106 saltp = enctype-name | 0x00 | salt 107 tkey = random2key(PBKDF2-HMAC-SHA1(passphrase, saltp, 108 iter_count, keylength)) 109 key = KDF-FEEDBACK-CMAC(tkey, "kerberos") 111 4. Key Derivation 113 We use a key derivation function from the family specified in 114 [SP800-108] section 5.2, "KDF in Feedback Mode". The PRF parameter 115 of the key derivation function is CMAC with Camellia-128 or Camellia- 116 256 as the underlying block cipher; this PRF has an output size of 117 128 bits. A block counter is used with a length of 4 bytes, 118 represented in big-endian order. The length of the output key in 119 bits (denoted as k) is also represented as a four-byte string in big- 120 endian order. The label input to the KDF is the usage constant 121 supplied to the key derivation function, and the context is unused. 123 n = ceiling(k / 128) 124 K0 = zeros 125 Ki = CMAC(key, K(i-1) | i | constant | 0x00 | k) 126 DR(key, constant) = k-truncate(K1 | K2 | ... | Kn) 127 KDF-FEEDBACK-CMAC(key, constant) = random-to-key(DR(key, constant)) 129 The constants used for key derivation are the same as those used in 130 the simplified profile. 132 5. CMAC Checksum Algorithm 134 For integrity protection and checksums, we use the CMAC function 135 defined in [SP800-38B], with Camellia-128 or Camellia-256 as the 136 underlying block cipher. 138 6. Kerberos Algorithm Protocol Parameters 140 The following parameters apply to the encryption types camellia128- 141 cts-cmac, which uses a 128-bit protocol key, and camellia256-cts- 142 cmac, which uses a 256-bit protocol key. 144 Protocol key format: as defined in Section 2. 146 Specific key structure: three protocol format keys: { Kc, Ke, Ki }. 148 Required checksum mechanism: as defined in Section 7. 150 Key generation seed length: the key size (128 or 256 bits). 152 String-to-key function: as defined in Section 3. 154 Default string-to-key parameters: 00 00 80 00. 156 Random-to-key function: identity function. 158 Key-derivation function: as indicated below, with usage represented 159 as four octets in big-endian order. 161 Kc = KDF-FEEDBACK-CMAC(base-key, usage | 0x99) 162 Ke = KDF-FEEDBACK-CMAC(base-key, usage | 0xAA) 163 Ki = KDF-FEEDBACK-CMAC(base-key, usage | 0x55) 165 Initial cipher state: all bits zero. 167 Encryption function: as follows, where E() is Camellia encryption in 168 CBC-CTS mode, with the next-to-last block used as the CBC-style ivec, 169 or the last block if there is only one. 171 conf = Random string of 128 bits 172 (C, newstate.ivec) = E(Ke, conf | plaintext, oldstate.ivec) 173 M = CMAC(Ki, conf | plaintext) 174 ciphertext = C | M 176 Decryption function: as follows, where D() is Camellia decryption in 177 CBC-CTS mode, with the ivec treated as in E(). 179 (C, M) = ciphertext 180 (P, newIV) = D(Ke, C, oldstate.ivec) 181 if (M != CMAC(Ki, P)) report error 182 newstate.ivec = newIV 184 Pseudo-random function: as follows. 186 Kp = KDF-FEEDBACK-CMAC(protocol-key, "prf") 187 PRF = CMAC(Kp, octet-string) 189 7. Checksum Parameters 191 The following parameters apply to the checksum types cmac-camellia128 192 and cmac-camellia256, which are the associated checksum for 193 camellia128-cts-cmac and camellia256-cts-cmac respectively. 195 Associated cryptosystem: Camellia-128 or Camellia-256 as appropriate 196 for the checksum type. 198 get_mic: CMAC(Kc, message). 200 verify_mic: get_mic and compare. 202 8. Assigned Numbers 204 Encryption types 206 +----------------------+-------------+----------+ 207 | Type name | etype value | key size | 208 +----------------------+-------------+----------+ 209 | camellia128-cts-cmac | TBD | 128 | 210 | camellia256-cts-cmac | TBD | 256 | 211 +----------------------+-------------+----------+ 213 Checksum types 215 +------------------+---------------+--------+ 216 | Type name | sumtype value | length | 217 +------------------+---------------+--------+ 218 | cmac-camellia128 | TBD | 128 | 219 | cmac-camellia256 | TBD | 128 | 220 +------------------+---------------+--------+ 222 9. Security Considerations 224 [CRYPTOENG] chapter 4 discusses weaknesses of the CBC cipher mode. 225 An attacker who can observe enough messages generated with the same 226 key to encounter a collision in ciphertext blocks could recover the 227 XOR of the plaintexts of the previous blocks. Observing such a 228 collision becomes likely as the number of blocks observed approaches 229 2^64. This consideration applies to all previously standardized 230 Kerberos encryption types and all uses of CBC encryption with 128-bit 231 block ciphers in other protocols. Kerberos deployments can mitigate 232 this concern by rolling over keys often enough to make observing 2^64 233 messages unlikely. 235 Because the new checksum types are deterministic, an attacker could 236 pre-compute checksums for a known plain-text message in 2^64 randomly 237 chosen protocol keys. The attacker could then observe checksums 238 legitimately computed in different keys until a collision with one of 239 the pre-computed keys is observed; this becomes likely after the 240 number of observed checksums approaches 2^64. Observing such a 241 collision allows the attacker to recover the protocol key. This 242 consideration applies to most previously standardized Kerberos 243 checksum types and most uses of 128-bit checksums in other protocols. 245 The Camellia cipher has not received as much scrutiny as AES. 246 Kerberos deployments should not migrate to the Camellia encryption 247 types simply because they are newer, but should use them only if 248 business needs require the use of Camellia, or if a serious flaw is 249 discovered in AES which does not apply to Camellia. 251 The security considerations described in [RFC3962] section 8 252 regarding the string-to-key algorithm also apply to the Camellia 253 encryption types. 255 10. Test Vectors 257 Sample results for string-to-key conversion: 259 Iteration count = 1 260 Pass phrase = "password" 261 Salt = "ATHENA.MIT.EDUraeburn" 262 128-bit Camellia key: 263 57 D0 29 72 98 FF D9 D3 5D E5 A4 7F B4 BD E2 4B 264 256-bit Camellia key: 265 B9 D6 82 8B 20 56 B7 BE 65 6D 88 A1 23 B1 FA C6 266 82 14 AC 2B 72 7E CF 5F 69 AF E0 C4 DF 2A 6D 2C 268 Iteration count = 2 269 Pass phrase = "password" 270 Salt = "ATHENA.MIT.EDUraeburn" 271 128-bit Camellia key: 272 73 F1 B5 3A A0 F3 10 F9 3B 1D E8 CC AA 0C B1 52 273 256-bit Camellia key: 274 83 FC 58 66 E5 F8 F4 C6 F3 86 63 C6 5C 87 54 9F 275 34 2B C4 7E D3 94 DC 9D 3C D4 D1 63 AD E3 75 E3 277 Iteration count = 1200 278 Pass phrase = "password" 279 Salt = "ATHENA.MIT.EDUraeburn" 280 128-bit Camellia key: 281 8E 57 11 45 45 28 55 57 5F D9 16 E7 B0 44 87 AA 282 256-bit Camellia key: 283 77 F4 21 A6 F2 5E 13 83 95 E8 37 E5 D8 5D 38 5B 284 4C 1B FD 77 2E 11 2C D9 20 8C E7 2A 53 0B 15 E6 286 Iteration count = 5 287 Pass phrase = "password" 288 Salt=0x1234567878563412 289 128-bit Camellia key: 290 00 49 8F D9 16 BF C1 C2 B1 03 1C 17 08 01 B3 81 291 256-bit Camellia key: 292 11 08 3A 00 BD FE 6A 41 B2 F1 97 16 D6 20 2F 0A 293 FA 94 28 9A FE 8B 27 A0 49 BD 28 B1 D7 6C 38 9A 295 Iteration count = 1200 296 Pass phrase = (64 characters) 297 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 298 Salt="pass phrase equals block size" 299 128-bit Camellia key: 300 8B F6 C3 EF 70 9B 98 1D BB 58 5D 08 68 43 BE 05 301 256-bit Camellia key: 302 11 9F E2 A1 CB 0B 1B E0 10 B9 06 7A 73 DB 63 ED 303 46 65 B4 E5 3A 98 D1 78 03 5D CF E8 43 A6 B9 B0 305 Iteration count = 1200 306 Pass phrase = (65 characters) 307 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 308 Salt = "pass phrase exceeds block size" 309 128-bit Camellia key: 310 57 52 AC 8D 6A D1 CC FE 84 30 B3 12 87 1C 2F 74 311 256-bit Camellia key: 312 61 4D 5D FC 0B A6 D3 90 B4 12 B8 9A E4 D5 B0 88 313 B6 12 B3 16 51 09 94 67 9D DB 43 83 C7 12 6D DF 315 Iteration count = 50 316 Pass phrase = g-clef (0xf09d849e) 317 Salt = "EXAMPLE.COMpianist" 318 128-bit Camellia key: 319 CC 75 C7 FD 26 0F 1C 16 58 01 1F CC 0D 56 06 16 320 256-bit Camellia key: 321 16 3B 76 8C 6D B1 48 B4 EE C7 16 3D F5 AE D7 0E 322 20 6B 68 CE C0 78 BC 06 9E D6 8A 7E D3 6B 1E CC 324 Sample results for key derivation: 326 128-bit Camellia key: 327 57 D0 29 72 98 FF D9 D3 5D E5 A4 7F B4 BD E2 4B 328 Kc value for key usage 2 (constant = 0x0000000299): 329 D1 55 77 5A 20 9D 05 F0 2B 38 D4 2A 38 9E 5A 56 330 Ke value for key usage 2 (constant = 0x00000002AA): 331 64 DF 83 F8 5A 53 2F 17 57 7D 8C 37 03 57 96 AB 332 Ki value for key usage 2 (constant = 0x0000000255): 333 3E 4F BD F3 0F B8 25 9C 42 5C B6 C9 6F 1F 46 35 335 256-bit Camellia key: 336 B9 D6 82 8B 20 56 B7 BE 65 6D 88 A1 23 B1 FA C6 337 82 14 AC 2B 72 7E CF 5F 69 AF E0 C4 DF 2A 6D 2C 338 Kc value for key usage 2 (constant = 0x0000000299): 339 E4 67 F9 A9 55 2B C7 D3 15 5A 62 20 AF 9C 19 22 340 0E EE D4 FF 78 B0 D1 E6 A1 54 49 91 46 1A 9E 50 341 Ke value for key usage 2 (constant = 0x00000002AA): 342 41 2A EF C3 62 A7 28 5F C3 96 6C 6A 51 81 E7 60 343 5A E6 75 23 5B 6D 54 9F BF C9 AB 66 30 A4 C6 04 344 Ki value for key usage 2 (constant = 0x0000000255): 345 FA 62 4F A0 E5 23 99 3F A3 88 AE FD C6 7E 67 EB 346 CD 8C 08 E8 A0 24 6B 1D 73 B0 D1 DD 9F C5 82 B0 348 Sample encryptions (all using the default cipher state): 350 Plaintext: (empty) 351 128-bit Camellia key: 352 1D C4 6A 8D 76 3F 4F 93 74 2B CB A3 38 75 76 C3 353 Random confounder: 354 B6 98 22 A1 9A 6B 09 C0 EB C8 55 7D 1F 1B 6C 0A 355 Ciphertext: 356 C4 66 F1 87 10 69 92 1E DB 7C 6F DE 24 4A 52 DB 357 0B A1 0E DC 19 7B DB 80 06 65 8C A3 CC CE 6E B8 359 Plaintext: 1 360 Random confounder: 361 6F 2F C3 C2 A1 66 FD 88 98 96 7A 83 DE 95 96 D9 362 128-bit Camellia key: 363 50 27 BC 23 1D 0F 3A 9D 23 33 3F 1C A6 FD BE 7C 364 Ciphertext: 365 84 2D 21 FD 95 03 11 C0 DD 46 4A 3F 4B E8 D6 DA 366 88 A5 6D 55 9C 9B 47 D3 F9 A8 50 67 AF 66 15 59 367 B8 369 Plaintext: 9 bytesss 370 Random confounder: 371 A5 B4 A7 1E 07 7A EE F9 3C 87 63 C1 8F DB 1F 10 372 128-bit Camellia key: 373 A1 BB 61 E8 05 F9 BA 6D DE 8F DB DD C0 5C DE A0 375 Ciphertext: 376 61 9F F0 72 E3 62 86 FF 0A 28 DE B3 A3 52 EC 0D 377 0E DF 5C 51 60 D6 63 C9 01 75 8C CF 9D 1E D3 3D 378 71 DB 8F 23 AA BF 83 48 A0 380 Plaintext: 13 bytes byte 381 Random confounder: 382 19 FE E4 0D 81 0C 52 4B 5B 22 F0 18 74 C6 93 DA 383 128-bit Camellia key: 384 2C A2 7A 5F AF 55 32 24 45 06 43 4E 1C EF 66 76 385 Ciphertext: 386 B8 EC A3 16 7A E6 31 55 12 E5 9F 98 A7 C5 00 20 387 5E 5F 63 FF 3B B3 89 AF 1C 41 A2 1D 64 0D 86 15 388 C9 ED 3F BE B0 5A B6 AC B6 76 89 B5 EA 390 Plaintext: 30 bytes bytes bytes bytes byt 391 Random confounder: 392 CA 7A 7A B4 BE 19 2D AB D6 03 50 6D B1 9C 39 E2 393 128-bit Camellia key: 394 78 24 F8 C1 6F 83 FF 35 4C 6B F7 51 5B 97 3F 43 395 Ciphertext: 396 A2 6A 39 05 A4 FF D5 81 6B 7B 1E 27 38 0D 08 09 397 0C 8E C1 F3 04 49 6E 1A BD CD 2B DC D1 DF FC 66 398 09 89 E1 17 A7 13 DD BB 57 A4 14 6C 15 87 CB A4 399 35 66 65 59 1D 22 40 28 2F 58 42 B1 05 A5 401 Plaintext: (empty) 402 Random confounder: 403 3C BB D2 B4 59 17 94 10 67 F9 65 99 BB 98 92 6C 404 256-bit Camellia key: 405 B6 1C 86 CC 4E 5D 27 57 54 5A D4 23 39 9F B7 03 406 1E CA B9 13 CB B9 00 BD 7A 3C 6D D8 BF 92 01 5B 407 Ciphertext: 408 03 88 6D 03 31 0B 47 A6 D8 F0 6D 7B 94 D1 DD 83 409 7E CC E3 15 EF 65 2A FF 62 08 59 D9 4A 25 92 66 411 Plaintext: 1 412 Random confounder: 413 DE F4 87 FC EB E6 DE 63 46 D4 DA 45 21 BB A2 D2 414 256-bit Camellia key: 415 1B 97 FE 0A 19 0E 20 21 EB 30 75 3E 1B 6E 1E 77 416 B0 75 4B 1D 68 46 10 35 58 64 10 49 63 46 38 33 417 Ciphertext: 418 2C 9C 15 70 13 3C 99 BF 6A 34 BC 1B 02 12 00 2F 419 D1 94 33 87 49 DB 41 35 49 7A 34 7C FC D9 D1 8A 420 12 422 Plaintext: 9 bytesss 423 Random confounder: 424 AD 4F F9 04 D3 4E 55 53 84 B1 41 00 FC 46 5F 88 425 256-bit Camellia key: 426 32 16 4C 5B 43 4D 1D 15 38 E4 CF D9 BE 80 40 FE 427 8C 4A C7 AC C4 B9 3D 33 14 D2 13 36 68 14 7A 05 428 Ciphertext: 429 9C 6D E7 5F 81 2D E7 ED 0D 28 B2 96 35 57 A1 15 430 64 09 98 27 5B 0A F5 15 27 09 91 3F F5 2A 2A 9C 431 8E 63 B8 72 F9 2E 64 C8 39 433 Plaintext: 13 bytes byte 434 Random confounder: 435 CF 9B CA 6D F1 14 4E 0C 0A F9 B8 F3 4C 90 D5 14 436 256-bit Camellia key: 437 B0 38 B1 32 CD 8E 06 61 22 67 FA B7 17 00 66 D8 438 8A EC CB A0 B7 44 BF C6 0D C8 9B CA 18 2D 07 15 439 Ciphertext: 440 EE EC 85 A9 81 3C DC 53 67 72 AB 9B 42 DE FC 57 441 06 F7 26 E9 75 DD E0 5A 87 EB 54 06 EA 32 4C A1 442 85 C9 98 6B 42 AA BE 79 4B 84 82 1B EE 444 Plaintext: 30 bytes bytes bytes bytes byt 445 Random confounder: 446 64 4D EF 38 DA 35 00 72 75 87 8D 21 68 55 E2 28 447 256-bit Camellia key: 448 CC FC D3 49 BF 4C 66 77 E8 6E 4B 02 B8 EA B9 24 449 A5 46 AC 73 1C F9 BF 69 89 B9 96 E7 D6 BF BB A7 450 Ciphertext: 451 0E 44 68 09 85 85 5F 2D 1F 18 12 52 9C A8 3B FD 452 8E 34 9D E6 FD 9A DA 0B AA A0 48 D6 8E 26 5F EB 453 F3 4A D1 25 5A 34 49 99 AD 37 14 68 87 A6 C6 84 454 57 31 AC 7F 46 37 6A 05 04 CD 06 57 14 74 456 Sample checksums: 458 Plaintext: abcdefghijk 459 Checksum type: cmac-camellia128 460 128-bit Camellia key: 461 1D C4 6A 8D 76 3F 4F 93 74 2B CB A3 38 75 76 C3 462 Key usage: 7 463 Checksum: 464 11 78 E6 C5 C4 7A 8C 1A E0 C4 B9 C7 D4 EB 7B 6B 466 Plaintext: ABCDEFGHIJKLMNOPQRSTUVWXYZ 467 Checksum type: cmac-camellia128 468 128-bit Camellia key: 469 50 27 BC 23 1D 0F 3A 9D 23 33 3F 1C A6 FD BE 7C 470 Key usage: 8 471 Checksum: 472 D1 B3 4F 70 04 A7 31 F2 3A 0C 00 BF 6C 3F 75 3A 474 Plaintext: 123456789 475 Checksum type: cmac-camellia256 476 256-bit Camellia key: 477 B6 1C 86 CC 4E 5D 27 57 54 5A D4 23 39 9F B7 03 478 1E CA B9 13 CB B9 00 BD 7A 3C 6D D8 BF 92 01 5B 479 Key usage: 9 480 Checksum: 481 87 A1 2C FD 2B 96 21 48 10 F0 1C 82 6E 77 44 B1 483 Plaintext: !@#$%^&*()!@#$%^&*()!@#$%^&*() 484 Checksum type: cmac-camellia256 485 256-bit Camellia key: 486 32 16 4C 5B 43 4D 1D 15 38 E4 CF D9 BE 80 40 FE 487 8C 4A C7 AC C4 B9 3D 33 14 D2 13 36 68 14 7A 05 488 Key usage: 10 489 Checksum: 490 3F A0 B4 23 55 E5 2B 18 91 87 29 4A A2 52 AB 64 492 11. References 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of 498 the Camellia Encryption Algorithm", RFC 3713, April 2004. 500 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 501 Kerberos 5", RFC 3961, February 2005. 503 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 504 Encryption for Kerberos 5", RFC 3962, February 2005. 506 [SP800-38B] 507 Dworkin, M., "Recommendation for Block Cipher Modes of 508 Operation: The CMAC Mode for Authentication", NIST Special 509 Publication 800-38B, October 2009. 511 [SP800-108] 512 Chen, L., "Recommendation for Key Derivation Using 513 Pseudorandom Functions", NIST Special Publication 800-108, 514 October 2009. 516 [CRYPTOENG] 517 Schneier, B., "Cryptography Engineering", March 2010. 519 Author's Address 521 Greg Hudson (editor) 522 MIT Kerberos Consortium 524 Email: ghudson@mit.edu