- cypherpunks-legacy - lists.cpunks.org

Re: An article for Wired magazine
by monty.harder＠famend.com 17 Dec '03

17 Dec '03

PE> kilos of gold in it if $50,000 in cash doesn't suit your tastes. I PE> defy governments to eliminate gold as well as paper currency. Um. Didn't FDR try that? * Free will made me do it! --- * Monster(a)FAmend.Com *

2 1

Re: Purple Boxes
by Bill Stewart 17 Dec '03

17 Dec '03

At 10:30 PM 8/15/95 -0400, Dave Emery wrote: > I reiterate my suggestion of a few months ago that >one could quite easily adapt the firmware on one of the new simultanious >data and digital voice on the same phone line modems to incorperate >encryption, and quite possibly encryption/key exhange interoperable >with some mode of PGPphone. Doing this would relieve one of the >need to develop or manufacture any hardware at all - all that would >be required to have a portable "bump in the cord" encrypter widely >available for a low price would be creating a new version of the >downloadable flash ROM image that did encryption and PGPphone >key exchange. Most modems I've seen only have one set of audio interfaces, and a bump-in-the-cord phone needs two (one for the voice side, one for the modem line side.) (Having two jacks doesn't count.) So you'd need at least two modems, one straight and one re-educated, and you'd probably need lots more flash ROM than the average modem has. On the other hand, laptops are increasingly getting multimedia capabilities like built-in sound cards, and if there's a microphone jack you're in business (uh, well, for $3K or so) Or a cheaper laptop with two PCMCIA modems, if you can re-educate one, which also lets you move the non-audio parts of your secure phone program into the PC. Of course, if you want long conversations from the airport, you'll still need to find a payphone within 4-6 feet of an electric socket and not located under a MegaMuzak speaker, but that's easier than trying to balance a TI Silent 700 under similar conditions :-) #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #--- "The fat man rocks out Hinges fall off Heaven's door "Come on in," says Bill" Wavy Gravy's haiku for Jerry

2 1

SSL challenge -- broken !
by Damien.Doligez＠inria.fr 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- SSL challenge -- broken This is to announce the solution of the SSL challenge posted by Hal Finney on July 17, 1995 (message-ID: <3u6kmg$pm4(a)jobe.shell.portal.com>), also found at: <URL:http://www.portal.com/~hfinney/sslchal.html> The 40-bit secret part of the key is 7e f0 96 1f a6. I found it by a brute force search on a network of about 120 workstations and a few parallel computers at INRIA, Ecole Polytechnique, and ENS. The key was found after scanning a little more than half the key space in 8 days. The cleartext of the encrypted data is as follows: The SERVER-VERIFY message is: 9C B1 C7 83 D9 BB B7 75 01 6F 19 19 03 58 EC 05 MAC-DATA 05 MSG-SERVER-VERIFY AF 84 A7 79 F8 13 69 20 25 9B 53 A0 60 AE 75 51 CHALLENGE The CHALLENGE part is a copy of the challenge sent by the client in its first message. The answer is the CLIENT-FINISHED message: 22 BB 23 39 55 B0 7F B6 1A B0 35 85 F7 DB C1 E5 MAC-DATA 03 MSG-CLIENT-FINISHED BF EB 90 F8 2C 0C E1 EA 18 AC 11 4C 83 14 21 B6 CONNECTION-ID The next message is SERVER-FINISHED: D4 CD F3 4E 38 F1 2B 1E DC FD 72 C8 34 02 CD FF MAC-DATA 06 SERVER-FINISHED-BYTE 23 1C 05 40 60 72 49 6E 83 BA D1 28 CC 9B 5F 63 SESSION-ID-DATA Then comes the data message sent by the client. This is the juicy one. I have broken the contents into its fields (the body was just one long line) 72 23 B5 98 0D D0 07 1A DA F1 C7 A4 40 41 5A 10 MAC-DATA POST /order2.cgi HTTP/1.0 Referer: https://order.netscape.com/order2.cgi User-Agent: Mozilla/1.1N (Macintosh; I; PPC) Accept: */* Accept: image/gif Accept: image/x-xbitmap Accept: image/jpeg Content-type: application/x-www-form-urlencoded Content-length: 472 source-form=order2-cust.html& order_number=31770& prod_80-01020-00_Mac=1& carrier_code=UM& ship_first=Cosmic& ship_last=Kumquat& ship_org=SSL+Trusters+Inc.& ship_addr1=1234+Squeamish+Ossifrage+Road& ship_addr2=& ship_city=Anywhere& ship_state=NY& ship_zip=12345& ship_country=USA& ship_phone=& ship_fax=& ship_email=& bill_first=& bill_last=& bill_org=& bill_addr1=& bill_addr2=& bill_city=& bill_state=& bill_zip=& bill_country=USA& bill_phone=& bill_fax=& bill_email=& submit=+Submit+Customer+Data+ This order came from Mr Cosmic Kumquat, SSL Trusters Inc., 1234 Squeamish Ossifrage Road, Anywhere, NY 12345 (USA). Unfortunately, Mr Kumquat forgot to give his phone number, and the server's reply (in two packets) is: 09 12 AD FE A5 A9 BF D1 8C 8C E2 6A A3 48 B9 75 MAC-DATA HTTP/1.0 200 OK Server: Netscape-Commerce/1.1 Date: Wednesday, 12-Jul-95 05:40:30 GMT Content-type: text/html 1C CD C4 3D 80 F1 7B 94 11 AC E8 72 B1 99 BC FA MAC-DATA <TITLE>Error</TITLE><H1>Error</H1> The shipping address you supplied is not complete. The street address, city, state, zip code, country and phone number are mandatory fields. Please go back and specify the full shipping address. Thank you. This result was found with a quick-and-dirty distributed search program, which I wrote when I realized that the cypherpunks were going to be a few weeks late with their collective effort. When the program was running, it took little more than one week to find the key (it would have taken about 15 days to sweep the entire key space). I ran it on almost all the machines I have access to, summarized in the following table: type speed (keys/s) number notes - -------------------------------------------------------- DEC (alpha) 18000-33000 34 DEC (MIPS) 2500-7500 11 SPARC 2000-13000 57 HP (HPPA/snake) 15000 3 Sony (R3000) 1100-4000 3 Sun 3 600 2 Sequent B8000 100 x 10 1 (1) Multimax (NS532) 600 x 14 1 (1) KSR 3200 x 64 1 (1) (2) Notes: 1. These are multiprocessor machines 2. The KSR spent only about 2 days on this computation. The total average searching speed was about 850000 keys/s, with a maximum of 1350000 keys/s (1150000 without the KSR). Conclusions: * Many people have access to the amount of computing power that I used. The exportable SSL protocol is supposed to be weak enough to be easily broken by governments, yet strong enough to resist the attempts of amateurs. It fails on the second count. Don't trust your credit card number to this protocol. * Cypherpunks write code, all right, but they shouldn't forget to run it. I want to thank the people at INRIA, Ecole Polytechnique, and Ecole Normale Superieure for giving their CPU time. (Most of them are on vacation anyway...) You can find a copy of this text at <URL:http://pauillac.inria.fr/~doligez/ssl/announce.txt> -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCSAwUBMDG4dVNZwSQVabihAQGeFAPnUZil4WlauoMke9HaULDNOVf1hLXS0i9U VJWZsPHcihDbn6nBN9T6f3sW/S08N5YJFSCmuZzqO59c0nOAKILb6a3TsXjFEcu8 W8UfwFsZa6gx7iuYqandhoHBEkkc5NSwMe1f+lPiV2MdclzQ4/VtZ7Oa1VB+RftD Am4+w/Y= =Fju1 -----END PGP SIGNATURE----- **** This is a timestamp of the above message: -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQBVAwUAMDGsOeWrvYiumrHZAQF0QwIAnDWdVVTiVmUTY5lp08yPeLRoFetczb+U E0WVgTUJ4a16tinOPaJl/6jOpPUUPWMjkDaD2N1xw8lGqm0UgZJiGIkAkgMFATAx uKJTWcEkFWm4oQEBAQ8D5ixvYrpEAQYfeNXmbB46BTTnBwBPS/JjfVFEEnC0Zsoj cyh/WELUsZf785b23vEq9JFvZB+bq1UsJTpttl335TrW344ZYof3kl6fdEF2Jf5q LxQjkuP9s/OQX5iJZpHz4LUxbb+/hOwSdZ2O3LV7ETiHs9AK1+bnKfOGDyei =qO7V -----END PGP MESSAGE-----

5 4

Breaking RC4-40 for less
by fc＠all.net 17 Dec '03

17 Dec '03

Since messages sent with netscape are fairly standard for the first so many bytes, why not make a 2^30 element table, store it on a few gigabytes of disk space, use a hash table on the message, and find the keys to one in every 1,000 messages about 1 time per second. If this code is being used to send millions of credit transactions per day, we should be able decode thousands of credit card numbers per day for a one-time cost of about $5,00. The $10,000 estimate of the cost of computing time is far too high for a production-based attack on the netscape codes. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

1 0

Re: Phone call for Mr. Doligez, was Re: SSL challenge -- broken !
by Peter Wayner 17 Dec '03

17 Dec '03

I don't think that there is any serious worry for Netscape. Their security is fine-- it's just crippled by the US Government. They could probably start distributing binary versions of their software that used full 128 bit keys in several hours. It's just that the Government gets pissed off about these things. In general, it just adds more flames to the fire started by the letter written by Microsoft, IBM and Lotus. Their point is bolstered by this easy attack. -Peter

3 2

Re: SSL challenge -- broken !
by Hal 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: Damien.Doligez(a)inria.fr (Damien Doligez) > This is to announce the solution of the SSL challenge posted by Hal > Finney on July 17, 1995 (message-ID: <3u6kmg$pm4(a)jobe.shell.portal.com>), > also found at: <URL:http://www.portal.com/~hfinney/sslchal.html> Although it is hardly necessary, I can confirm the accuracy of the decryption found, and I extend my congratulations for this achievement! Ironically, I understand that an independent effort coordinated by Adam Back also discovered the key at approximately the same time. In addition, Eric Young had done a search starting at 8000000000 and upwards; unfortunately the key value of 7ef0961fa6 was only about one percent below his starting point. Hopefully Adam will supply more information. It will be interesting to see what the fallout is from this accomplishment. It should provide ammunition for the current effort by Microsoft and other companies to try to persuade the government to allow the export of full 56 bit DES. Knowing the tendency of the media and the net to oversimplify, this will probably come out as "SSL is broken" just as the RSA-129 result led to "RSA is broken" stories. This would not be as egregious an oversimplification as in the RSA case, but in fairness it should be recognized that SSL as a spec provides support for much stronger ciphers than the intentionally weakened RC4-40 which was broken here, but Netscape was constrained by the government to supply browsers with only the weak encryption. I am a little alarmed by the suggestion that this news could have some marked impact on the Netscape stock price. From our perspective this was certainly an unsurprising result (not to take anything away from Damien and others who worked on it). It is a useful reminder that the things we work on here can have profound consequences. Hal Finney hfinney(a)shell.portal.com -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBMDIuehnMLJtOy9MBAQHQbwH+I0YL1ewcCbXOGw8yYvKXIJMg15O0jmqW wMb6SKrethbJzpWXJBpC1oKrl8wVzPvqBCLJtfJFWcN9xD4pTOluhA== =0GPy -----END PGP SIGNATURE-----

7 7

FBI Files on Clipper Releas
by Dave Banisar 17 Dec '03

17 Dec '03

FOR RELEASE: August 16, 1995, 2:00 p.m. EST CONTACT: David Sobel (202) 544-9240 FBI FILES: CLIPPER MUST BE MANDATORY WASHINGTON, DC - Newly-released government documents show that key federal agencies concluded more than two years ago that the "Clipper Chip" encryption initiative will only succeed if alternative security techniques are outlawed. The Electronic Privacy Information Center (EPIC) obtained the documents from the Federal Bureau of Investigation under the Freedom of Information Act. EPIC, a non-profit research group, received hundreds of pages of material from FBI files concerning Clipper and cryptography. The conclusions contained in the documents appear to conflict with frequent Administration claims that use of Clipper technology will remain "voluntary." Critics of the government's initiative, including EPIC, have long maintained that the Clipper "key-escrow encryption" technique would only serve its stated purpose if made mandatory. According to the FBI documents, that view is shared by the Bureau, the National Security Agency (NSA) and the Department of Justice (DOJ). In a "briefing document" titled "Encryption: The Threat, Applications and Potential Solutions," and sent to the National Security Council in February 1993, the FBI, NSA and DOJ concluded that: Technical solutions, such as they are, will only work if they are incorporated into *all* encryption products. To ensure that this occurs, legislation mandating the use of Government-approved encryption products or adherence to Government encryption criteria is required. Likewise, an undated FBI report titled "Impact of Emerging Telecommunications Technologies on Law Enforcement" observes that "[a]lthough the export of encryption products by the United States is controlled, domestic use is not regulated." The report concludes that "a national policy embodied in legislation is needed." Such a policy, according to the FBI, must ensure "real- time decryption by law enforcement" and "prohibit[] cryptography that cannot meet the Government standard." The FBI conclusions stand in stark contrast to public assurances that the government does not intend to prohibit the use of non-escrowed encryption. Testifying before a Senate Judiciary Subcommittee on May 3, 1994, Assistant Attorney General Jo Ann Harris asserted that: As the Administration has made clear on a number of occasions, the key-escrow encryption initiative is a voluntary one; we have absolutely no intention of mandating private use of a particular kind of cryptography, nor of criminalizing the private use of certain kinds of cryptography. According to EPIC Legal Counsel David Sobel, the newly- disclosed information "demonstrates that the architects of the Clipper program -- NSA and the FBI -- have always recognized that key-escrow must eventually be mandated. As privacy advocates and industry have always said, Clipper does nothing for law enforcement unless the alternatives are outlawed." Scanned images of several key documents are available via the World Wide Web at the EPIC Home Page: http://www.epic.org/crypto/ban/fbi_dox/ -30- _________________________________________________________________________ Subject: FBI Files on Clipper Released _________________________________________________________________________ David Banisar (Banisar(a)epic.org) * 202-544-9240 (tel) Electronic Privacy Information Center * 202-547-5482 (fax) 666 Pennsylvania Ave, SE, Suite 301 * HTTP://epic.org Washington, DC 20003 * ftp/gopher/wais cpsr.org

3 4

Eudora/Trumpet encryption
by Sean A. Walberg 17 Dec '03

17 Dec '03

I'm a crypto newbie here, but does anybody know how Trumpet Winsock and/or Eudora encrypt the passwords in their .ini files? I am trying to write a front end for a client and would rather it set up automatically rather than the program ask. How would I go about cryptoanalysing this? If it were a simple XOR, then wouldn't Plaintext1^Cypher1 == Plaintext2^Cypher2 and so on? Thanx for any help you can give me on this matter, Sean o-------------------o----------------------o-----------------------o | Sean Walberg, | Tech Support | Pas_al, _obol, BASI_, | | sean(a)escape.ca | escape communication | PostS_ript, T_L... | | Mail for PGP key | 925-4290 | C fills all the holes | o----------------] http://www.escape.ca/~sean [--------------------o

3 2

Re: SSL challenge -- broken !
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 1:45 PM 8/16/95, Hal wrote: >I am a little alarmed by the suggestion that this news could have some >marked impact on the Netscape stock price. My apologies for causing alarm. I was merely making a too-subtle joke about hysteria in the press and the capital markets for Netscape, and its inevitable backlash. Madness of crowds and all that... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Erroneous HPCwire phone #
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Whoops... Hope this helps! Cheers, Bob Hettinga --- begin forwarded text Date: Sat, 12 Aug 95 04:22:08 PST From: "Alan Beck" <alan(a)tgc.com> X-Minuet-Version: Minuet1.0_Beta_4 Reply-To: <alan(a)newsmaster.tgc.com> X-Popmail-Charset: English To: rah(a)shipwright.com Subject: Erroneous HPCwire phone # Robert, I can't reach my managing editor, who's a cypherpunk subscriber, so I'm emailing you: HPCwire's telephone number was posted incorrectly. Our real number is: 619-625-0070. I'd appreciate it if you could revise the post. Thanks much! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alan Beck HPCwire Associate Editor 8445 Camino Santa Fe HPCwire Suite 204 alan(a)hpcwire.tgc.com San Diego, Calif. 92121 Voice: 619/625-0070 Fax: 619/625-0088 For a free trial subscription, email: <trial(a)hpcwire.tgc.com> ~~ Diagonally parked in a parallel universe. ~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0