idnits 2.17.1 draft-kaukonen-cipher-arcfour-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 (2024-04-26) 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 3 characters in excess of 72. 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 (July 1997) is 9782 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'Schneier' is mentioned on line 114, but not defined -- Looks like a reference, but probably isn't: '0' on line 127 -- Looks like a reference, but probably isn't: '255' on line 127 -- Looks like a reference, but probably isn't: '1' on line 127 -- Looks like a reference, but probably isn't: '256' on line 427 -- Looks like a reference, but probably isn't: '500' on line 438 == Unused Reference: 'SCHNEIER' is defined on line 255, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'Caronni' -- Possible downref: Non-RFC (?) normative reference: ref. 'COMMERCE' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRYPTLIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'FINNEY' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOLIC' ** Obsolete normative reference: RFC 1825 (ref. 'IPSEC') (Obsoleted by RFC 2401) -- Possible downref: Non-RFC (?) normative reference: ref. 'JENKINS' -- Possible downref: Non-RFC (?) normative reference: ref. 'ROOS' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHNEIER' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSH' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSH ARCFOUR' == Outdated reference: A later version (-06) exists of draft-ietf-tls-protocol-00 ** Downref: Normative reference to an Historic draft: draft-ietf-tls-protocol (ref. 'TLS') Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Kaukonen 2 R. Thayer 4 Internet Draft July 1997 6 A Stream Cipher Encryption Algorithm "Arcfour" 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are 12 working documents of the Internet Engineering Task Force 13 (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 ``work in progress.'' 23 To learn the current status of any Internet-Draft, please 24 check the ``1id-abstracts.txt'' listing contained in the 25 Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), 26 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West 28 Coast). 30 Abstract 32 This document describes an algorithm here called Arcfour that 33 is believed to be fully interoperable with the RC4 algoritm. 34 RC4 is trademark of RSA Data Security, Inc. There is a need 35 in the Internet community for an encryption algorithm that 36 provides interoperable operation with existing deployed 37 commercial cryptographic applications. This interoperability 38 will allow for a smoother transition to protocols that have 39 been developed through the IETF standards process. 41 TABLE OF CONTENTS 43 STATUS OF THIS MEMO..........................................1 45 ABSTRACT.....................................................1 47 1. INTRODUCTION..............................................3 49 2. REQUIREMENTS FOR THIS ENCRYPTION ALGORITHM................3 51 3. DESCRIPTION OF ALGORITHM..................................4 53 3.1. KEY SETUP...............................................4 54 3.2. STREAM GENERATION.......................................4 56 4. INTELLECTUAL PROPERTY CONSIDERATIONS......................5 58 5. ACKNOWLEDGEMENTS..........................................5 60 6. SECURITY CONSIDERATIONS...................................5 62 7. REFERENCES................................................6 64 8. AUTHORS' ADDRESSES........................................7 66 APPENDIX.....................................................7 68 A. TEST VECTORS..............................................7 69 B. SAMPLE CODE..............................................10 71 1. Introduction 73 There is a need in the Internet community for an encryption 74 algorithm that provides interoperable operation with existing 75 deployed commercial cryptographic applications. This 76 interoperability allows for a smoother transition to protocols 77 that have been developed through the IETF standards process. 78 This document describes an existing algorithm that satisifies 79 this requirement. 81 There is a large body of experience in developing and 82 deploying encryption applications, especially in the HTTP/HTML 83 browser/server markets. These browsers typically implement 84 the RC4 encryption algorithm provided by [RSA]. It would be 85 beneficial for the IETF standards processes to produce 86 protocols that can be deployed into existing Internet 87 environments. This would allow graceful addition of new 88 (IETF-developed) protocols. It would allow less disruption of 89 existing users, since there would be more interoperability 90 between pre-exisiting protocols and IETF- based protocols. 92 2. Requirements for this Encryption Algorithm 94 The algorithm described here is called Arcfour, and it has 95 been chosen because it is compatible with the RC4(TM) algoritm 96 that is one of the most popular encryption algorithms in the 97 browser market. (See chapter Intellectual Property 98 Considerations.) Arcfour is potentially useful in several 99 environments, including IPSEC [IPSEC], SSH [SSH], and TLS 100 [TLS]. There are existing Internet Drafts that describe how 101 it can be applied, see e.g. [Caronni], [SSH], and [TLS]. 103 The algorithm can be used with a variety of key lengths. It 104 specifically can be operated with 40-bit keys and with 128-bit 105 keys. See the Security Considerations section for comments on 106 the use of 40-bit keys. 108 Compatibility of the algorithm with commercial algorithms can 109 be tested by comparing the encrypted data that is produced by 110 the test vectors listed in the appendix to this document. 112 3. Description of Algorithm 114 The algorithm itself is documented in [Schneier], pages 115 397-398, in the chapter titled "Other Stream Ciphers and Real 116 Random Sequence Generators". 118 3.1 Key Setup 120 1. Allocate an 256 elemment array of 8 bit bytes to be used as 121 an S-box, label it 122 S [0] .. S [255]. 124 2. Initialize the S-box. Fill each entry first with it's 125 index: 127 S [0] = 0; S [1] = 1; etc. up to S [255] = 255; 129 3. Fill another array of the same size (256) with the key, 130 repeating bytes as necessary. 132 for (i = 0; i < 256; i = i + 1) 133 S2 [i] = key [i % keylen]; 135 4. Set j to zero and initialize the S-box like this: 137 for (i = 0; i < 256; i = i + 1) 138 { 139 j = (j + S [i] + S2 [i]) % 256; 140 temp = S [i]; 141 S [i] = S [j]; 142 S [j] = temp; 143 } 145 5. Initialize i and j to zero. If superuser priviledged 146 program sniffing is feared (that is, always) set also the S2 147 array and the key array to zero. That gives a slightly better 148 proctection since the key is believed to be not feasible to 149 calculate after it has been zeroed and thus forgotten. 151 3.2 Stream Generation 153 For either encryption or decryption, the input text is 154 processed one byte at a time. A pseudorandom byte K is 155 generated: 157 i = (i+1) % 256; 158 j = (j + S[i]) % 256; 159 temp = S [i]; 160 S [i] = S [j]; 161 S [j] = temp; 162 t = (S [i] + S [j]) % 256; 163 K = S [t]; 165 To encrypt, XOR the value K with the next byte of the 166 plaintext. To decrypt, XOR the value K with the next byte of 167 the ciphertext. 169 4. Intellectual Property Considerations 171 This document does not address Intellectual Property issues. 172 No claim is made as to who owns this algorithm, of the 173 performance of the algoritm, its cryptographic security or any 174 other liability issues related to the algoritm itself, its 175 implementation or use. 177 The Arcfour algorithm is believed to be fully interoperable 178 with the RC4 algorithm. "RC4" is believed to be trademark of 179 RSA Data Security, Inc. Contact [RSA] if RC4(TM) algorithm is 180 needed. 182 5. Acknowledgements 184 This work was based on conversations with several collegues 185 within the IETF. 187 6. Security Considerations 189 This algorithm can be operated with several different key 190 sizes. If the key is 128 bits in length then this algorithm 191 is believed to be secure. If the key length is significantly 192 shorter, specifically 40 bits, then there are known attacts 193 that have been successfully applied. For this algorithm to be 194 operated in a cryptographically sound manner it is believed 195 that a key length of 128 bits or more should be used. 197 On the other hand, the 40-bit version of this algorithm is 198 specifically regulated by the U.S. Government. This means 199 that deployment of 40-bit implementations may be easier to 200 export than alternative algorithms. 202 It must be strongly recommended that no two plaintexts are 203 encrypted with the same key. Otherwise the plaintext can 204 usually be broken, and often even quite easily. If the two 205 encrypted messages are XORed together, the result is XOR of 206 the original plaintexts. Given the encrypted messages are text 207 strings, credit card numbers, or other byte streams with some 208 known properties, the plaintexts can be estimated with great 209 accuracy. See the [DAWSON AND NIELSEN] for more details. 211 Initial cryptanalysis results are favorable, but the current 212 literature should be consulted to assess the security of this 213 cipher. A good starting point for a citation search would be 214 [GOLIC]. For Internet news group posting, start with 215 [FINNEY], [JENKINS] and [ROOS]. 217 7. References 219 [Caronni] Caronni, G., Waldvogel, M. "The ESP Stream 220 Transform", ftp://ds.internic.net/internet-drafts/ 221 draft-caronni-esp-stream-01.txt, September, 1996. 223 [COMMERCE] Test vectors issued by United States Department of 224 Commerce, Bureau of Export Administration, Office of Strategic 225 Trade and Foreign Policy, Strategic Trade Controls Division. 227 [CRYPTLIB] Gutmann, P, Young, E., Plumb, C. "Cryptlib, A 228 Portable Encryption Library", Version 2.00. 229 http://www.cs.auckland.ac.nz/~pgut001/cryptlib.html, 1996. 231 [DAWSON AND NIELSEN] Dawson E. and Nielsen L.: Automated 232 Cryptoanalysis of XOR Plaintext Strings, Cryptologia, April 233 1996, Volume XX, Number 2. 235 [FINNEY] Finney, H. Internet message posted to sci.crypt 21 236 September, 1994. 238 [GOLIC] Golic, J. "Linear Statistical Weakness of Alleged RC4 239 Keystream Generator." In, W. Fumy (ed.), Proceedings of 240 Eurocrypt '97, 226-238, Springer-Verlag, 1997. 242 [IPSEC] Atkinson, R, "Security Architecture for the Internet 243 Protocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995. 245 [JENKINS] Jenkins, B. Internet message posted to sci.crypt 22 246 September, 1994. 248 [ROOS] Roos, A. Internet message posted to sci.crypt 28 249 September, 1995. 251 [RSA] RSA Data Security, Inc., http://www.rsa.com, Address: 252 RSA Data Security, Inc. 100 Marine Parkway, Suite 500, 253 Redwood City, CA 94065-1031. 255 [SCHNEIER] Schneier, B. "Applied Cryptography", Second 256 Edition, http://www.counterpane.com. Published by John Wiley 257 & Sons, Inc. ISBN 0-471-11709-9, 1996. 259 [SSH] Ylonen, T., "SSH Transport Layer Protocol", 260 ftp://ietf.org/internet-drafts/draft-ietf-secsh-transport-00.txt, 261 March, 1997. 263 [SSH ARCFOUR] Kaukonen, K. Long test vectors for Arcfour and 264 RC4 algorithms issued by Kalle Kaukonen, SSH Communications 265 Security, Ltd, July, 1997. 267 [TLS] Freier, A., Karlton, P., Kocher, P., Dierks, T., " The 268 TLS Protocol", ftp://ds.internic.net/internet-drafts/ 269 draft-ietf-tls-protocol-00.txt, December, 1996. 271 8. Authors' Addresses 273 Kalle Kaukonen 274 SSH Communications Security 275 Tekniikantie 12 276 02150 Espoo 277 Finland 278 kalle@ssh.fi 279 +358 40 526 0364 280 Fax +358 9 4354 3206 282 Rodney Thayer 283 Sable Technology Corporation 284 246 Walnut Street 285 Newton Massachusetts 02160 286 rodney@sabletech.com 287 +1 617 332 7292 288 Fax +1 617 332 7970 290 Appendix 292 A. Test Vectors 294 1. Test Vectors from [CRYPTLIB]: 295 Plain Text: 296 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 297 Key: 298 0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF 300 Cipher Text: 301 0x74, 0x94, 0xC2, 0xE7, 0x10, 0x4B, 0x08, 0x79 303 2. Test Vectors from [COMMERCE]: 304 Plain Text: 305 0xdc, 0xee, 0x4c, 0xf9, 0x2c 306 Key: 307 0x61, 0x8a, 0x63, 0xd2, 0xfb 308 Cipher Text: 309 0xf1, 0x38, 0x29, 0xc9, 0xde 311 3. Test Vectors from [SSH ARCFOUR]: 312 Plain Text: 313 0x52, 0x75, 0x69, 0x73, 0x6c, 0x69, 0x6e, 0x6e, 314 0x75, 0x6e, 0x20, 0x6c, 0x61, 0x75, 0x6c, 0x75, 315 0x20, 0x6b, 0x6f, 0x72, 0x76, 0x69, 0x73, 0x73, 316 0x73, 0x61, 0x6e, 0x69, 0x2c, 0x20, 0x74, 0xe4, 317 0x68, 0x6b, 0xe4, 0x70, 0xe4, 0x69, 0x64, 0x65, 318 0x6e, 0x20, 0x70, 0xe4, 0xe4, 0x6c, 0x6c, 0xe4, 319 0x20, 0x74, 0xe4, 0x79, 0x73, 0x69, 0x6b, 0x75, 320 0x75, 0x2e, 0x20, 0x4b, 0x65, 0x73, 0xe4, 0x79, 321 0xf6, 0x6e, 0x20, 0x6f, 0x6e, 0x20, 0x6f, 0x6e, 322 0x6e, 0x69, 0x20, 0x6f, 0x6d, 0x61, 0x6e, 0x61, 323 0x6e, 0x69, 0x2c, 0x20, 0x6b, 0x61, 0x73, 0x6b, 324 0x69, 0x73, 0x61, 0x76, 0x75, 0x75, 0x6e, 0x20, 325 0x6c, 0x61, 0x61, 0x6b, 0x73, 0x6f, 0x74, 0x20, 326 0x76, 0x65, 0x72, 0x68, 0x6f, 0x75, 0x75, 0x2e, 327 0x20, 0x45, 0x6e, 0x20, 0x6d, 0x61, 0x20, 0x69, 328 0x6c, 0x6f, 0x69, 0x74, 0x73, 0x65, 0x2c, 0x20, 329 0x73, 0x75, 0x72, 0x65, 0x20, 0x68, 0x75, 0x6f, 330 0x6b, 0x61, 0x61, 0x2c, 0x20, 0x6d, 0x75, 0x74, 331 0x74, 0x61, 0x20, 0x6d, 0x65, 0x74, 0x73, 0xe4, 332 0x6e, 0x20, 0x74, 0x75, 0x6d, 0x6d, 0x75, 0x75, 333 0x73, 0x20, 0x6d, 0x75, 0x6c, 0x6c, 0x65, 0x20, 334 0x74, 0x75, 0x6f, 0x6b, 0x61, 0x61, 0x2e, 0x20, 335 0x50, 0x75, 0x75, 0x6e, 0x74, 0x6f, 0x20, 0x70, 336 0x69, 0x6c, 0x76, 0x65, 0x6e, 0x2c, 0x20, 0x6d, 337 0x69, 0x20, 0x68, 0x75, 0x6b, 0x6b, 0x75, 0x75, 338 0x2c, 0x20, 0x73, 0x69, 0x69, 0x6e, 0x74, 0x6f, 339 0x20, 0x76, 0x61, 0x72, 0x61, 0x6e, 0x20, 0x74, 340 0x75, 0x75, 0x6c, 0x69, 0x73, 0x65, 0x6e, 0x2c, 341 0x20, 0x6d, 0x69, 0x20, 0x6e, 0x75, 0x6b, 0x6b, 342 0x75, 0x75, 0x2e, 0x20, 0x54, 0x75, 0x6f, 0x6b, 343 0x73, 0x75, 0x74, 0x20, 0x76, 0x61, 0x6e, 0x61, 344 0x6d, 0x6f, 0x6e, 0x20, 0x6a, 0x61, 0x20, 0x76, 345 0x61, 0x72, 0x6a, 0x6f, 0x74, 0x20, 0x76, 0x65, 346 0x65, 0x6e, 0x2c, 0x20, 0x6e, 0x69, 0x69, 0x73, 347 0x74, 0xe4, 0x20, 0x73, 0x79, 0x64, 0xe4, 0x6d, 348 0x65, 0x6e, 0x69, 0x20, 0x6c, 0x61, 0x75, 0x6c, 349 0x75, 0x6e, 0x20, 0x74, 0x65, 0x65, 0x6e, 0x2e, 350 0x20, 0x2d, 0x20, 0x45, 0x69, 0x6e, 0x6f, 0x20, 351 0x4c, 0x65, 0x69, 0x6e, 0x6f 353 Key: 354 0x29, 0x04, 0x19, 0x72, 0xfb, 0x42, 0xba, 0x5f, 355 0xc7, 0x12, 0x77, 0x12, 0xf1, 0x38, 0x29, 0xc9 357 Cipher Text: 358 0x35, 0x81, 0x86, 0x99, 0x90, 0x01, 0xe6, 0xb5, 359 0xda, 0xf0, 0x5e, 0xce, 0xeb, 0x7e, 0xee, 0x21, 360 0xe0, 0x68, 0x9c, 0x1f, 0x00, 0xee, 0xa8, 0x1f, 361 0x7d, 0xd2, 0xca, 0xae, 0xe1, 0xd2, 0x76, 0x3e, 362 0x68, 0xaf, 0x0e, 0xad, 0x33, 0xd6, 0x6c, 0x26, 363 0x8b, 0xc9, 0x46, 0xc4, 0x84, 0xfb, 0xe9, 0x4c, 364 0x5f, 0x5e, 0x0b, 0x86, 0xa5, 0x92, 0x79, 0xe4, 365 0xf8, 0x24, 0xe7, 0xa6, 0x40, 0xbd, 0x22, 0x32, 366 0x10, 0xb0, 0xa6, 0x11, 0x60, 0xb7, 0xbc, 0xe9, 367 0x86, 0xea, 0x65, 0x68, 0x80, 0x03, 0x59, 0x6b, 368 0x63, 0x0a, 0x6b, 0x90, 0xf8, 0xe0, 0xca, 0xf6, 369 0x91, 0x2a, 0x98, 0xeb, 0x87, 0x21, 0x76, 0xe8, 370 0x3c, 0x20, 0x2c, 0xaa, 0x64, 0x16, 0x6d, 0x2c, 371 0xce, 0x57, 0xff, 0x1b, 0xca, 0x57, 0xb2, 0x13, 372 0xf0, 0xed, 0x1a, 0xa7, 0x2f, 0xb8, 0xea, 0x52, 373 0xb0, 0xbe, 0x01, 0xcd, 0x1e, 0x41, 0x28, 0x67, 374 0x72, 0x0b, 0x32, 0x6e, 0xb3, 0x89, 0xd0, 0x11, 375 0xbd, 0x70, 0xd8, 0xaf, 0x03, 0x5f, 0xb0, 0xd8, 376 0x58, 0x9d, 0xbc, 0xe3, 0xc6, 0x66, 0xf5, 0xea, 377 0x8d, 0x4c, 0x79, 0x54, 0xc5, 0x0c, 0x3f, 0x34, 378 0x0b, 0x04, 0x67, 0xf8, 0x1b, 0x42, 0x59, 0x61, 379 0xc1, 0x18, 0x43, 0x07, 0x4d, 0xf6, 0x20, 0xf2, 380 0x08, 0x40, 0x4b, 0x39, 0x4c, 0xf9, 0xd3, 0x7f, 381 0xf5, 0x4b, 0x5f, 0x1a, 0xd8, 0xf6, 0xea, 0x7d, 382 0xa3, 0xc5, 0x61, 0xdf, 0xa7, 0x28, 0x1f, 0x96, 383 0x44, 0x63, 0xd2, 0xcc, 0x35, 0xa4, 0xd1, 0xb0, 384 0x34, 0x90, 0xde, 0xc5, 0x1b, 0x07, 0x11, 0xfb, 385 0xd6, 0xf5, 0x5f, 0x79, 0x23, 0x4d, 0x5b, 0x7c, 386 0x76, 0x66, 0x22, 0xa6, 0x6d, 0xe9, 0x2b, 0xe9, 387 0x96, 0x46, 0x1d, 0x5e, 0x4d, 0xc8, 0x78, 0xef, 388 0x9b, 0xca, 0x03, 0x05, 0x21, 0xe8, 0x35, 0x1e, 389 0x4b, 0xae, 0xd2, 0xfd, 0x04, 0xf9, 0x46, 0x73, 390 0x68, 0xc4, 0xad, 0x6a, 0xc1, 0x86, 0xd0, 0x82, 391 0x45, 0xb2, 0x63, 0xa2, 0x66, 0x6d, 0x1f, 0x6c, 392 0x54, 0x20, 0xf1, 0x59, 0x9d, 0xfd, 0x9f, 0x43, 393 0x89, 0x21, 0xc2, 0xf5, 0xa4, 0x63, 0x93, 0x8c, 394 0xe0, 0x98, 0x22, 0x65, 0xee, 0xf7, 0x01, 0x79, 395 0xbc, 0x55, 0x3f, 0x33, 0x9e, 0xb1, 0xa4, 0xc1, 396 0xaf, 0x5f, 0x6a, 0x54, 0x7f 398 B. Sample Code 400 /* This code illustrates a sample implementation 401 * of the Arcfour algorithm 402 * Copyright (c) April 29, 1997 Kalle Kaukonen. 403 * All Rights Reserved. 404 * 405 * Redistribution and use in source and binary forms, with or 406 * without modification, are permitted provided that this copyright 407 * notice and disclaimer are retained. 408 * 409 * THIS SOFTWARE IS PROVIDED BY KALLE KAUKONEN AND CONTRIBUTORS ``AS 410 * IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 411 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 412 * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL KALLE 413 * KAUKONEN OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 414 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 415 * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 416 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 417 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, 418 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 419 * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 420 * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 421 */ 423 typedef struct 424 { 425 unsigned int x; 426 unsigned int y; 427 unsigned char state[256]; 428 } ArcfourContext; 430 void arcfour_init(ArcfourContext *ctx, const unsigned char *key, 431 unsigned int key_len); 432 unsigned int arcfour_byte(ArcfourContext *ctx); 433 void arcfour_encrypt(ArcfourContext *ctx, unsigned char *dest, 434 const unsigned char *src, unsigned int len); 436 int main(int argc, char **argv) 437 { 438 unsigned char dest[500]; 439 unsigned char mykey[] = {0x29, 0x04, 0x19, 0x72, 0xfb, 0x42, 440 0xba, 0x5f, 0xc7, 0x12, 0x77, 0x12, 441 0xf1, 0x38, 0x29, 0xc9}; 442 unsigned char src[] = "Know thyself"; 444 ArcfourContext mycontext; 445 /* Initialize the algoritm */ 446 arcfour_init(&mycontext, mykey, 16); 448 /* Encrypt 13 bytes of the src string */ 449 arcfour_encrypt(&mycontext, dest, src, 13); 451 /* Now "dest" contains the encrypted string. Do whatever 452 you please with it... */ 454 return 0; 455 } 457 void arcfour_init(ArcfourContext *ctx, const unsigned char *key, 458 unsigned int key_len) 459 { 460 unsigned int t, u; 461 unsigned int keyindex; 462 unsigned int stateindex; 463 unsigned char *state; 464 unsigned int counter; 466 state = ctx->state; 467 ctx->x = 0; 468 ctx->y = 0; 469 for (counter = 0; counter < 256; counter++) 470 state[counter] = counter; 471 keyindex = 0; 472 stateindex = 0; 473 for (counter = 0; counter < 256; counter++) 474 { 475 t = state[counter]; 476 stateindex = (stateindex + key[keyindex] + t) & 0xff; 477 u = state[stateindex]; 478 state[stateindex] = t; 479 state[counter] = u; 480 if (++keyindex >= key_len) 481 keyindex = 0; 482 } 483 } 484 unsigned int arcfour_byte(ArcfourContext *ctx) 485 { 486 unsigned int x; 487 unsigned int y; 488 unsigned int sx, sy; 489 unsigned char *state; 491 state = ctx->state; 492 x = (ctx->x + 1) & 0xff; 493 sx = state[x]; 494 y = (sx + ctx->y) & 0xff; 495 sy = state[y]; 496 ctx->x = x; 497 ctx->y = y; 498 state[y] = sx; 499 state[x] = sy; 500 return state[(sx + sy) & 0xff]; 501 } 503 void arcfour_encrypt(ArcfourContext *ctx, unsigned char *dest, 504 const unsigned char *src, unsigned int len) 505 { 506 unsigned int i; 507 for (i = 0; i < len; i++) 508 dest[i] = src[i] ^ arcfour_byte(ctx); 509 }