idnits 2.17.00 (12 Aug 2021) /tmp/idnits27247/draft-hoffman-des40-01.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 131 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 112 looks like a reference -- Missing reference section? 'CDMF' on line 108 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-01.txt Internet Mail Consortium 3 Russ Housley 4 SPYRUS 5 April 20, 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 The shortening method described in this draft causes a discernable 88 pattern of zero bits in the resulting key. There is no known 89 literature at this time that describes whether cyphertext encrypted 90 with a key that has this pattern of zeros is easier to decrypt than 91 cyphertext that has no pattern. However, because 40-bit keys are 92 already inherently weak, a decrease in security from the pattern is 93 not considered to be very important relative to the inherent weakness 94 due to the short key length. 96 There are other methods for converting longer keys to shorter ones. 97 For example, IBM has created a patented (and significantly more 98 complex) method called "Commercial Data Masking Facility", or CDMF 99 [CDMF]; other methods probably exist. These methods might result in 100 keys that produce cyphertext that is harder (or easier) to determine 101 through brute-force. A quick comparison of CDMF and DES-40 shows that 102 the brute-force attack against CDMF require one additional DES 103 operation. Saving one DES operation does not seem to warrant the 104 additional complexity. 106 A. References 108 [CDMF] "Design of the Commercial Data Masking Facility Data Privacy 109 Algorithm", 1st ACM Conference on Computer and Communications 110 Security, ACM Press, 1993. 112 [DES] ANSI X3.106, "American National Standard for Information 113 Systems-Data Link Encryption," American National Standards 114 Institute, 1983. 116 B. Authors' Addresses 118 Paul Hoffman 119 Internet Mail Consortium 120 127 Segre Place 121 Santa Cruz, CA 95060 122 (408) 426-9827 123 phoffman@imc.org 125 Russ Housley 126 SPYRUS 127 381 Elden Street, Suite 1120 128 Herndon, VA 20170 129 housley@spyrus.com