idnits 2.17.1 draft-horowitz-key-derivation-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 (2024-03-28) 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) 2024 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 4 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([Blumenthal96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Blumenthal96' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Horowitz 2 Stonecast, Inc. 3 Internet-Draft August, 1998 5 Key Derivation for Authentication, Integrity, and Privacy 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 21 Directories on ftp.ietf.org (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 23 Rim). 25 Distribution of this memo is unlimited. Please send comments to the 26 author. 28 Abstract 30 Recent advances in cryptography have made it desirable to use longer 31 cryptographic keys, and to make more careful use of these keys. In 32 particular, it is considered unwise by some cryptographers to use the 33 same key for multiple purposes. Since most cryptographic-based 34 systems perform a range of functions, such as authentication, key 35 exchange, integrity, and encryption, it is desirable to use different 36 cryptographic keys for these purposes. 38 This RFC does not define a particular protocol, but defines a set of 39 cryptographic transformations for use with arbitrary network 40 protocols and block cryptographic algorithm. 42 Deriving Keys 44 In order to use multiple keys for different functions, there are two 45 possibilities: 47 - Each protocol ``key'' contains multiple cryptographic keys. The 48 implementation would know how to break up the protocol ``key'' for 49 use by the underlying cryptographic routines. 51 - The protocol ``key'' is used to derive the cryptographic keys. 52 The implementation would perform this derivation before calling 53 the underlying cryptographic routines. 55 In the first solution, the system has the opportunity to provide 56 separate keys for different functions. This has the advantage that 57 if one of these keys is broken, the others remain secret. However, 58 this comes at the cost of larger ``keys'' at the protocol layer. In 59 addition, since these ``keys'' may be encrypted, compromising the 60 cryptographic key which is used to encrypt them compromises all the 61 component keys. Also, the not all ``keys'' are used for all possible 62 functions. Some ``keys'', especially those derived from passwords, 63 are generated from limited amounts of entropy. Wasting some of this 64 entropy on cryptographic keys which are never used is unwise. 66 The second solution uses keys derived from a base key to perform 67 cryptographic operations. By carefully specifying how this key is 68 used, all of the advantages of the first solution can be kept, while 69 eliminating some disadvantages. In particular, the base key must be 70 used only for generating the derived keys, and this derivation must 71 be non-invertible and entropy-preserving. Given these restrictions, 72 compromise of one derived keys does not compromise the other subkeys. 73 Attack of the base key is limited, since it is only used for 74 derivation, and is not exposed to any user data. 76 Since the derived key has as much entropy as the base keys (if the 77 cryptosystem is good), password-derived keys have the full benefit of 78 all the entropy in the password. 80 To generate a derived key from a base key: 82 Derived Key = DK(Base Key, Well-Known Constant) 84 where 86 DK(Key, Constant) = k-truncate(E(Key, Constant)) 88 In this construction, E(Key, Plaintext) is a block cipher, Constant 89 is a well-known constant defined by the protocol, and k-truncate 90 truncates its argument by taking the first k bits; here, k is the key 91 size of E. 93 If the output of E is is shorter than k bits, then some entropy in 94 the key will be lost. If the Constant is smaller than the block size 95 of E, then it must be padded so it may be encrypted. If the Constant 96 is larger than the block size, then it must be folded down to the 97 block size to avoid chaining, which affects the distribution of 98 entropy. 100 In any of these situations, a variation of the above construction is 101 used, where the folded Constant is encrypted, and the resulting 102 output is fed back into the encryption as necessary (the | indicates 103 concatentation): 105 K1 = E(Key, n-fold(Constant)) 106 K2 = E(Key, K1) 107 K3 = E(Key, K2) 108 K4 = ... 110 DK(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...) 112 n-fold is an algorithm which takes m input bits and ``stretches'' 113 them to form n output bits with no loss of entropy, as described in 114 [Blumenthal96]. In this document, n-fold is always used to produce n 115 bits of output, where n is the block size of E. 117 If the size of the Constant is not equal to the block size of E, then 118 the Constant must be n-folded to the block size of E. This string is 119 used as input to E. If the block size of E is less than the key 120 size, then the output from E is taken as input to a second invocation 121 of E. This process is repeated until the number of bits accumulated 122 is greater than or equal to the key size of E. When enough bits have 123 been computed, the first k are taken as the derived key. 125 Since the derived key is the result of one or more encryptions in the 126 base key, deriving the base key from the derived key is equivalent to 127 determining the key from a very small number of plaintext/ciphertext 128 pairs. Thus, this construction is as strong as the cryptosystem 129 itself. 131 Deriving Keys from Passwords 133 When protecting information with a password or other user data, it is 134 necessary to convert an arbitrary bit string into an encryption key. 135 In addition, it is sometimes desirable that the transformation from 136 password to key be difficult to reverse. A simple variation on the 137 construction in the prior section can be used: 139 Key = DK(k-fold(Password), Well-Known Constant) 141 k-fold is same algorithm as n-fold, used to fold the Password into 142 the same number of bits as the key of E. 144 The k-fold algorithm is reversible, so recovery of the k-fold output 145 is equivalent to recovery of Password. However, recovering the k- 146 fold output is difficult for the same reason recovering the base key 147 from a derived key is difficult. 149 Traditionally, the transformation from plaintext to ciphertext, or 150 vice versa, is determined by the cryptographic algorithm and the key. 151 A simple way to think of derived keys is that the transformation is 152 determined by the cryptographic algorithm, the constant, and the key. 154 For interoperability, the constants used to derive keys for different 155 purposes must be specified in the protocol specification. Also, the 156 endian order of the keys must be specified. 158 The constants must not be specified on the wire, or else an attacker 159 who determined one derived key could provide the associated constant 160 and spoof data using that derived key, rather than the one the 161 protocol designer intended. 163 Determining which parts of a protocol require their own constants is 164 an issue for the designer of protocol using derived keys. 166 Security Considerations 168 This entire document deals with security considerations relating to 169 the use of cryptography in network protocols. 171 Appendix 173 This Appendix quotes the n-fold algorithm from [Blumenthal96]. It is 174 provided here as a convenience to the implementor. Sample vectors 175 are also included. It should be noted that the sample vector in 176 Appendix B.2 of the original paper appears to be incorrect. Two 177 independent implementations from the specification (one in C by the 178 author, and another in Scheme by Bill Sommerfeld) agree on a value 179 different from that in [Blumenthal96]. 181 We first define a primitive called n-folding, which takes a 182 variable-length input block and produces a fixed-length output 183 sequence. The intent is to give each input bit approximately 184 equal weight in determining the value of each output bit. Note 185 that whenever we need to treat a string of bytes as a number, the 186 assumed representation is Big-Endian -- Most Significant Byte 187 first. 189 To n-fold a number X, replicate the input value to a length that 190 is the least common multiple of n and the length of X. Before 191 each repetition, the input is rotated to the right by 13 bit 192 positions. The successive n-bit chunks are added together using 193 1's-complement addiiton (that is, with end-around carry) to yield 194 a n-bit result.... 196 The result is the n-fold of X. Here are some sample vectors, in 197 hexadecimal. For convenience, the inputs are ASCII encodings of 198 strings. 200 64-fold("012345") = 201 64-fold(303132333435) = be072631276b1955 203 56-fold("password") = 204 56-fold(70617373776f7264) = 78a07b6caf85fa 206 64-fold("Rough Consensus, and Running Code") = 207 64-fold(526f75676820436f6e73656e7375732c20616e642052756e 208 6e696e6720436f6465) = bb6ed30870b7f0e0 210 168-fold("password") = 211 168-fold(70617373776f7264) = 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e 213 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY" 214 192-fold(4d41535341434856534554545320494e5354495456544520 215 4f4620544543484e4f4c4f4759) = 216 db3b0d8f0b061e603282b308a50841229ad798fab9540c1b 218 Acknowledgements 220 I would like to thank Uri Blumenthal, Hugo Krawczyk, and Bill 221 Sommerfeld for their contributions to this document. 223 References 225 [Blumenthal96] Blumenthal, U., "A Better Key Schedule for DES-Like 226 Ciphers", Proceedings of PRAGOCRYPT '96, 1996. 228 Author's Address 230 Marc Horowitz 231 Stonecast, Inc. 232 108 Stow Road 233 Harvard, MA 01451 235 Phone: +1 978 456 9103 236 Email: marc@stonecast.net