idnits 2.17.00 (12 Aug 2021) /tmp/idnits26863/draft-hoffman-des40-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-21) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 150 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.) ** 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 72: '...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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 130 looks like a reference -- Missing reference section? 'CDMF' on line 126 looks like a reference Summary: 8 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-02.txt Internet Mail Consortium 3 Russ Housley 4 SPYRUS 5 April 29, 1998 Expires six months later 7 Creating 40-Bit Keys for DES 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 1. Introduction 30 This document describes an method for shortening DES keys from 56 bits 31 to 40 bits. The shortened keys are generally known as "DES-40". The 32 motivation for this weakening is that some localities (such as the 33 United States) give special preference to applications that use 40-bit 34 keys. The weakened keys are then used with the DES encryption 35 algorithm in the same manner as full-strength keys. 37 There are many possible methods for reducing a 56-bit key to a 40-bit 38 key. The method in this draft was chosen because one method is needed 39 for interoperability. Further, this method has been known to 40 occasionally have been approved for export from the United States. 42 2. Creating 40-Bit Keys for DES 44 DES [DES] uses a 56-bit key. The key consists of eight 8-bit bytes; 45 however the last (eighth) bit of each byte is used for parity, leaving 46 56 bits of key. 48 To weaken the 8-byte, 56-bit key into a 40-bit key, you set to zero 49 the first four bits of every other byte in the key, starting with the 50 first byte. Stated a different way, you take the bitwise logical AND 51 of the key and the binary value: 52 0000111111111111000011111111111100001111111111110000111111111111 54 Another way to picture this is: 56 Bit positions: 57 0000000000111111111122222222223333333333444444444455555555556666 58 0123456789012345678901234567890123456789012345678901234567890123 59 Use: 60 zzzzKKKpKKKKKKKpzzzzKKKpKKKKKKKpzzzzKKKpKKKKKKKpzzzzKKKpKKKKKKKp 62 Legend: 63 z = zero bit 64 K = key bit 65 p = parity bit 67 Some implementations of DES require the parity bit of each byte to be 68 set correctly in order for the key to be accepted. DES requires that 69 the last bit of each byte be a parity bit. DES uses odd parity, 70 meaning that the number of 1 bits in each byte should be odd. 71 Therefore, to complete the transformation to a 40-bit key, the 72 software SHOULD cause the parity in each byte to be odd, changing the 73 last bit if necessary. 75 3. Security Considerations 77 Current computer technology makes a brute-force attack on ciphertext 78 that is encrypted with a 40-bit key fairly quick. This is true for any 79 encryption algorithms, not just DES. Thus, 40-bit keys result in only 80 weak security against decryption. As computers get faster, this weak 81 security will become even weaker. Thus, 40-bit keys should never be 82 used with data that has a high value if it is decrypted by an 83 adversary. However, encrypting data with 40-bit keys prevents passive 84 snoopers from immediately reading a message without using some 85 significant but not onerous decryption effort. 87 Because of the ease of a brute-force attack on 40-bit keys, the 56-bit 88 key from which a 40-bit key is derived must not also be used as a 89 56-bit key. This is due to a simple attack that first derives the 90 40-bit key, then fills in the remaining 16 bits by brute force. 91 Systems that produce 40-bit keys from 56-bit keys must assume that the 92 associated 56-bit key is only slightly harder to compromise than the 93 40-bit key. 95 Note that short keys (and 40 bits is generally considered short) are 96 subject to a variety of brute-force attacks that are not possible with 97 longer keys, thus making them even more dangerous. For example, if a 98 40-bit algorithm is used and encrypted text includes a block of bytes 99 known to the attacker, then the attacker can pre-compute all possible 100 encryptions of that block and do a rapid comparison against the 101 pre-computed ciphertexts. Further, it is likely that more attacks on 102 short keys will appear in the future, thereby rendering them even less 103 suitable for protecting data. 105 The shortening method described in this draft causes a discernable 106 pattern of zero bits in the resulting key. There is no known 107 literature at this time that describes whether cyphertext encrypted 108 with a key that has this pattern of zeros is easier to decrypt than 109 cyphertext that has no pattern. However, because 40-bit keys are 110 already inherently weak, a decrease in security from the pattern is 111 not considered to be very important relative to the inherent weakness 112 due to the short key length. 114 There are other methods for converting longer keys to shorter ones. 115 For example, IBM has created a patented (and significantly more 116 complex) method called "Commercial Data Masking Facility", or CDMF 117 [CDMF]; other methods probably exist. These methods might result in 118 keys that produce cyphertext that is harder (or easier) to determine 119 through brute-force. A quick comparison of CDMF and DES-40 shows that 120 the brute-force attack against CDMF require one additional DES 121 operation. Saving one DES operation does not seem to warrant the 122 additional complexity. 124 A. References 126 [CDMF] "Design of the Commercial Data Masking Facility Data Privacy 127 Algorithm", 1st ACM Conference on Computer and Communications 128 Security, ACM Press, 1993. 130 [DES] ANSI X3.106, "American National Standard for Information 131 Systems-Data Link Encryption," American National Standards 132 Institute, 1983. 134 B. Authors' Addresses 136 Paul Hoffman 137 Internet Mail Consortium 138 127 Segre Place 139 Santa Cruz, CA 95060 140 (408) 426-9827 141 phoffman@imc.org 143 Russ Housley 144 SPYRUS 145 381 Elden Street, Suite 1120 146 Herndon, VA 20170 147 housley@spyrus.com