idnits 2.17.1 draft-reeder-snmpv3-usm-3desede-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages 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. ** There are 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC2574]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (6 October 1999) is 8967 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) == Missing Reference: 'MULTI-CRYPT' is mentioned on line 1152, but not defined == Missing Reference: 'DIFF-ANALYSIS' is mentioned on line 1144, but not defined == Missing Reference: 'LIN-ANALYSIS' is mentioned on line 1148, but not defined == Missing Reference: 'DESMODES' is mentioned on line 1140, but not defined == Unused Reference: 'IETF-CRYPTO' is defined on line 847, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3DES-ANSI' -- Possible downref: Non-RFC (?) normative reference: ref. '3DES-NIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESG-NIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESO-ANSI' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESO-NIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESM-NIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'DEST-NIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'ESP-3DES' -- Possible downref: Non-RFC (?) normative reference: ref. 'IETF-CRYPTO' -- Possible downref: Non-RFC (?) normative reference: ref. 'LOCALIZED-KEY' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIN-KEYLENGTH' -- Possible downref: Non-RFC (?) normative reference: ref. 'PLAIN-ANALYSIS' ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHNEIER95' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SNMPv3 Working Group David Reeder 2 INTERNET-DRAFT NAI Labs 3 Olafur Gudmundsson 4 NAI Labs 5 6 October 1999 7 Extension to the User-Based Security Model (USM) to 8 Support Triple-DES EDE in "Outside" CBC Mode 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document describes an extension to the the User-based Security 35 Model (USM) [RFC2574]. It defines the Elements of Procedure for 36 providing SNMP message level security for a privacy protocol using 37 Triple-DES EDE in "Outside" Cipher-Block Chaining (CBC) mode. This 38 document also extends the existing SNMPv3 MIBs in order to remotely 39 monitor and manage the configuration parameters for this privacy 40 protocol of the USM. 42 Copyright Notice 44 Copyright (C) The Internet Society (1999). All Rights Reserved. 46 Table of Contents 48 1. Introduction 2 49 2. Use of Password-to-Key Algorithm with 3DES-EDE 5 50 2.1 Chaining of the Password-to-Key Algorithm 5 51 2.2 Password (P) versus Ku versus the localized key Kul 6 52 3. Use of SNMP-USER-BASED-SM-3DES-MIB MIB Module 7 53 4. Definitions 8 54 5. 3DES-EDE Symmetric Encryption Protocol 11 55 5.1. Mechanisms 11 56 5.1.1. Symmetric Encryption Protocol 11 57 5.1.1.1. 3DES-EDE Key and Initialization Vector 12 58 5.1.1.1.1. 3DES-EDE Key 12 59 5.1.1.1.2. 3DES-EDE Initialization Vector 13 60 5.1.1.2. Data Encryption 14 61 5.1.1.3. Data Decryption 15 62 5.2. Elements of the 3DES-EDE Privacy Protocol 16 63 5.2.1. Users 16 64 5.2.2. msgAuthoritativeEngineID 16 65 5.2.3. SNMP Messages Using this Privacy Protocol 17 66 5.2.4. Services provided by the 3DES-EDE Privacy Module 17 67 5.2.4.1. Services for Encrypting Outgoing Data 17 68 5.2.4.2. Services for Decrypting Incoming Data 18 69 5.3. Elements of Procedure 19 70 5.3.1. Processing an Outgoing Message 19 71 5.3.2. Processing an Incoming Message 19 72 6. Security Considerations 20 73 7. Acknowledgements 20 74 8. Intellectual Property 20 75 9. References 21 76 10. Editors' Addresses 23 77 11. Full Copyright Statement 24 78 A. SNMP engine Installation Parameters Using 3DES-EDE 24 79 B. Password-to-Key Chaining Sample Results 25 80 B.1. Password-to-Key Chaining Sample Results using MD5 25 81 B.2. Password-to-Key Chaining Sample Results using SHA 26 82 C. Sample keyChange Results 26 83 C.1. Sample keyChange Results using MD5 26 84 C.2. Sample keyChange Results using SHA 27 85 D.1. Strength of 3DES-EDE and Known Attacks 28 86 D.2. Further References 29 88 1. Introduction 90 The Architecture for describing Internet Management Frameworks 91 [RFC2571] describes that an SNMP engine is composed of: 93 1) a Dispatcher 94 2) a Message Processing Subsystem, 95 3) a Security Subsystem, and 96 4) an Access Control Subsystem. 98 Applications make use of the services of these subsystems. 100 It is important to understand the SNMP architecture and the 101 terminology of the architecture to understand where the extensions to 102 the Security Model described in this document fit into the 103 architecture and interact with other subsystems within the 104 architecture. The reader is expected to have read and understood the 105 description of the SNMP architecture and the User-Based Security 106 Model (USM), as defined in [RFC2571] and [RFC2574], respectively. 108 This memo describes an extension to the User-based Security Model 109 which defines the 3DES-EDE privacy protocol using Triple-DES EDE in 110 "Outside" CBC mode. "EDE" is one method of triple encryption which 111 simply varies the "direction" that the single DES algorithm is used 112 in each iteration -- first encrypting, then decrypting, and finally 113 encrypting again. Since the second decryption uses a different key 114 than the first encryption, the decryption iteration serves to further 115 encrypt the data. 117 This extension adds to, but does not otherwise change, the details 118 describing the use of privacy protocols in the USM. Further, it 119 makes no changes to the remainder of the USM, and adopts all its 120 assumptions, supporting concepts and apparatus. It is expected that 121 this document alone will provide all necessary details necessary for 122 the immediate integration and use of 3DES-EDE into the existing USM 123 subsystem. 125 In particular, the following aspects of the USM are adopted in their 126 entirety, without modification, by the 3DES-EDE extension: 128 - Abstract Service Interface describing the User-based 129 Security Model primitives for privacy, 131 - Format of SNMP messages using the User-based Security Model, 133 - Password-to-key key localization algorithm, 135 - Services for generating an outgoing SNMP Message, and for 136 processing an incoming SNMP message, 138 - Existing USM security considerations including: 139 * Recommended practices 140 * Defining users 141 * Conformance 142 * Use of reports 143 * Access to the SNMP-USER-BASED-SM-MIB. 145 Note that some details surrounding the use of the password-to-key 146 algorithm for key localization are necessarily changed when using 147 this extension in order to provide for the larger number of bits 148 required by the 3DES-EDE cryptographic key. The key localization 149 algorithm as specified in the USM as the password-to-key algorithm 150 has not changed, however. (See [LOCALIZED-KEY] for the original 151 definition.) 153 In addition, while users may specify passphrases of any length, the 154 maximum length of keying material used by the SNMP engine is limited 155 to the length of the largest hash generated by the currently 156 specified authentication protocols. Some effort should be taken to 157 provide for key lengths greater than this protocols provide. Work in 158 this regard, however, is outside the scope of this document. 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 2. Use of Password-to-Key Algorithm with 3DES-EDE 166 A set of sample code fragments given in the USM document demonstrate 167 the password-to-key algorithm which can be used to map a password to 168 a privacy key using MD5 or SHA. 170 2.1 Chaining of the Password-to-Key Algorithm 172 Some cryptographic algorithms may require keys that have a length 173 greater than the that of the hash output used by the password-to-key 174 algorithm. This will be the case, for example, with any user that 175 defines usm3DESEDEPrivProtocol as its privacy protocol (described 176 below in Section 6). To acquire the necessary number of key bits, 177 the password-to-key algorithm may be chained using its own output as 178 further input in order to generate an appropriate number of key bits. 180 Chaining is described as follows. First, run the password-to-key 181 algorithm with inputs of the passphrase and engineID as described in 182 the USM document. This will output as many key bits as the hash 183 algorithm used to implement the password-to-key algorithm. Secondly, 184 run the password-to-key algorithm again with the previous output 185 (instead of the passphrase) and the same engineID as inputs. Repeat 186 this process as many times as necessary in order to generate the 187 minimum number of key bits for the chosen privacy protocol. The 188 outputs of each execution are concatenated into a single string of 189 key bits. 191 When this process results in more key bits than are necessary, only 192 the most significant bits of the string should be used. 194 For example, if password-to-key implemented with SHA creates a 195 40-octet string string for use as key bits, only the first 32 octets 196 will be used for usm3DESEDEPrivProtocol. 198 Chaining may be demonstrated using simplified pseudo-code as follows, 199 let: 201 Output_bits <-- P2K( Input_bits, EngineID ) 203 where the string of key bits (Output_bits) is returned from the 204 password-to-key (P2K) algorithm which takes a string of bits 205 (Input_bits) and the engineID (EngineID) as inputs. One iteration of 206 chaining, creating a localized key of twice the normal length is 207 achieved as follows: 209 K1 <-- P2K( , ) 210 K2 <-- P2K( K1, ) 212 localized_key = K1 | K2 214 The next further iteration will pass K2 (instead of K1) and return 215 K3. The iteration after that passes K3 and returns K4, etc. The 216 results of all iterations (K1, K2, ..., Kn) are concatenated to form 217 the localized key. Note that the engineID is the same for all 218 iterations. 220 An example of the results of a correct implementation is provided in 221 Appendix B. 223 2.2 Password (P) versus Ku versus the localized key Kul 225 It is important to note that using the chaining method confuses the 226 simple relationship between the passphrase, Ku and the localized key, 227 Kul described in the USM document. It is believed that this should 228 pose no significant difficulty to for existing USM implementations, 229 however. 231 The password-to-key algorithm performs two actions. First, it 232 derives Ku from P by expanding P to 1024 kilobytes and hashing the 233 result. Second, it derives Kul from Ku by hashing a concatenation of 234 Ku and engineID. This latter step constitutes the localization 235 method. 237 Normally, Ku is temporarily generated within the password-to-key 238 algorithm only for use in generating Kul, and it is expected that Ku 239 will be discarded after this use. When the password-to-key algorithm 240 is chained as described in Section 2.1, the final string of key bits 241 output is no longer directly derived from P through Ku. Further 242 there is no longer a one-to-one mapping between P and Ku, and from Ku 243 to Kul. Nonetheless, the cryptographic mixing and uniqifying 244 function provided by chaining the password-to-key algorithm serves 245 the same purpose as a single use of the password-to-key algorithm. 247 Alternatives to the chaining method might require the password-to-key 248 algorithm to take an input indicating the number of key bits desired, 249 allowing the algorithm to perform the entire chaining operation (or 250 some other pseudo-random number generation technique). 252 The benefits of chaining the password-to-key algorithm, effectively 253 using it "as is," include the following: 255 - Should be simpler for existing implementations to adapt to 256 the longer 3DES-EDE key length with a minimum of changes. 258 - No need to document and define a choice between the existing 259 password-to-key algorithm and some new algorithm. 261 The drawbacks of the described chaining method include: 263 - The notion of Ku and its relationship to P and Kul is confused. 265 - Network management stations that insist on storing Ku 266 will have to store the passphrase (P) instead. 268 Note that storing P poses the same security risks as storing Ku. 270 - A new algorithm could be optimized to save at least one hashing 271 operation per chaining cycle. 273 3. Use of SNMP-USER-BASED-SM-3DES-MIB MIB Module 275 The current purpose of the SNMP-USER-BASED-SM-3DES-MIB MIB module is 276 simply to define the OBJECT-IDENTITY usm3DESEDEPrivProtocol. This 277 adds to but does not change the { snmpModules snmpFrameworkMIB } MIB 278 module [RFC2571] by naming a new privacy protocol. 280 This naming takes place within the context of the USM { snmpModules 281 snmpUsmMIB } MIB module where other privacy protocols have previously 282 been defined. When the 3DES-EDE privacy protocol is used, a size of 283 SIZE(0 | 64) is recommended for use with the following OBJECT-TYPEs: 285 { usmUserEntry usmUserPrivKeyChange } 286 { usmUserEntry usmUserOwnPrivKeyChange }. 288 4. Definitions 289 SNMP-USER-BASED-SM-3DES-MIB DEFINITIONS ::= BEGIN 291 IMPORTS 292 MODULE-IDENTITY, OBJECT-IDENTITY, 293 snmpModules FROM SNMPv2-SMI 294 AutonomousType FROM SNMPv2-TC 295 snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB; 297 snmpUsmMIB MODULE-IDENTITY 298 LAST-UPDATED "9910060000Z" -- 06 October 1999, midnight 299 ORGANIZATION "SNMPv3 Working Group" 300 CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com 301 Subscribe: majordomo@lists.tislabs.com 302 In msg body: subscribe snmpv3 304 Chair: Russ Mundy 305 NAI Labs 306 postal: 3060 Washington Rd 307 Glenwood MD 21738 308 USA 309 email: mundy@tislabs.com 310 phone: +1-443-259-2307 312 Co-editor: David Reeder 313 NAI Labs 314 postal: 3060 Washington Road (Route 97) 315 Glenwood, MD 21738 316 USA 317 email: dreeder@tislabs.com 318 phone: +1-443-259-2348 320 Co-editor: Olafur Gudmundsson 321 NAI Labs 322 postal: 3060 Washington Road (Route 97) 323 Glenwood, MD 21738 324 USA 325 email: ogud@tislabs.com 326 phone: +1-443-259-2389 327 " 328 DESCRIPTION "Extension to the SNMP User-based Security Model 329 to support Triple-DES EDE in 'Outside' CBC 330 (cipher-block chaining) Mode. 331 " 332 -- Revision history 333 REVISION "9910060000Z" -- 06 October 1999, midnight 334 DESCRIPTION "Initial version, published as an Internet Draft." 336 ::= { snmpModules 15 } 338 -- Identification of Privacy Protocols ******************************* 340 -- Note: { snmpPrivProtocols 1 } through { snmpPrivProtocols 2 } 341 -- are defined in USM. 343 usm3DESEDEPrivProtocol OBJECT-IDENTITY 344 STATUS current 345 DESCRIPTION "The 3DES-EDE Symmetric Encryption Protocol." 346 REFERENCE "- Data Encryption Standard, National Institute of 347 Standards and Technology. Federal Information 348 Processing Standard (FIPS) Publication 46-3, 349 (1999, 350 pending approval). Will supersede FIPS 351 Publication 352 46-2. 354 - Data Encryption Algorithm, American National 355 Standards Institute. ANSI X3.92-1981, 356 (December, 1980). 358 - DES Modes of Operation, National Institute of 359 Standards and Technology. Federal Information 360 Processing Standard (FIPS) Publication 81, 361 (December, 1980). 363 - Data Encryption Algorithm - Modes of Operation, 364 American National Standards Institute. 365 ANSI X3.106-1983, (May 1983). 366 " 367 ::= { snmpPrivProtocols 3 } 369 END 371 5. 3DES-EDE Symmetric Encryption Protocol 373 This section describes the 3DES-EDE Symmetric Encryption Protocol. 374 This protocol is an optional privacy protocol defined for use with 375 the User-based Security Model. 377 This protocol is identified by usm3DESEDEPrivProtocol. 379 Over time, other privacy protocols may be defined either as a 380 replacement of this protocol or in addition to this protocol. 382 5.1. Mechanisms 384 - In support of data confidentiality, an encryption algorithm is 385 required. An appropriate portion of the message is encrypted prior 386 to being transmitted. The User-based Security Model specifies that 387 the scopedPDU is the portion of the message that needs to be 388 encrypted. 390 - A secret value in combination with a timeliness value is used 391 to create the en/decryption key and the initialization vector. The 392 secret value is shared by all SNMP engines authorized to originate 393 messages on behalf of the appropriate user. 395 5.1.1. Symmetric Encryption Protocol 397 The Symmetric Encryption Protocol defined here provides support for 398 data confidentiality. The designated portion of an SNMP message is 399 encrypted and included as part of the message sent to the recipient. 401 Two organizations have published specifications defining 3DES-EDE: 402 the National Institute of Standards and Technology (NIST) [3DES-NIST] 403 and the American National Standards Institute [3DES-ANSI]. There is 404 a companion Modes of Operation specification for each definition 405 ([DESO-NIST] and [DESO-ANSI], respectively). Additional information 406 about 3DES-EDE may be found in [SCHNEIER95] (see Chapter 12 and 407 Section 15.2). 409 The NIST has published three additional documents that implementors 410 may find useful. Although these documents were written with (single) 411 DES in mind, they may be adapted to the use of 3DES-EDE. 413 - There is a document with guidelines for implementing and using 414 the DES, including functional specifications for the DES and its 415 modes of operation [DESG-NIST]. 417 - There is a specification of a validation test suite for the DES 418 [DEST-NIST]. The suite is designed to test all aspects of the DES 419 and is useful for pinpointing specific problems. 421 - There is a specification of a maintenance test for the DES 422 [DESM-NIST]. The test utilizes a minimal amount of data and 423 processing to test all components of the DES. It provides a simple 424 yes-or-no indication of correct operation and is useful to run as 425 part of an initialization step, e.g., when a computer re-boots. 427 5.1.1.1. 3DES-EDE Key and Initialization Vector 429 5.1.1.1.1. 3DES-EDE Key 431 The first 24 octets of the 32-octet secret (private privacy key) are 432 used as a 3DES-EDE key. Since 3DES-EDE uses only 168 bits, the Least 433 Significant Bit in each octet is disregarded. 435 The 3DES-EDE subkeys are obtained in the following 436 manner. 438 The 24-octet sequence is divided into three smaller 8-octet sequences 439 where bytes 1 through 8 define K1, bytes 9 through 16 define K2, and 440 bytes 17 through 24 define K3. For each 8-octet sequence, bytes are 441 assigned to its respective subkey from left to right, beginning with 442 the most significant byte and extending to the least significant 443 byte. 445 The three subkeys MUST be verified to be different. This may be done 446 by checking that K1 is not equal to K2, and that K2 is not equal to 447 K3. This will guarantee that at least two of the three subkeys are 448 different. To verify that all three subkeys are different, it SHOULD 449 be verified in addition that K1 is not equal to K3. The first set of 450 checks verifies that the whole key contains at least 112 bits, the 451 second check verifies that the whole key contains 168 bits. For a 452 stronger key it is advised that both checks are performed. 454 There are no published attacks against 3DES-EDE that take advantage 455 of using "weak keys" for any of K1, K2 or K3. The list of weak keys 456 includes the semi-weak and possibly-weak keys. It is generally 457 accepted that 3DES-EDE is resistant to attacks using these keys, 458 unlike single DES. Nonetheless, since the list of weak keys is 459 small, it is advised that each of the subkeys SHOULD be checked for 460 membership in this list. The complete list of known weak keys is 461 given in [SCHNEIER95]. 463 The checks for difference and weakness noted above should be 464 performed when the key is assigned. If any of the mandated tests 465 fail, then the whole key MUST be discarded and an appropriate 466 exception noted. 468 5.1.1.1.2. 3DES-EDE Initialization Vector 470 The Initialization Vector for encryption is obtained using the 471 following procedure. 473 The last 8 octets of the 32-octet secret (private privacy key) are 474 used as pre-IV. 476 In order to ensure that the IV for two different packets encrypted by 477 the same key, are not the same (i.e., the IV does not repeat over the 478 lifetime of the private key) we need to "salt" the pre-IV with 479 something unique per packet. An 8-octet string is used as the 480 "salt". The concatenation of the generating SNMP engine's 32-bit 481 snmpEngineBoots and a local 32-bit integer, that the encryption 482 engine maintains, is input to the "salt". The 32-bit integer is 483 initialized to an arbitrary value at boot time. 485 This 32-bit arbitrary integer SHOULD be randomly determined when the 486 engine boots. This is in keeping with the recommendations given in 487 [RFC1750] and [PLAIN-ANALYSIS] with regard to the generation of 488 random numbers and the use of predictable plaintext to speed a 489 cryptographic search for a secret key. 491 If the arbitrary integer cannot be chosen randomly, it is suggested 492 instead that it SHOULD be derived from a hardware clock, or from 493 system.sysUpTime.0 if a hardware clock is not available. These 494 options are preferable to a simple counter as periodic use of it will 495 not describe a direct sequence of natural numbers. 497 The 32-bit snmpEngineBoots is converted to the first 4 octets (Most 498 Significant Byte first) of our "salt". The 32-bit integer is then 499 converted to the last 4 octets (Most Significant Byte first) of our 500 "salt". 502 To achieve effective bit spreading, the complete 8-octet "salt" value 503 SHOULD be hashed using the usmUserAuthProtocol. This may be 504 performed using the authentication algorithm directly, or by passing 505 the "salt" as input the the password-to-key algorithm. The result of 506 the hash is truncated to 8 octets. 508 The resulting "salt" is then XOR-ed with the pre-IV to obtain the IV. 509 The 8-octet "salt" is then put into the privParameters field encoded 510 as an OCTET STRING. 512 Finally, the "salt" value is updated in preparation for future use, 513 possibly using one of the methods just described. How exactly the 514 value of the "salt" varies (and thus the value of the IV), is an 515 implementation issue, as long as the measures are taken to avoid 516 producing a duplicate IV over the lifetime of the private key. 518 The "salt" must be placed in the privParameters field to enable the 519 receiving entity to compute the correct IV and to decrypt the 520 message. 522 5.1.1.2. Data Encryption 524 The data to be encrypted is treated as sequence of octets. Its 525 length should be an integral multiple of 8 - and if it is not, the 526 data is padded at the end as necessary. The actual pad value is 527 irrelevant. 529 The data is encrypted using Triple DES Encryption - Decryption - 530 Encryption (EDE) in Outside Cipher Block Chaining (CBC) mode. 532 The plaintext is divided into 64-bit blocks. A single block of 533 plaintext is encrypted by performing a sequence of encryption with 534 the first key (K1), followed by decryption of the previous result 535 with the second key (K2), finally followed by encryption of the 536 previous result with the final key (K3). 538 The plaintext for each block is XOR-ed with the ciphertext of the 539 previous EDE encryption, the result is EDE encrypted and the output 540 of the encryption is the ciphertext for the block. This procedure is 541 repeated until there are no more plaintext blocks. 543 For the very first block, the Initialization Vector (IV) is used 544 instead of the ciphertext of the previous block. 546 This is expressed more succinctly by the following formula: 548 Ci = E_K3( D_K2( E_K1( Pi XOR C(i-1) ) ) ) 550 Where plaintext block number i is XOR-ed with ciphertext block number 551 (i-1), then encrypted with K1, decrypted with K2, and encrypted again 552 with K3 to give ciphertext block number i. For the first EDE 553 encryption, C(i-1) is replaced by the IV. A more thorough 554 explanation may be found in [SCHNEIER95]. 556 5.1.1.3. Data Decryption 558 Before decryption, the encrypted data length is verified. If the 559 length of the OCTET STRING to be decrypted is not an integral 560 multiple of 8 octets, the decryption process is halted and an 561 appropriate exception noted. When decrypting, the padding is 562 ignored. 564 The first ciphertext block is decrypted, the decryption output is 565 XOR-ed with the Initialization Vector, and the result is the first 566 plaintext block. 568 A single ciphertext block is decrypted by performing a sequence of 569 decryption with the third key (K3), followed by encryption of the 570 previous result with the second key (K2), finally followed by 571 decryption of the previous result with the first key (K1). This 572 cycle of decryption - encryption - decryption (DED) is the reverse of 573 the EDE sequence used for encryption. 575 For each subsequent block, the ciphertext block is DED decrypted, 576 then the decryption output is XOR-ed with the previous ciphertext 577 block and the result is the plaintext block. 579 This is expressed more succinctly by the following formula: 581 Pi = C(i-1) XOR D_K1( E_K2( D_K3( Ci ) ) ) 583 Where ciphertext block number i is decrypted with K3, then encrypted 584 with K2, then decrypted with K1 and finally XOR-ed with ciphertext 585 block (i-1) to give plaintext block number i. For the first 586 ciphertext block of the series, C(i-1) is replaced by the IV. A more 587 thorough explanation may be found in [SCHNEIER95]. 589 5.2. Elements of the 3DES-EDE Privacy Protocol 591 This section contains definitions required to realize the privacy 592 module defined by this memo. 594 5.2.1. Users 596 Data en/decryption using this Symmetric Encryption Protocol makes use 597 of a defined set of userNames. For any user on whose behalf a 598 message must be en/decrypted at a particular SNMP engine, that SNMP 599 engine must have knowledge of that user. An SNMP engine that wishes 600 to communicate with another SNMP engine must also have knowledge of a 601 user known to that SNMP engine, including knowledge of the applicable 602 attributes of that user. 604 A user and its attributes are defined as follows: 606 607 An octet string representing the name of the user. 609 610 A user's secret key to be used as input for the 3DES-EDE key and 611 IV. The length of this key MUST be 32 octets. 613 5.2.2. msgAuthoritativeEngineID 615 The msgAuthoritativeEngineID value contained in an authenticated 616 message specifies the authoritative SNMP engine for that particular 617 message (see the definition of SnmpEngineID in the SNMP Architecture 618 document [RFC2571]). 620 The user's (private) privacy key is normally different at each 621 authoritative SNMP engine and so the snmpEngineID is used to select 622 the proper key for the en/decryption process. 624 5.2.3. SNMP Messages Using this Privacy Protocol 626 Messages using this privacy protocol carry a msgPrivacyParameters 627 field as part of the msgSecurityParameters. For this protocol, the 628 msgPrivacyParameters field is the serialized OCTET STRING 629 representing the "salt" that was used to create the IV. 631 5.2.4. Services provided by the 3DES-EDE Privacy Module 633 This section describes the inputs and outputs that the 3DES-EDE 634 Privacy module expects and produces when the User-based Security 635 module invokes the 3DES-EDE Privacy module for services. 637 5.2.4.1. Services for Encrypting Outgoing Data 639 This 3DES-EDE privacy protocol assumes that the selection of the 640 privKey is done by the caller and that the caller passes the secret 641 key to be used. 643 Upon completion the privacy module returns statusInformation and, if 644 the encryption process was successful, the encryptedPDU and the 645 msgPrivacyParameters encoded as an OCTET STRING. The abstract 646 service primitive is: 648 statusInformation = -- success of failure 649 encryptData( 650 IN encryptKey -- secret key for encryption 651 IN dataToEncrypt -- data to encrypt (scopedPDU) 652 OUT encryptedData -- encrypted data (encryptedPDU) 653 OUT privParameters -- filled in by service provider 654 ) 656 The abstract data elements are: 658 statusInformation 659 An indication of the success or failure of the encryption 660 process. In case of failure, it is an indication of the error. 661 encryptKey 662 The secret key to be used by the encryption algorithm. 663 The length of this key MUST be 32 octets. 664 dataToEncrypt 665 The data that must be encrypted. 666 encryptedData 667 The encrypted data upon successful completion. 668 privParameters 669 The privParameters encoded as an OCTET STRING. 671 5.2.4.2. Services for Decrypting Incoming Data 673 This 3DES-EDE privacy protocol assumes that the selection of the 674 privKey is done by the caller and that the caller passes the secret 675 key to be used. 677 Upon completion the privacy module returns statusInformation and, if 678 the decryption process was successful, the scopedPDU in plain text. 679 The abstract service primitive is: 681 statusInformation = 682 decryptData( 683 IN decryptKey -- secret key for decryption 684 IN privParameters -- as received on the wire 685 IN encryptedData -- encrypted data (encryptedPDU) 686 OUT decryptedData -- decrypted data (scopedPDU) 687 ) 689 The abstract data elements are: 691 statusInformation 692 An indication whether the data was successfully decrypted 693 and if not an indication of the error. 694 decryptKey 695 The secret key to be used by the decryption algorithm. 696 The length of this key MUST be 32 octets. 697 encryptedData 698 The data to be decrypted. 699 decryptedData 700 The decrypted data. 701 privParameters 702 The "salt" to be used to calculate the IV. 704 5.3. Elements of Procedure 706 This section describes the procedures for the 3DES-EDE privacy 707 protocol. 709 5.3.1. Processing an Outgoing Message 711 This section describes the procedure followed by an SNMP engine 712 whenever it must encrypt part of an outgoing message using the 713 usm3DESEDEPrivProtocol. 715 1) The secret cryptKey is used to construct the 3DES-EDE encryption 716 key, the "salt" and the 3DES-EDE pre-IV (from which the IV is 717 computed as described in section 5.1.1.1.2). 719 2) The privParameters field is set to the serialization according 720 to the rules in [RFC1906] of an OCTET STRING representing the the 721 "salt" string. 723 3) The scopedPDU is encrypted (as described in section 5.1.1.2) 724 and the encrypted data is serialized according to the rules in 725 [RFC1906] as an OCTET STRING. 727 4) The serialized OCTET STRING representing the encrypted 728 scopedPDU together with the privParameters and statusInformation 729 indicating success is returned to the calling module. 731 5.3.2. Processing an Incoming Message 733 This section describes the procedure followed by an SNMP engine 734 whenever it must decrypt part of an incoming message using the 735 usm3DESEDEPrivProtocol. 737 1) If the privParameters field is not an 8-octet OCTET STRING, 738 then an error indication (decryptionError) is returned to the 739 calling module. 741 2) The "salt" is extracted from the privParameters field. 743 3) The secret cryptKey and the "salt" are then used to construct the 744 3DES-EDE decryption key and pre-IV (from which the IV is computed 745 as described in section 5.1.1.1.2). 747 4) The encryptedPDU is then decrypted (as described in 748 section 5.1.1.3). 750 5) If the encryptedPDU cannot be decrypted, then an error 751 indication (decryptionError) is returned to the calling module. 753 6) The decrypted scopedPDU and statusInformation indicating 754 success are returned to the calling module. 756 6. Security Considerations 758 This document fully adopts and expects enforcement of the details 759 presented in the Security Considerations section of the document 760 describing the User-based Security Model [RFC2574]. 762 Insofar as the privacy protocol presented in this document is 763 considered to be an improvement over existing SNMP privacy protocols, 764 this document presents an alternative offering greater security for 765 the SNMP architecture. 767 7. Acknowledgements 769 The general structure of this document and some of the text in it was 770 taken directly from the document describing the User-based Security 771 Model. Many details and references specific to the strength and 772 analysis of the Triple-DES cryptographic algorithm were initially 773 adapted from the description of that algorithm given in documents 774 generated by the IPSec Working Group concerning the Encapsulation 775 Security Protocol [ESP-DESCBC][ESP-3DES]. 777 8. Intellectual Property 779 The IETF takes no position regarding the validity or scope of any 780 intellectual property or other rights that might be claimed to 781 pertain to the implementation or use of the technology described in 782 this document or the extent to which any license under such rights 783 might or might not be available; neither does it represent that it 784 has made any effort to identify any such rights. Information on the 785 IETF's procedures with respect to rights in standards-track and 786 standards-related documentation can be found in BCP-11. Copies of 787 claims of rights made available for publication and any assurances of 788 licenses to be made available, or the result of an attempt made to 789 obtain a general license or permission for the use of such 790 proprietary rights by implementors or users of this specification can 791 be obtained from the IETF Secretariat. 793 The IETF invites any interested party to bring to its attention any 794 copyrights, patents or patent applications, or other proprietary 795 rights which may cover technology that may be required to practice 796 this standard. Please address the information to the IETF Executive 797 Director. 799 9. References 801 [3DES-ANSI] Data Encryption Algorithm, American National 802 Standards Institute. ANSI X9.52. 804 [3DES-NIST] Data Encryption Standard, National Institute of 805 Standards and Technology. Federal Information 806 Processing Standard (FIPS) Publication 46-3, (1999, 807 pending approval). Will supersede FIPS Publication 808 46-2. http://csrc.nist.gov/fips/dfips46-3.pdf 809 http://csrc.nist.gov/cryptval/des/fr990115.htm 811 [DESG-NIST] Guidelines for Implementing and Using the NBS Data 812 Encryption Standard, National Institute of 813 Standards and Technology. Federal Information 814 Processing Standard (FIPS) Publication 74, (April, 815 1981). http://www.itl.nist.gov/fipspubs/fip74.htm 817 [DESO-ANSI] Data Encryption Algorithm - Modes of Operation, 818 American National Standards Institute. ANSI 819 X3.106- 1983, (May 1983). 821 [DESO-NIST] DES Modes of Operation, National Institute of 822 Standards and Technology. Federal Information 823 Processing Standard (FIPS) Publication 81, 824 (December, 1980). 825 http://www.itl.nist.gov/fipspubs/fip81.htm 827 [DESM-NIST] Maintenance Testing for the Data Encryption 828 Standard, National Institute of Standards and 829 Technology. Special Publication 500-61, (August, 830 1980). 832 [DEST-NIST] Validating the Correctness of Hardware 833 Implementations of the NBS Data Encryption 834 Standard, National Institute of Standards and 835 Technology. Special Publication 500-20. 837 [ESP-DESCBC] Madson, C. and N. Dorswamy, "The ESP DES-CBC Cipher 838 Algorithm With Explicit IV", RFC 2405, November 839 1998. 841 [ESP-3DES] Doraswamy, N., Metzger, P., and Simpson, W.A., "The 842 ESP Triple DES Transform", , July 1997. 844 http://www.ietf.org/internet-drafts/draft-ietf- 845 ipsec-ciph-des3-00.txt 847 [IETF-CRYPTO] Schiller, J., "Cryptographic Algorithms for the 848 IETF," , August 849 1999. http://web.mit.edu/network/sa/draft-ietf- 850 saag-aes-ciph-00.txt 852 [LOCALIZED-KEY] U. Blumenthal, N. C. Hien, B. Wijnen "Key 853 Derivation for Network Management Applications" 854 IEEE Network Magazine, April/May issue, 1997. 856 [MIN-KEYLENGTH] Blaze, M., Diffie, W., Rivest, R., Schneier, B., 857 Shimomura, T., Thompson, E., and M. Wiener, 858 "Minimal Key Lengths for Symmetric Ciphers to 859 Provide Adequate Commercial Security", currently 860 available at 861 http://www.crypto.com/papers/keylength.ps 862 http://www.crypto.com/papers/keylength.txt 864 [PLAIN-ANALYSIS] Bellovin, S., "Probable Plaintext Cryptanalysis of 865 the IP Security Protocols", Proceedings of the 866 Symposium on Network and Distributed System 867 Security, San Diego, CA, pp. 155-160, February 868 1997. 869 http://www.research.att.com/~smb/papers/probtxt.ps 870 http://www.research.att.com/~smb/papers/probtxt.pdf 872 [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, 873 "Randomness Recommendations for Security", RFC 874 1750, December 1994. 875 http://www.ietf.org/rfc/rfc1750.txt 877 [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. 878 Waldbusser, "Transport Mappings for Version 2 of 879 the Simple Network Management Protocol (SNMPv2)", 880 RFC 1906, January 1996. 882 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 883 Requirement Levels", BCP 14, RFC 2119, March 1997. 885 [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An 886 Architecture for describing SNMP Management 887 Frameworks", RFC 2571, April 1999. 889 [RFC2574] Blumenthal, U. and B. Wijnen, "The User-Based 890 Security Model for Version 3 of the Simple Network 891 Management Protocol (SNMPv3)", RFC 2574, April 892 1999. 894 [SCHNEIER95] Schneier, B., "Applied Cryptography Second 895 Edition", John Wiley & Sons, New York, NY, 1995. 896 ISBN 0-471-12845-7. 898 10. Editors' Addresses 900 David Reeder 901 NAI Labs 902 3060 Washington Road (Route 97) 903 Glenwood, MD 21738 904 USA 906 Phone: +1-443-259-2348 907 Email: dreeder@tislabs.com 909 Olafur Gudmundsson 910 NAI Labs 911 3060 Washington Road (Route 97) 912 Glenwood, MD 21738 913 USA 915 Phone: +1-443-259-2389 916 Email: ogud@tislabs.com 918 11. Full Copyright Statement 920 Copyright (C) The Internet Society (1999). All Rights Reserved. 922 This document and translations of it may be copied and furnished to 923 others, and derivative works that comment on or otherwise explain it 924 or assist in its implementation may be prepared, copied, published 925 and distributed, in whole or in part, without restriction of any 926 kind, provided that the above copyright notice and this paragraph are 927 included on all such copies and derivative works. However, this 928 document itself may not be modified in any way, such as by removing 929 the copyright notice or references to the Internet Society or other 930 Internet organizations, except as needed for the purpose of 931 developing Internet standards in which case the procedures for 932 copyrights defined in the Internet Standards process must be 933 followed, or as required to translate it into languages other than 934 English. 936 The limited permissions granted above are perpetual and will not be 937 revoked by the Internet Society or its successors or assigns. 939 This document and the information contained herein is provided on an 940 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 941 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 942 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 943 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 944 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 946 Appendix 948 A. SNMP engine Installation Parameters Using 3DES-EDE 950 In order to use the 3DES-EDE privacy protocol in place of the CBC- 951 DES, the SNMP engine may use the following usmUserEntry in the 952 initial configuration of the usmUserTable: 954 privacy support 955 --------------- 956 usmUserEngineID localEngineID 957 usmUserName "initial" 958 usmUserSecurityName "initial" 959 usmUserCloneFrom ZeroDotZero 960 usmUserAuthProtocol usmHMACMD5AuthProtocol 961 usmUserAuthKeyChange "" 962 usmUserOwnAuthKeyChange "" 963 usmUserPrivProtocol usm3DESEDEPrivProtocol 964 usmUserPrivKeyChange "" 965 usmUserOwnPrivKeyChange "" 966 usmUserPublic "" 967 usmUserStorageType anyValidStorageType 968 usmUserStatus active 970 Templates instantiated as initial usmUserEntries for use as clone- 971 from users have a similar format. The usmUserPrivProtocol of 972 usm3DESEDEPrivProtocol replaces usmDESPrivProtocol. 974 B. Password-to-Key Chaining Sample Results 976 B.1. Password-to-Key Chaining Sample Results using MD5 978 [Please Note: This note will be removed when the following values 979 have been double-checked by a third party.] 981 The following shows a sample output of the password-to-key algorithm 982 for a 32-octet key using MD5. The password used in this example is 983 "maplesyrup". The first 16 octets (bytes 1 through 16) are generated 984 by password-to-key algorithm with the pasphrase as input. The second 985 16 octets (bytes 17 through 32) are generated from the password-to- 986 key algorithm with the first 16 octets as input. 988 Each invocation of the password-to-key algorithm in the generation of 989 a string of key bits uses the same engineID. In this example the 990 engineID is: 992 '00 00 00 00 00 00 00 00 00 00 00 02'H 994 The final output of the password-to-key algorithm, used twice as 995 described above, produces a 32-octet localized key of: 997 '52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b 998 79 ef f4 4a 90 65 0e e0 a3 a4 0a bf ac 5a cc 12'H 1000 B.2. Password-to-Key Chaining Sample Results using SHA 1002 [Please Note: This note will be removed when the following values 1003 have been double-checked by a third party.] 1005 The following shows a sample output of the password-to-key algorithm 1006 for a 40-octet key using SHA. The password used in this example is 1007 "maplesyrup". The first 20 octets (bytes 1 through 20) are generated 1008 by password-to-key algorithm with the pasphrase as input. The second 1009 20 octets (bytes 21 through 40) are generated from the password-to- 1010 key algorithm with the first 20 octets as input. 1012 Each invocation of the password-to-key algorithm in the generation of 1013 a string of key bits uses the same engineID. In this example the 1014 engineID is: 1016 '00 00 00 00 00 00 00 00 00 00 00 02'H 1018 The final output of the password-to-key algorithm, used twice as 1019 described above, produces a 40-octet localized key of: 1021 '66 95 fe bc 92 88 e3 62 82 23 5f c7 15 1f 12 84 97 b3 8f 3f 1022 9b 8b 6d 78 93 6b a6 e7 d1 9d fd 9c d2 d5 06 55 47 74 3f b5'H 1024 C. Sample keyChange Results for 32-octet keys 1026 C.1. Sample keyChange Results for 32-octet Keys Using MD5 1028 [Please Note: This section is incomplete.] 1030 Let us assume that a user has a current password of "maplesyrup" as 1031 in section B.1. and let us also assume the snmpEngineID of 12 octets: 1033 '00 00 00 00 00 00 00 00 00 00 00 02'H 1035 If we now want to change the password to "newsyrup", then we first 1036 calculate the localized key for the new password. It is as follows: 1038 87 02 1d 7b d9 d1 01 ba 05 ea 6e 3b f9 d9 bd 4a 1039 70 29 8b 75 7c 91 99 b6 a8 fb f3 93 7b e0 54 XX'H 1041 Then, using the following value as a placeholder for the random 1042 value: 1044 '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1045 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H 1047 we compute a keyChange value of: 1049 '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1051 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 1052 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX'H 1054 C.2. Sample keyChange Results for 32-octet Keys Using SHA 1056 [Please Note: This section is incomplete.] 1058 Let us assume that a user has a current password of "maplesyrup" as 1059 in section B.2. and let us also assume the snmpEngineID of 12 octets: 1061 '00 00 00 00 00 00 00 00 00 00 00 02'H 1063 If we now want to change the password to "newsyrup", then we first 1064 calculate the localized key for the new password. It is as follows: 1066 78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63 1067 91 f1 cd 25 97 74 35 55 f9 fc f9 4a c3 e7 e9 22'H 1069 Note that this value has been truncated from to 32 octets. 1071 Then, using the following value as a placeholder for the random 1072 value: 1074 '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1075 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H 1077 we compute a keyChange value of: 1079 '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1081 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 1082 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX'H 1084 D.1. Strength of 3DES-EDE and Known Attacks 1086 Although 3DES-EDE has an effective key length of 168 bits (56 * 3), 1087 it may be attacked with brute force as though its key were only 112 1088 bits via the meet-in-the-middle attack [MULTI-CRYPT]. Even so, this 1089 number of key bits is greater than the minimum currently recommended 1090 by expert cryptanalysts, although it is still somewhat short of the 1091 most conservative estimates [MIN-KEYLENGTH]. 1093 It has been demonstrated that a DES key may be recovered by 1094 differential cryptanalysis [DIFF-ANALYSIS] and linear cryptanalysis 1095 [LIN-ANALYSIS] after collecting a minimum of 2^47 and 2^43 1096 plaintext/ciphertext pairs, respectively. 3DES-EDE is susceptible to 1097 the same attacks given the same number of plaintext/ciphertext pairs 1098 [DESMODES]. 1100 Thus the primary value of 3DES-EDE over DES is not so much that it is 1101 more resistant to published theoretical attacks, but that it is 1102 apparently more resistant to brute force attacks. 1104 [DIFF-ANALYSIS] also demonstrates a rare attack which requires only 1105 2^33 plaintext/ciphertext pairs. For this reason, it is recommended 1106 that keys are changed after no more than 2^32 block encryptions. 1108 Finally, as has been demonstrated in the context of IP Security, it 1109 is often a simpler and highly successful technique to guess at the 1110 contents of an encrypted block, and use these guesses in combination 1111 with differential or linear cryptananalysis to increase the 1112 probability of recovering the secret key [PLAIN-ANALYSIS]. SNMP has 1113 possible vulnerabilities in this regard as the following PDU fields 1114 are likely to be easily predictable by a passive observer: 1116 - PDU Type 1117 - Request ID 1118 - Error Status, Error Index 1119 - Non-Repeaters, Max-Repetition 1121 Implementations may be classified by the species of their ASN.1 1122 encoding engines, just as network hosts and routers may be classified 1123 by the species of their TCP/IP stack. This in combination with 1124 knowledge of common PDU exchanges makes the prediction of PDU fields 1125 a realistic endeavor. 1127 Suggestions in [PLAIN-ANALYSIS] for closing these sorts of security 1128 holes include: 1130 * Starting counters at random values, 1131 * Replacing predictable values with random values when they are 1132 already known by the receiver, 1133 * Keyed compression. 1135 Concerns of this nature, however, are beyond the scope of this 1136 document. 1138 D.2. Further References 1140 [DESMODES] Biham, E., "On Modes of Operation," Fast Software 1141 Encryption, Cambridge Security Workship Proceedings, 1142 Springer-Verlag, 1994, pp. 116-120. 1144 [DIFF-ANALYSIS] Biham, E., and Shamir, A., "Differential 1145 Cryptanalysis of the Data Encryption Standard", 1146 Berlin: Springer-Verlag, 1993. 1148 [LIN-ANALYSIS] Matsui, M., "Linear Cryptanalysis method for DES 1149 Cipher," Advances in Cryptology -- Eurocrypt '93 1150 Proceedings, Berlin: Springer-Verlag, 1994. 1152 [MULTI-CRYPT] Merkle, R.C., and Hellman, M., "On the Security of 1153 Multiple Encryption", Communications of the ACM, v. 1154 24 n. 7, 1981, pp. 465-467.