idnits 2.17.1 draft-hoffman-des40-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 163 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 76: '...software SHOULD cause the parity in ea...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (April 30, 1999) is 9128 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 section? 'DES' on line 134 looks like a reference -- Missing reference section? 'CDMF' on line 130 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Hoffman 2 draft-hoffman-des40-03.txt Internet Mail Consortium 3 Russ Housley 4 SPYRUS 5 April 30, 1999 6 Expires in six months 8 Creating 40-Bit Keys for DES 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1. Introduction 32 This document describes an method for shortening DES keys from 56 bits 33 to 40 bits. The shortened keys are generally known as "DES-40". The 34 motivation for this weakening is that some localities give export 35 preference to applications that use relatively weak encryption 36 algorithms. Some implementors want to use DES with 40-bit keys instead 37 of other algorithms with 40-bit keys because they already have DES 38 coded into their products. The weakened keys are then used with the DES 39 encryption algorithm in the same manner as full-strength keys. 41 There are many possible methods for reducing a 56-bit key to a 40-bit 42 key. The method in this draft was chosen because one method is needed 43 for interoperability. Further, this method has been known to 44 occasionally have been approved for export from the United States. 46 2. Creating 40-Bit Keys for DES 48 DES [DES] uses a 56-bit key. The key consists of eight 8-bit bytes; 49 however the last (eighth) bit of each byte is used for parity, leaving 50 56 bits of key. 52 To weaken the 8-byte, 56-bit key into a 40-bit key, you set to zero 53 the first four bits of every other byte in the key, starting with the 54 first byte. Stated a different way, you take the bitwise logical AND 55 of the key and the binary value: 56 0000111111111111000011111111111100001111111111110000111111111111 58 Another way to picture this is: 60 Bit positions: 61 0000000000111111111122222222223333333333444444444455555555556666 62 0123456789012345678901234567890123456789012345678901234567890123 63 Use: 64 zzzzKKKpKKKKKKKpzzzzKKKpKKKKKKKpzzzzKKKpKKKKKKKpzzzzKKKpKKKKKKKp 66 Legend: 67 z = zero bit 68 K = key bit 69 p = parity bit 71 Some implementations of DES require the parity bit of each byte to be 72 set correctly in order for the key to be accepted. DES requires that 73 the last bit of each byte be a parity bit. DES uses odd parity, 74 meaning that the number of 1 bits in each byte should be odd. 75 Therefore, to complete the transformation to a 40-bit key, the 76 software SHOULD cause the parity in each byte to be odd, changing the 77 last bit if necessary. 79 3. Security Considerations 81 Current computer technology makes a brute-force attack on ciphertext 82 that is encrypted with a 40-bit key fairly quick. This is true for any 83 encryption algorithms, not just DES. Thus, 40-bit keys result in only 84 weak security against decryption. As computers get faster, this weak 85 security will become even weaker. Thus, 40-bit keys should never be 86 used with data that has a high value if it is decrypted by an 87 adversary. However, encrypting data with 40-bit keys prevents passive 88 snoopers from immediately reading a message without using some 89 significant but not onerous decryption effort. 91 Because of the ease of a brute-force attack on 40-bit keys, the 56-bit 92 key from which a 40-bit key is derived must not also be used as a 93 56-bit key. This is due to a simple attack that first derives the 94 40-bit key, then fills in the remaining 16 bits by brute force. 95 Systems that produce 40-bit keys from 56-bit keys must assume that the 96 associated 56-bit key is only slightly harder to compromise than the 97 40-bit key. 99 Note that short keys (and 40 bits is generally considered short) are 100 subject to a variety of brute-force attacks that are not possible with 101 longer keys, thus making them even more dangerous. For example, if a 102 40-bit algorithm is used and encrypted text includes a block of bytes 103 known to the attacker, then the attacker can pre-compute all possible 104 encryptions of that block and do a rapid comparison against the 105 pre-computed ciphertexts. Further, it is likely that more attacks on 106 short keys will appear in the future, thereby rendering them even less 107 suitable for protecting data. 109 The shortening method described in this draft causes a discernable 110 pattern of zero bits in the resulting key. There is no known 111 literature at this time that describes whether cyphertext encrypted 112 with a key that has this pattern of zeros is easier to decrypt than 113 cyphertext that has no pattern. However, because 40-bit keys are 114 already inherently weak, a decrease in security from the pattern is 115 not considered to be very important relative to the inherent weakness 116 due to the short key length. 118 There are other methods for converting longer keys to shorter ones. 119 For example, IBM has created a patented (and significantly more 120 complex) method called "Commercial Data Masking Facility", or CDMF 121 [CDMF]; other methods probably exist. These methods might result in 122 keys that produce cyphertext that is harder (or easier) to determine 123 through brute-force. A quick comparison of CDMF and DES-40 shows that 124 the brute-force attack against CDMF require one additional DES 125 operation. Saving one DES operation does not seem to warrant the 126 additional complexity. 128 A. References 130 [CDMF] "Design of the Commercial Data Masking Facility Data Privacy 131 Algorithm", 1st ACM Conference on Computer and Communications 132 Security, ACM Press, 1993. 134 [DES] ANSI X3.106, "American National Standard for Information 135 Systems-Data Link Encryption," American National Standards 136 Institute, 1983. 138 B. Object Identifier 140 In general, the algorithm identifiers associated with DES are used with 141 DES-40 since the algorithm is exactly the same except that 16 of the 142 key bits have known values. However, there are a few instances (such as 143 algorithm negotiation) where DES-40 needs to be specified. The 144 following algorithm identifier has been assigned for these cases. Note 145 that no mode of operation is associated with this algorithm identifier. 147 id-alg-des40 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 148 dod(6) internet(1) security(5) mechanisms(5) pkix(7) alg(6) 1 } 150 C. Authors' Addresses 152 Paul Hoffman 153 Internet Mail Consortium 154 127 Segre Place 155 Santa Cruz, CA 95060 USA 156 phoffman@imc.org 158 Russ Housley 159 SPYRUS 160 381 Elden Street, Suite 1120 161 Herndon, VA 20170 USA 162 housley@spyrus.com