idnits 2.17.00 (12 Aug 2021) /tmp/idnits27507/draft-hoffman-des40-00.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 141 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 81: '...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 121 looks like a reference -- Missing reference section? 'CDMF' on line 117 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-00.txt Internet Mail Consortium 3 Russ Housley 4 SPYRUS 5 May 14, 1996 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 learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 1. Introduction 29 This document describes an method for shortening DES keys from 56 bits 30 to 40 bits. The shortened keys are generally known as "DES-40". The 31 motivation for this weakening is that some localities (such as the 32 United States) give special preference to applications that use 40-bit 33 keys. The weakened keys are then used with the DES encryption 34 algorithm in the same manner as full-strength keys. 36 There are many possible methods for reducing a 56-bit key to a 40-bit 37 key. The method in this draft was chosen because one method is needed 38 for interoperability. Further, this method has been known to 39 occaisionally have been approved for export from the United States. 41 1.1 Discussion of this Draft 43 This draft is being discussed on the "ietf-smime" mailing list. To 44 subscribe, send a message to: 45 ietf-smime-request@imc.org 46 witht the single word 47 subscribe 48 in the body of the message. There is a Web site for the mailing list 49 at . 51 2. Creating 40-Bit Keys for DES 53 DES [DES] uses a 56-bit key. The key consists of eight 8-bit bytes; 54 however the last (eighth) bit of each byte is used for parity, leaving 55 56 bits of key. 57 To weaken the 8-byte, 56-bit key into a 40-bit key, you set to zero 58 the first four bits of every other byte in the key, starting with the 59 first byte. Stated a different way, you take the bitwise logical AND 60 of the key and the binary value: 61 0000111111111111000011111111111100001111111111110000111111111111 63 Another way to picture this is: 65 Bit positions: 66 0000000000111111111122222222223333333333444444444455555555556666 67 0123456789012345678901234567890123456789012345678901234567890123 68 Use: 69 zzzzKKKpKKKKKKKpzzzzKKKpKKKKKKKpzzzzKKKpKKKKKKKpzzzzKKKpKKKKKKKp 71 Legend: 72 z = zero bit 73 K = key bit 74 p = parity bit 76 Some implementations of DES require the parity bit of each byte to be 77 set correctly in order for the key to be accepted. DES requires that 78 the last bit of each byte be a parity bit. DES uses odd parity, 79 meaning that the number of 1 bits in each byte should be odd. 80 Therefore, to complete the transformation to a 40-bit key, the 81 software SHOULD cause the parity in each byte to be odd, changing the 82 last bit if necessary. 84 3. Security Considerations 86 Current computer technology makes a brute-force attack on ciphertext 87 that is encrypted with a 40-bit key fairly quick. This is true for any 88 encryption algorithms, not just DES. Thus, 40-bit keys result in only 89 weak security against decryption. As computers get faster, this weak 90 security will become even weaker. Thus, 40-bit keys should never be 91 used with data that has a high value if it is decrypted by an 92 adversary. However, encrypting data with 40-bit keys prevents passive 93 snoopers from immediately reading a message without using some 94 significant but not onerous decryption effort. 96 The shortening method described in this draft causes a discernable 97 pattern of zero bits in the resulting key. There is no known 98 literature at this time that describes whether cyphertext encrypted 99 with a key that has this pattern of zeros is easier to decrypt than 100 cyphertext that has no pattern. However, because 40-bit keys are 101 already inherently weak, a decrease in security from the pattern is 102 not considered to be very important relative to the inherent weakness 103 due to the short key length. 105 There are other methods for converting longer keys to shorter ones. 106 For example, IBM has created a patented (and significantly more 107 complex) method called "Commercial Data Masking Facility", or CDMF 108 [CDMF]; other methods probably exist. These methods might result in 109 keys that produce cyphertext that is harder (or easier) to determine 110 through brute-force. A quick comparison of CDMF and DES-40 shows that 111 the brute-force attack against CDMF require one additional DES 112 operation. Saving one DES operation does not seem to warrant the 113 additonal complexity. 115 A. References 117 [CDMF] "Design of the Commercial Data Masking Facility Data Privacy 118 Algorithm", 1st ACM Conference on Computer and Communications 119 Security, ACM Press, 1993. 121 [DES] ANSI X3.106, "American National Standard for Information 122 Systems-Data Link Encryption," American National Standards 123 Institute, 1983. 125 B. Authors' Addresses 127 Paul Hoffman 128 Internet Mail Consortium 129 127 Segre Place 130 Santa Cruz, CA 95060 131 (408) 426-9827 132 phoffman@imc.org 134 Russ Housley 135 SPYRUS 136 PO Box 1198 137 Herndon, VA 20172 138 (703) 435-7344 139 housley@spyrus.com