December 2003 - cypherpunks-legacy

CIAC Notice - Virus with Crypto Tech...
by NetSurfer 17 Dec '03

17 Dec '03

Excerpted from CIAC, a report of a stealth virus that uses encryption as part of its attack. If the list thinks its of interest, I'll zap it over. But briefly: September 13, 1994 1600 PDT Number E-34 _____________________________________________________________________________ PROBLEM: A previously unknown computer virus is damaging systems. PLATFORM: All MS-DOS, PC-DOS, Windows systems, all versions. DAMAGE: Damages files, encrypts hard drive. SOLUTION: Update your Anti-Virus program to detect/remove the virus. _____________________________________________________________________________ VULNERABILITY While it is not epidemic, the virus has been seen at an East ASSESSMENT: coast site and it isn't detected by the current versions of most virus scanners (revised versions are upcoming.) The virus is intentionally damaging and all files on an infected machine are at risk. Warning: Removing the virus may make some files inaccessible (see below.) _____________________________________________________________________________ The virus is intentionally damaging. Every time an infected machine boots, the virus encrypts two cylinders of the DOS partition of the hard drive starting with the highest numbered cylinder and progressing to lower numbered ones. The virus then hides the fact that it is encrypting the hard drive by decrypting any of the encrypted sectors whenever they are accessed by the system. Only with the virus out of memory do you see the encrypted sectors. WARNING: Because of the encryption the virus does, be sure you copy any important files to a floppy disk or tape before removing the virus. The CHK_HALF program described below does not decrypt any encrypted cylinders, so when the virus is removed, the encryption key is lost with it and any files in the encrypted cylinders are lost. ===========================================================================

1 0

(fwd) RC4 Algorithm revealed.
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Someone (probably one of you!) has posted this item to several newsgroups. Note the forgery, a la port 25, of "David Sterndark"'s name. I, too, am shocked, simply shocked, and will be nofifying the "Casa Blanca" of this breach. -TCM Newsgroups: sci.crypt,alt.security,comp.security.misc,alt.privacy Path: netcom.com!sterndark From: sterndark(a)netcom.com (David Sterndark) Subject: RC4 Algorithm revealed. Message-ID: <sternCvKL4B.Hyy(a)netcom.com> Sender: sterndark(a)netcom.com Organization: NETCOM On-line Communication Services (408 261-4700 guest) Date: Wed, 14 Sep 1994 06:35:31 GMT I am shocked, shocked, I tell you, shocked, to discover that the cypherpunks have illegaly and criminally revealed a crucial RSA trade secret and harmed the security of America by reverse engineering the RC4 algorithm and publishing it to the world. On Saturday morning an anonymous cypherpunk wrote: SUBJECT: RC4 Source Code I've tested this. It is compatible with the RC4 object module that comes in the various RSA toolkits. /* rc4.h */ typedef struct rc4_key { unsigned char state[256]; unsigned char x; unsigned char y; } rc4_key; void prepare_key(unsigned char *key_data_ptr,int key_data_len, rc4_key *key); void rc4(unsigned char *buffer_ptr,int buffer_len,rc4_key * key); /*rc4.c */ #include "rc4.h" static void swap_byte(unsigned char *a, unsigned char *b); void prepare_key(unsigned char *key_data_ptr, int key_data_len, rc4_key *key) { unsigned char swapByte; unsigned char index1; unsigned char index2; unsigned char* state; short counter; state = &key->state[0]; for(counter = 0; counter < 256; counter++) state[counter] = counter; key->x = 0; key->y = 0; index1 = 0; index2 = 0; for(counter = 0; counter < 256; counter++) { index2 = (key_data_ptr[index1] + state[counter] + index2) % 256; swap_byte(&state[counter], &state[index2]); index1 = (index1 + 1) % key_data_len; } } void rc4(unsigned char *buffer_ptr, int buffer_len, rc4_key *key) { unsigned char x; unsigned char y; unsigned char* state; unsigned char xorIndex; short counter; x = key->x; y = key->y; state = &key->state[0]; for(counter = 0; counter < buffer_len; counter ++) { x = (x + 1) % 256; y = (state[x] + y) % 256; swap_byte(&state[x], &state[y]); xorIndex = (state[x] + state[y]) % 256; buffer_ptr[counter] ^= state[xorIndex]; } key->x = x; key->y = y; } static void swap_byte(unsigned char *a, unsigned char *b) { unsigned char swapByte; swapByte = *a; *a = *b; *b = swapByte; } Another cypherpunk, this one not anonymous, tested the output from this algorithm against the output from official RC4 object code Date: Tue, 13 Sep 94 18:37:56 PDT From: ekr(a)eit.COM (Eric Rescorla) Message-Id: <9409140137.AA17743(a)eitech.eit.com> Subject: RC4 compatibility testing Cc: cypherpunks(a)toad.com One data point: I can't say anything about the internals of RC4 versus the algorithm that Bill Sommerfeld is rightly calling 'Alleged RC4', since I don't know anything about RC4's internals. However, I do have a (legitimately acquired) copy of BSAFE2 and so I'm able to compare the output of this algorithm to the output of genuine RC4 as found in BSAFE. I chose a set of test vectors and ran them through both algorithms. The algorithms appear to give identical results, at least with these key/plaintext pairs. I note that this is the algorithm _without_ Hal Finney's proposed modification (see <199409130605.XAA24133(a)jobe.shell.portal.com>). The vectors I used (together with the ciphertext they produce) follow at the end of this message. -Ekr Disclaimer: This posting does not reflect the opinions of EIT. --------------------results follow-------------- Test vector 0 Key: 0x01 0x23 0x45 0x67 0x89 0xab 0xcd 0xef Input: 0x01 0x23 0x45 0x67 0x89 0xab 0xcd 0xef 0 Output: 0x75 0xb7 0x87 0x80 0x99 0xe0 0xc5 0x96 Test vector 1 Key: 0x01 0x23 0x45 0x67 0x89 0xab 0xcd 0xef Input: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0 Output: 0x74 0x94 0xc2 0xe7 0x10 0x4b 0x08 0x79 Test vector 2 Key: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Input: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0 Output: 0xde 0x18 0x89 0x41 0xa3 0x37 0x5d 0x3a Test vector 3 Key: 0xef 0x01 0x23 0x45 Input: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0 Output: 0xd6 0xa1 0x41 0xa7 0xec 0x3c 0x38 0xdf 0xbd 0x61 Test vector 4 Key: 0x01 0x23 0x45 0x67 0x89 0xab 0xcd 0xef Input: 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0 Output: 0x75 0x95 0xc3 0xe6 0x11 0x4a 0x09 0x78 0x0c 0x4a 0xd4 0x52 0x33 0x8e 0x1f 0xfd 0x9a 0x1b 0xe9 0x49 0x8f 0x81 0x3d 0x76 0x53 0x34 0x49 0xb6 0x77 0x8d 0xca 0xd8 0xc7 0x8a 0x8d 0x2b 0xa9 0xac 0x66 0x08 0x5d 0x0e 0x53 0xd5 0x9c 0x26 0xc2 0xd1 0xc4 0x90 0xc1 0xeb 0xbe 0x0c 0xe6 0x6d 0x1b 0x6b 0x1b 0x13 0xb6 0xb9 0x19 0xb8 0x47 0xc2 0x5a 0x91 0x44 0x7a 0x95 0xe7 0x5e 0x4e 0xf1 0x67 0x79 0xcd 0xe8 0xbf 0x0a 0x95 0x85 0x0e 0x32 0xaf 0x96 0x89 0x44 0x4f 0xd3 0x77 0x10 0x8f 0x98 0xfd 0xcb 0xd4 0xe7 0x26 0x56 0x75 0x00 0x99 0x0b 0xcc 0x7e 0x0c 0xa3 0xc4 0xaa 0xa3 0x04 0xa3 0x87 0xd2 0x0f 0x3b 0x8f 0xbb 0xcd 0x42 0xa1 0xbd 0x31 0x1d 0x7a 0x43 0x03 0xdd 0xa5 0xab 0x07 0x88 0x96 0xae 0x80 0xc1 0x8b 0x0a 0xf6 0x6d 0xff 0x31 0x96 0x16 0xeb 0x78 0x4e 0x49 0x5a 0xd2 0xce 0x90 0xd7 0xf7 0x72 0xa8 0x17 0x47 0xb6 0x5f 0x62 0x09 0x3b 0x1e 0x0d 0xb9 0xe5 0xba 0x53 0x2f 0xaf 0xec 0x47 0x50 0x83 0x23 0xe6 0x71 0x32 0x7d 0xf9 0x44 0x44 0x32 0xcb 0x73 0x67 0xce 0xc8 0x2f 0x5d 0x44 0xc0 0xd0 0x0b 0x67 0xd6 0x50 0xa0 0x75 0xcd 0x4b 0x70 0xde 0xdd 0x77 0xeb 0x9b 0x10 0x23 0x1b 0x6b 0x5b 0x74 0x13 0x47 0x39 0x6d 0x62 0x89 0x74 0x21 0xd4 0x3d 0xf9 0xb4 0x2e 0x44 0x6e 0x35 0x8e 0x9c 0x11 0xa9 0xb2 0x18 0x4e 0xcb 0xef 0x0c 0xd8 0xe7 0xa8 0x77 0xef 0x96 0x8f 0x13 0x90 0xec 0x9b 0x3d 0x35 0xa5 0x58 0x5c 0xb0 0x09 0x29 0x0e 0x2f 0xcd 0xe7 0xb5 0xec 0x66 0xd9 0x08 0x4b 0xe4 0x40 0x55 0xa6 0x19 0xd9 0xdd 0x7f 0xc3 0x16 0x6f 0x94 0x87 0xf7 0xcb 0x27 0x29 0x12 0x42 0x64 0x45 0x99 0x85 0x14 0xc1 0x5d 0x53 0xa1 0x8c 0x86 0x4c 0xe3 0xa2 0xb7 0x55 0x57 0x93 0x98 0x81 0x26 0x52 0x0e 0xac 0xf2 0xe3 0x06 0x6e 0x23 0x0c 0x91 0xbe 0xe4 0xdd 0x53 0x04 0xf5 0xfd 0x04 0x05 0xb3 0x5b 0xd9 0x9c 0x73 0x13 0x5d 0x3d 0x9b 0xc3 0x35 0xee 0x04 0x9e 0xf6 0x9b 0x38 0x67 0xbf 0x2d 0x7b 0xd1 0xea 0xa5 0x95 0xd8 0xbf 0xc0 0x06 0x6f 0xf8 0xd3 0x15 0x09 0xeb 0x0c 0x6c 0xaa 0x00 0x6c 0x80 0x7a 0x62 0x3e 0xf8 0x4c 0x3d 0x33 0xc1 0x95 0xd2 0x3e 0xe3 0x20 0xc4 0x0d 0xe0 0x55 0x81 0x57 0xc8 0x22 0xd4 0xb8 0xc5 0x69 0xd8 0x49 0xae 0xd5 0x9d 0x4e 0x0f 0xd7 0xf3 0x79 0x58 0x6b 0x4b 0x7f 0xf6 0x84 0xed 0x6a 0x18 0x9f 0x74 0x86 0xd4 0x9b 0x9c 0x4b 0xad 0x9b 0xa2 0x4b 0x96 0xab 0xf9 0x24 0x37 0x2c 0x8a 0x8f 0xff 0xb1 0x0d 0x55 0x35 0x49 0x00 0xa7 0x7a 0x3d 0xb5 0xf2 0x05 0xe1 0xb9 0x9f 0xcd 0x86 0x60 0x86 0x3a 0x15 0x9a 0xd4 0xab 0xe4 0x0f 0xa4 0x89 0x34 0x16 0x3d 0xdd 0xe5 0x42 0xa6 0x58 0x55 0x40 0xfd 0x68 0x3c 0xbf 0xd8 0xc0 0x0f 0x12 0x12 0x9a 0x28 0x4d 0xea 0xcc 0x4c 0xde 0xfe 0x58 0xbe 0x71 0x37 0x54 0x1c 0x04 0x71 0x26 0xc8 0xd4 0x9e 0x27 0x55 0xab 0x18 0x1a 0xb7 0xe9 0x40 0xb0 0xc0 -- --------------------------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we James A. Donald are. True law derives from this right, not from the arbitrary power of the omnipotent state. jamesd(a)netcom.com -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway." -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

1 0

No Subject
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

Many thanks to the anonymous gentileperson who reposted the RC4 source. Now I can rejoin the conversation already in progress. Louis Cypher (new Nym on the block)

1 0

Re: e$: WSJ, CyberCash, and the Falling Barometer
by Anonymous User 17 Dec '03

17 Dec '03

THE WALL STREET JOURNAL. (c) 1994 Dow Jones & Company, Inc. ------------------------------------------------------------------------------------------------------------------- TUESDAY, SEPTEMBER 13, 1994 Enterprise: System Planned For Shopping On the Internet ---- By Jared Sandberg Staff Reporter of The Wall Street Journal As millions of computer users browse the Internet for a burgeoning array of goods and services, most can look but not buy. That may soon change. A new company called CyberCash Inc., formed by executives from the Internet and the electronic-payment industries, plans to introduce a system that will allow on-line browsers to pay for an item, either by credit card or through bank transfers, over the global computer network. CommerceNet, a new on-line system funded by Apple Computer Inc., BankAmerica Corp. and others, expects to adopt the CyberCash system by year's end. The company has talked to America Online Inc., which has one million subscribers and to which it has close ties. By clicking a "buy" button, CyberCash users could approve electronic transfers to merchants from checking and credit-card accounts. Companies could pay invoices, and e-mail penpals could settle bets with the point of a mouse. But to do that, CyberCash must first persuade banks that the system is secure from on-line theft, which may be its toughest challenge. "I don't think there's a system that is adequately secure that has been placed on the table," says Sholom Rosen, a vice president for Citicorp, who says he isn't familiar with CyberCash. Even if one emerges, he adds, "it's going to be tough to get everybody to agree on the same system." While some companies, including Citibank, are planning their own business-to-business electronic payment systems on the Internet, CyberCash is aimed at the millions of consumer and business users who browse the Internet. "We want to make the Internet safe for commerce," says CyberCash's co-founder and president, William N. Melton, and "provide safe passage from cyberspace into the banking world." Private on-line services use proprietary software to move funds, which reduces the risk of thieves breaking into the system. But only subscribers are permitted to make on-line purchases, and then only from participating merchants. For example, fewer than 3% of the people who frequent the CompuServe "mall" each month buy anything. The Internet, by contrast, is an unsecured free-for-all that uses "open" software to let tens of thousands of computers link up. That means more computer jocks know how it really works, increasing the chances of a break-in. Mr. Melton is in a good position to overcome the banks' security concerns. He founded Verifone Inc., which makes the devices retailers use to authorize credit-card charges. He sits on the board of America Online and helped launch Transaction Network Services Inc., a data transmission network for six of the 12 largest credit-card processing centers. TNS is expected to be part of CyberCash's private banking network. CyberCash's co-founder is Dan Lynch, founder of Interop Co., a trade-show subsidiary of Ziff Communications Co. that hosts the biggest Internet gatherings. Other partners include Stephen D. Crocker, one of the Internet's architects; James Bidzos, president of RSA Data Securities Inc., a leading software-security firm; and Bruce Wilson, a former Nynex Corp. executive and one-time board member of the Electronic Funds Transfer Association, a banking trade group. The Internet today is one big yard sale of computers, t-shirts, books, compact disks, rope sandals, legal services and hundreds of other products -- with almost no way to buy. An estimated 500 companies, from travel agencies and art galleries to real-estate brokers and a Volvo dealership, have put up storefronts. Most offer only product information and customer support. To make a purchase, a browser must phone a vendor. "It's a very clunky way of conducting electronic commerce," says Jayne Levin, editor of the Internet Letter, a newsletter aimed at business users. She estimates the current value of Internet transactions at a "piddling" $10 million. A few pioneers have passed credit-card numbers safely on the Internet. In July, an electronic bookstore received its first payment over the network. Last month, a small startup retailer in Nashua, N.H., sold its first compact disk on-line. Almost no one, however, has been able to automate payment by bringing banks directly on-line, which is CyberCash's goal. Its approach would let users punch a few keys to ask their banks to set aside money in a "digital purse." When the customer clicks on a "buy" icon, the merchant's computer would pass the request to CyberCash's network, which would forward it to the bank. If funds are available in the "digital purse" or a credit-card account, the money would get tranferred from bank to CyberCash to merchant. CyberCash would receive a small fee for each transaction from the banks. "The transaction is processed instantaneously -- while you wait," says Mr. Crocker of CyberCash. He says the company is working to secure the system, "but there's no question we will have people trying our `front door.'" CyberCash plans to spend $20 million on a private network of computers, which will separate Internet merchants from users' bank accounts. To protect sensitive account information, RSA Data Securities will provide encryption to scramble the data, allowing only those who have a special software "key" to read it. Customers and their banks will hold the keys. In addition, Cybercash is discussing licensing with David Chaum, president of Digicash Inc., a key patent holder for digital-cash technology. Digicash emphasizes anonymity: A merchant is told only whether the cash is available, not who is paying. Other security measures must be taken. On the Internet, users can veil their identities or steal access accounts masquerading as someone else. Backers of RSA and CommerceNet, which posts business and product information on the Internet, are working on tools to verify user ID and keep payment requests private and tamper-proof. Even with those measures, however, CyberCash executives concede it will take some potent powers of persuasion to get the banks on board. "There is no security on the Internet," says Dan Schutzer, president of the Financial Services Technology Consortium, a group of major banks. "Your conversations can be tapped, your passwords can be obtained, and your credit card number can be filched. Clearly, it's there for the reading for a clever hacker." WSJviaNewsEDGE Copyright (c) 1994 Dow Jones and Company, Inc. Received via NewsEDGE from Desktop Data, Inc. Tickers: AAPL AMER BAC CCI TNSI Subjects: BNKM BANK TLCM COMP FIN ICSO SOFT ICS LICN NPRD SBUS INDG CA NOAM NY USA VA WSJ Page: B1 WS: Wall Street Journal

1 0

Re: alleged-RC4
by Hal 17 Dec '03

17 Dec '03

Bill Sommerfeld <sommerfeld(a)orchard.medford.ma.us> writes: >Actually, all the %256 operations in the code are superfluous on >8-bit-byte platforms since the indices are declared as `unsigned >char'. Ah, good point. So my "typo" doesn't really matter (although I think it is a typo.) >Probably the only potential weakness I can see is that the `x' and `y' >counters are always initialized to zero when starting off; this means >that an attacker can almost always know the `x' value used to encrypt >each byte of cyphertext they find. I can't see any way to exploit >this, though. It would seem that you could (slightly) strengthen the >cipher by starting with x=state[0] and y=state[1], then cranking the >key generation loop for two more iterations.. A related point is how the key-dependent state-table permutation is set up. The algorithm is, in pseudo-code, for i from 0 to 255 swap state[i] and state[j] where j is incremented by state[i] plus the next key byte, mod 256. Notice the similarity to the naive random-permutation generator: for i from 0 to 255 j = random (256) swap state[i] and state[j] where random (n) returns a random number less than n. This naive algorithm is not quite right, as it generates 256 to the 256th power equally likely arrangements, when there are actually only 256! arrangements and 256! doesn't even divide 256^256 evenly. The similarity I see is that j is chosen in the prepare_key as a slightly complicated function of the key byte and the current state, and we can view this as a key-dependent substitute for random (256). So it would appear that the prepare_key algorithm, even with a fully random key, may produce a bias in the permutation table. A correct algorithm for a random permutation is: for i from 0 to 255 j = random (i+1) swap state[i] and state[j] Here we choose the random number from among the ones we have already done. This algorithm can be easily proven correct. Perhaps it would be better if the prepare_key algorithm did a similar thing, choosing the entry with which to swap modulo the current "i" value plus one rather than mod 256. One implication of the existing implementation is that there may be a simple relation between at least state[0] and the first character of the key. Initially state[0] will be swapped with the value in the table at the position of the first byte of the key. Since the table is initialized to 0..255, this means that state[0] will hold the value of the first key byte after that swap. Now, it is probable that state[0] will be chosen "randomly" to be swapped with a later entry in the table. But as we discussed here a few days ago, there is about a 1/e chance (about 37%) that it will not be swapped after its first guaranteed swap. This means that 37% of the time that this algorithm is used, state[0] holds the first key byte at startup. OTOH if the modification I suggested above were made, no such conclusion could be drawn and I don't see anything simple you could say about the likely permutation after prepare_key is complete. Now, having said this, I don't see any way to exploit this knowledge to attack the cypher. The "lookup, sum, and lookup" structure of the cypher has too many degrees of freedom to allow this information about state[0] to expose a hint of what the key might be, as far as I can see. But it is an interesting aspect of the key setup, nevertheless. Hal

2 1

Re: Is cypherpunks archived somewhere?
by bshantz＠spry.com 17 Dec '03

17 Dec '03

On Wed, 14 Sep, Phil Karn wrote: >Is the cypherpunks list being automatically archived where it can be >retrieved by anonymous FTP? The list is not automatically archived. Robert Hayden had been keeping a "digest" version on his machine. That was until the university he's at pulled the plug for stupid reasons. Right now, Robert is fighting to get his machine back up and running. Maybe he'd be willing to keep the digest again if the machine gets back up. Until then, anyone have any suggestions? Brad >>>>>>>>>>>>>>>>INTERNETWORKING THE DESKTOP<<<<<<<<<<<<<<<<<< Brad Shantz bshantz(a)spry.com Software Engineer Main #: (206)-447-0300 SPRY Inc. Direct #: (206)-442-8251 316 Occidental Ave FAX #: (206)-442-9008 2nd Floor Seattle, WA 98104 WWW URL: http://WWW.SPRY.COM ------------------------------------------------------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

2 1

RC4
by schneier＠chinet.chinet.com 17 Dec '03

17 Dec '03

I've been out of e-mail range for a while, so some of sci.crypt has fallen off the back end of my host. And I don't read the full Cypherpunks feed. So some of these may be dumb questions, but they're mine and I would like them answered. Does anyone know if this is really RC4? Has anyone compiled it to see if it will run? Has anyone tried to use it to decrypt messages encrypted with some commercial RC4 program? I see that it has been posted anonymously. Was it posted to Cypherpunks only, or did it also get on sci.crypt? If not, did someone from Cypherpunks, anonymously or not, crosspost it to sci.crypt? Has there been any reaction from anybody? RSADS? NSA? NIST? I just sent a copy of Bidzos asking for comment. This seems to be a REALLY GOOD THING, but I would like some verification that it is not a hoax. Inquiring minds want to know. Bruce

3 4

Noninteractive use of PGP 2.6 _help requested
by Syl Miniter 803-768-3759 17 Dec '03

17 Dec '03

I would like to know how to set up PGP 2.6 UNIX so that I can filter(ELM) mail through PGP from the filter without being signed on the(remote) system. I believe that the path variable is involved($PGPPATH). The ELM filter works fine while I am physically signed on but stops encrypting when I send mail to the filter from a remote account. Presumably the program looks at the "current"directory for public key files---/usr/local/bin/pgp and the keys are really in my personal account /usr/homef/me/.pgp. I am NOT UNIX expert so if you send a response a 4th grade programming level explanation will not be viewed as "playing down" I am assuming I can use "setenv $PGPPATH =/usr/homef/me/pgp" in csh and that will work while I am logged into the account. Question (I think)is how to provide a path statement while I am not signed on and have th csh-ell active. Some sample statements are helpful. BTW the same question is interesting for Procmail and I would apprecitae some recipes from the cyphercognoscenti for this problem regards,Syl

1 0

Is cypherpunks archived somewhere?
by Phil Karn 17 Dec '03

17 Dec '03

Is the cypherpunks list being automatically archived where it can be retrieved by anonymous FTP? Yes, there *are* occasional nuggets on this list. Why, there's even the occasional practical item about cryptography buried in the massive rants to the libertarian choir. But I'd hate to miss stuff like the recent note on RC4. That's why I haven't unsubscribed yet. But something has to give. The list is just too high-volume, and the signal-to-noise ratio is now below -1.6 dB. It's just not worth it. It's a major reason why I always seem to run as much as a week behind on my mail. If there were an automatic FTP archive of the list, then I could unsubscribe while keeping the option of pulling over and grepping through an archived batch every so often just to see if anybody is actually doing anything. Phil

10 12

EFF's DIGICASH Archive
by Brian D Williams 17 Dec '03

17 Dec '03

compiled by Stanton McCandlish EFF Digital Money & Online Commercial Transactions Archive Index of: ftp.eff.org, /pub/EFF/Policy/Privacy/Crypto_Clipper_ITAR/Digital_money/ gopher.eff.org, 1/EFF/Policy/Privacy/Crypto_Clipper_ITAR/Digital_money http://www.eff.org/pub/EFF/Policy/Privacy/Crypto_Clipper_ITAR/Digital money/ chaum_privacy_id.article - David Chaum's August 1992 article from Scientific America describing "blind signature' technology and the possibilities of enhanced digital privacy. Such technology is behind Chaum's "DigiCash" e-money system. david_chaum.biblio - a 1994 list of publications by David Chaum, "the father of digital money", and strong proponent for online transaction systems that are anonymous and cryptographically secure. digicash.brochure - a 1994 brochure describing what DigiCash is. digicash.gif - the DigiCash logo. This is a GIF-format graphic file. digicash.announce - May 1994 press release hailing digicash as the first online cash payment system over computer networks. double_spend_finney.notes - October 1993 notes from a mailing list describing Chaum's digital cash in lay terms, focussing on the "double spending" problem that has so far crippled attempts to institute online transactions by others. By Hal Finney. ecash.gif - an "E-Cash" logo graphic (intended for use by merchants that accept DigiCash). magic_money.announce - may 1994 description of Magic Money V1.1 with autoclient and multiserver capability. This is an Internet-based digital money system. online_banks.info - a listing of online banks worldwide, books about online banking and a description of why online banking increases the privacy of individuals. online_cash_chaum.paper - Chaum's 1993 article describes 3 ways to make online cash exchange work. prepaid_smartcard_chaum.article - Chaum's 1994 paper explaining the technique of prepaid smartcards which contains stored value (in terms of dollars) which a user might exchange with a vendor rather than cumbersome cash. secure_newsgroup.paper - Marc Rinquette's August 1992 article on implementing electrocnic cash using secure newsgroups. visa_e-purse.announce - 1994 article and commentary discussing "electronic purse" proposal from Visa.

1 0