December 2003 - cypherpunks-legacy

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

17 Dec '03

Congratulations on demonstrating the effort required to break SSL with a 40-bit key. It seems clear demonstrated that this is not adequate to store, say, company-confidential information for communication over insecure networks, since it seems the average grad student at a large university could get access to similar computing power that you used (spare cycles on a hundred workstations or more). However, I disagree with your conclusion: > 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. Your credit card number, expiration date, etc, are continually being revealed to minimum-wage clerks all the time, unless you never use the card. A chain is only as strong as its weakest link; it makes no sense to buy an expensive lock when your door has a big enough opening to climb through. Should some bad person get hold of your card number and misuse it, you're not out any money: you just tell the card company "I didn't buy that". Since there's so much tracing in the system, if you buy a physical something with a stolen credit card number it can usually be traced to you (who'd they ship the package to?). It's not clear to me that *any* encryption is really essential if the only purpose is to protect credit card #'s from snoopers. There's plenty of stuff that *does* need protection, but I'm not sure credit card #'s head the list. Q: Of the 20,000 credit card #'s stolen from Netcom's computer, how many were used to buy things? Answer: not sure, but expect the answer is "zero".

2 1

Re: SSL challenge -- broken !
by goedel＠tezcat.com 17 Dec '03

17 Dec '03

Perry E. Metzger <perry(a)piermont.com> writes: >Joe Buck writes: >> However, I disagree with your conclusion: >> >> > Don't trust your credit card number to this protocol. >> >> Your credit card number, expiration date, etc, are continually being >> revealed to minimum-wage clerks all the time, unless you never use the >> card. > >On the other hand, those clerks can be traced down in most cases and >have fairly limited numbers of cards they get. It might be very >profitable to run a vacuum cleaner operation on the net slurping down >credit card number or other confidential information and then selling >it in bulk to people who could exploit it. Most credit card companies ship their registration information off shore to low tech developing countries. The idea is that the people entering the information are unlikely to be able to exploit the information they are exposed to. Capturing a set of credit card tapes is certainly profitable, as would be capturing large volumes of numbers, as you suggest. Now, are those West African credit fraud rings dialing up DEC, SUN, and SGI? :-) DJK P.S. There could be an article in tomorrows WSJ about the SSL Challenge. The technical details and facts will surely be mangled. :-(

1 0

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

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

Re: CoS Raid on "Copyright Terrorist"
by Duncan Frissell 17 Dec '03

17 Dec '03

At 09:28 AM 8/14/95 -0400, Futplex wrote: >Some CoS news: > >This past Saturday (95/08/12) a prominent Church of Scientology litigator, >Helena Kobrin, and some U.S. federal marshals raided the home of Arnaldo >Lerma, seizing pretty much all his computer hardware, disks, etc. So why is it that people insist on listing their home addresses with their ISP's rather than a mail receiving service or something else. It is very hard to raid a mail drop and obtain anything useful. While it is true that if you blow up buildings, the Fibbies may be able to find you, quite simple techniques can frustrate even quite dedicated private parties. DCF "We warned you mental defectives back in '65 that the socialized medicine offered by Medicare and Medicaid would be expensive, lousy, and eventually not there at all but you didn't believe us. Good luck."

4 3

Doing the SSL challenge
by Eric Young 17 Dec '03

17 Dec '03

Boy, go away for a weeks holidays and every-one else has all the fun :-). Just a few quick ramble about my searching of the top half of the key space in the first SSL challenge, please ignore if you are sick of this thread. All these estimates of the cost in CPU time are a bit silly. I started out using a few of our bigger machines at work but when people noticed I just stoped using them. My main workhorse machines became desktop boxes that nobody used at night. Quite a bit of my %50 keyspace was done by 5 dual processor sparc 20's that people around me had on their desktops. Most of the rest was done by about 50 486's that I rsh'ed to each night (I just tried to rsh to every Solaris/x86 box in the company :-). Out of a company of about 300 people, about 2 (who did not know about my attempt on the challenge) asked me about this processing and what was I actually doing, no-one else really noticed :-). I was making no particular effort to use every machine I could but I was still able to do about %2.5 of the key space each 12 hour night and %12.5 each weekend. If I made a real effort to harness the compute power at my work I would have probably been able to run at twice this rate but that would have required work on my part, alot more people would have noticed and it would have had an impact on people doing real work. The way I was seaching had no impact. I will also say that screen-savers running on the above mentioned 486's were a real pain, perhaps we will change xlock so they can only run the blank screen :-). I personally feel that using mas-pars is cheating a bit :-). People are aware that something is going on when a machine that big is grunting away all weekend :-). There is so much CPU sitting on people's desktops that is just unused that there is very little need to use the big central boxes. The relative speed on some of the machines I used is as follows (per CPU is in brackets) 6 CPU SGI challenge 37 (6.1) 5 (1.6) 2 CPU sparc 20 7 (3.5) 1 1 CPU 486 DX50 1 I could never realy get more that 1/2 the SGI but I could always get 5 sparc 20's and 50+ 486's without anyone noticing. So I was getting the 2.5 6CPU SGI challenge's from idle machines on people desks. eric -- Eric Young | Signature removed since it was generating AARNet: eay(a)mincom.oz.au | more followups that the message contents :-)

1 0

Re: Programlike Texts
by geeman＠best.com 17 Dec '03

17 Dec '03

Also coming to mind is the well-known notation for dancers ... I believe it's called Laban notation. At 09:46 AM 7/29/97 -0400, you wrote: > >One argument that is made by the government when trying to defend its >export restrictions---which are really publishing restrictions---on >cryptographic software is that they are not trying to regulate the >communication of information but rather the functionality of the >software. > >Now this has never made any sense to me, but that does not mean that >the argument can just be ignored. > >So I have been looking for examples of texts that are analogous to computer >programs but that are executed by something other than a computer. > >So far the best example that I can think of, and I doubt that one can >find a better one, is the instructions given to a drill team. > >I have looked at the drill manual for the U.S. Naval Academy that is >located at <http://www.nadn.navy.mil/MISLO/DRILL/drillman.html> and >it sounds exactly like a manual for some rather specialized computer >language dealing with mathematical objects that can be subjected to >various rotations and other transformations.

1 0

[NOISE] Re: Basically F-C-ed
by Alex de Joode 17 Dec '03

17 Dec '03

I wrote earlier: [..] : : Orlando, Fla., August 20 (AP) -- Two explosives were : : planted in a professor's suitcase to test airport : : security measures in Amsterdam, The Netherlands, and were : : discovered when he arrived in Orlando, officials said : : Saturday. : [..] : : Kensel said such security measures were normal for : : Europe. : : "Particularly in Europe, there are grave concerns about : : security issues," he said. "As a result, they do conduct : : various security programs regularly. This was part of a : : routine check of their own security systems. : : "The bag got away from them basically," he said. : Airport police was very quick to point out that such practices : were legal, now when they do that ...... The Dutch Department of Justice stated that there was no legal basis for such practises, Airport Police are forbidden to use 'innocent travelers' as decoy. -- Alex de Joode Fear Uncertainty Confusion and Kaos, Inc.

1 0

NEXT CHALLENGE: plan of action?
by fc＠all.net 17 Dec '03

17 Dec '03

I would like to offer all.net as a repository for the sources and executables for all platforms. We can put them in the gopher server for all to access. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

1 0

Re: Netscape security
by Damien.Doligez＠inria.fr 17 Dec '03

17 Dec '03

>From: altitude(a)cic.net (Alex Tang) >It seems that one of the problems with Damien's >cracking job was that it was "not sanctioned". Actually, INRIA's PR people are quite pleased with the publicity. They asked me to prepare an official press release to counteract the Wall Street Journal's "evil hacker" story, which was unfortunately reprinted by some papers. The Herald Tribune is particularly bad in this respect. If some media insist on this "evil hacker" thing, they will look more ridiculous than anything else (I hope). The press release will be out as soon as it gets through the red tape (the official opinion of a French administration is not something to be taken lightly, even though it's mostly facts :-) I'll put it on my web page when it's official (which is likely to be too late). -- Damien

2 1