- cypherpunks-legacy - lists.cpunks.org

Another SSL breakage...
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- All hell seems to have broken loose whilst I was lazing on the beach yesterday. SSL breakings, big name newspaper newsreports (of varying degrees of accuracy), and much ITAR bashing (yay!) or perhaps that should be nooooh! 'cos I might be doing myself out of work as a UK crypto hacker (as John Hemming said in the article Robert Hettinga forwarded) if we loose the fun advantage of being in the free world, and not having to follow the ITAR nonsense. Anyway, congratulations Damien! As Hal said, another group was working on the SSL challenge (albiet just for software testing purposes). Here's the story.... on Tue, 15 Aug 1995 10:43:15 +0200 I recieved this from David Byers <davby(a)ida.liu.se>: > Eureka! > > Encrypted Master Key: 7ef0961fa6 > > [...] So who was first? David hit it Tue 10:43 GMT+2. Doesn't matter, the more the merrier, and the better to demonstrate the silly ITAR export restrictions. This was a trial run at breaking it which two people had done just to check if their respective software was working correctly. It appears that it was :-). This testing was some of the reason for the slowness in getting the group effort started, we were very keen to ensure it really would work, and that the software was working perfectly. Disappointment with the RC4 bruting demonstrated the importance of checking first. On with the story, Davids eureka arrived Tuesday, I tinkered with it some, but was interpreting it wrongly and left it for that day, then I was away yesterday (at the beach with wife and kids, nice weather over here), and figured out how to apply the key this morning (with a bit of prompting from Hal as to what I was doing wrong), just after reading Damien's announce on cpunks, where he independently bruted it on a farm of workstations. Here's the output, with the "Mr Cosmic Kumquat" from "SSL Trusters Inc": > PPOST /order2.cgi HTTP/1.0Referer: 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+ (I won't bother formating it more cleanly as Damien has already done the honors). I think a group effort ought to be done now that we are confident of the software, just to see how darn fast we (cypherpunks as a group) can knock off SSL keys. (This one was done by 2 people for testing purposes, and independently by Damien (who we didn't know was working on it)). I'd really like to work up to a really meanly few hours breakage, as it looks that much more impresive. The next media release ought to be of a steady offer, of the form, cpunks break keys in x hours, where x is a very small number. And not just break one key, but will break lots of keys, as required, until something is done about it (ITAR) :-) Eric Young is currently away on holiday, but I have his machine stats from earlier email, where he explained the hardware he was testing on. Eric swept 8000 - FFFF, and David 0000 - 7ef0 (where he hit the key) Machine stats for this bruting: 1 x 16k processor MasPar MP-1 - 1.5M keys/sec 4 CPUs of R4400 200mhz - 24000 keys/sec 4 CPUs of sparc 60mhz - 17500 keys/sec 2 CPUs of sparc 50mhz - 14800 keys/sec 1 CPU of Pentium 75mhz - 10200 keys/sec 1 CPU of Alpha - 10000 keys/sec 2 CPUs of 88100 - 8000 keys/sec 1 CPU of 88000 - 3500 keys/sec 1 CPU of R3000 36mhz - 3800 keys/sec 49 CPUs of 486DX 50mhz - 3780 per src The workstations total: - 424,320 keys/sec, and the Maspar 1.5M keys/sec on it's own. The 0000 - 8000 sweep was finished Aug 11 (he might have finished a day or two earlier, that's when he replied to my question as to how he was getting on. He left for his holiday after that email. The MasPar sweepings were going fast, swept 0000 - 795d (this was sometime before the 11th Aug) but someone else wanted the machine, so a pause ... and then (presumably Tues morning) 795d - 7ef0 and bang he hit it. We were getting worried about the possibility of software failure by then as we'd already swept 8000 - FFFF and 0000 - 795D accounting for 97.4% of the key space. It was hiding away in the last bit of unswept keyspace. Luck of the draw... A few quick calculations: The maspar alone could do the entire keyspace in 8 1/2 days, or an expected average time of ~100 hours. I believe I'm right that there would be lots of organisations which would sell you idle maspar hours for a lot less than $100 / hr. Heck you could do it with PC's, if they (WSJ article) think it's worth $10k all I can say is "give me the $10k", and I'll do it and make a handsome profit. The workstation farm, at 424k keys/sec could do the job in 30 days, or 15 days average. The workstation farm was only used to sweep half the key space, and was used overnight (12 hours) and weekends (61 hours) only as people were using the machines during the day. Could it have been done with out anyone knowing? Hell, yes - it was in fact, no announce was made as it was just testing etc. Adam - -- HAVE *YOU* EXPORTED RSA TODAY? --> http://dcs.ex.ac.uk/~aba/rsa/ - --rsa--------------------------8<------------------------------- #!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL $m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa 2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*',$_)while read(STDIN,$m,($w=2*$d-1+length($n)&~1)/2) - -------------------------------8<------------------------------- TRY: rsa -k=3 -n=7537d365 < msg | rsa -d -k=4e243e33 -n=7537d365 -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMDNbnSnIuJ1VakpnAQHe9AP8DJBhZ8LyRNx7PO1GY076Cap+xzdS0/ys WE/tdm0GBfjqxvjtar85mmc1hZVPCn1m5Swsflk2ZpieLbwUzHz+g1ciW3IiZu1Y 8Qc2HJxWRrez3J5CeiMHgMJl6Bj6vF5XAWLW0v6NpujbOR9XuIjsKnH3jKvkhLF5 z0u7Oui0AX0= =nkmn -----END PGP SIGNATURE-----

5 4

Denver area meeting, SUNDAY, 8/20, 2 pm
by adwestro＠ouray.cudenver.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This one is on SUNDAY, 2 pm, at the Tivoli Food Court (at least initially). Send email for directions, etc. Alan Westrope <awestrop(a)nyx10.cs.du.edu> __________/|-, <adwestro(a)ouray.cudenver.edu> (_) \|-' 2.6.2 public key: finger / servers PGP 0xB8359639: D6 89 74 03 77 C8 2D 43 7C CA 6D 57 29 25 69 23 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Exon blows goats...but I suspect you already knew that. iQCVAwUBMDOBpVRRFMq4NZY5AQEnVAP8CLg9z5AwjIw0ouJtxPPr6CUytFOeVPrt cMrEm8MRUt0ay0S4F+TGMq1npcF8pxdU0jwWk9EBj+1XvTOKVpEED+kp8shafsVj qlWGplAVUHMTF19H1VAByoz7j3VGMB2zmdNDm2ifDMNzR5Di81o7CeyvQT0sZ6zt 5XGWmHkoX3g= =GD3W -----END PGP SIGNATURE-----

1 0

Re: Idle compute cycles [Re: Netscape's Offical Response]
by Damien.Doligez＠inria.fr 17 Dec '03

17 Dec '03

>From: Jim Gillogly <jim(a)acm.org> >and one thing that seems to miss the point. As usual, I agree with all Jim has to say, but there's another problem with Netscape's response: they UNDERestimate the cost of breaking RC4-128 (by brute force) by a factor of about 300 trillion. If someone know of an URL for Netscape's response, I'll be glad to include a pointer in my virtual press conference. I would have to ask for permission before I put a copy on my disks. Copyrights, you know... -- Damien

1 0

Breaking DES anyone? (was: Breaking RC4-40 for less)
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

Fred Cohen <fc(a)all.net> wrote on cpunks: > 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. Nice idea and one which works for pure RC4, but unfortunately not for 128 bit, 88 bit known + 40 bit unknown "export" SSL. Netscape's SSL uses "40 bit keys" that are composed in a strange way: you are given 88 bits of known key, and this is combined with the 40 bit key, to give a 128 bit key. That key is used to do the encryption. The problem is that this has a unix password salt like effect, only this time there are 88 bits of salt rather than 12 bits. So this means that you can't precompute anything on the 40 bits as the 88 bits are randomly generated, and likely vary with each session. > The $10,000 estimate of the cost of computing time is far too high > for a production-based attack on the netscape codes. Agreed, it's too high for the other reason that lots of people have spare compute cycles. Idle cycles have low to non-existant incremental cost, and there are plenty of them around in the world. Back to breaking crypto systems. There are a couple of things you can do, there is your pre-compute some proportion of the key space - so that you get some of them, this would work well for straight 40 bit RC4 - and there are quite probably such products around - microsoft has a number of "secure" [sic] things around the Microsoft Access we were looking at earlier, another system for doing remote access (modem) and having the sessions encrypted. The problem with micro$oft is they are a darn closed system, and no-one so far has invested the time to decode what they're doing with a debugger. That was the reason for the failed brute RC4 a while back - no specs. So precompute regions of keys would work on pure RC4-40 as you describe. It would be fast too - a disk seek time being the bounding factor - per key! Another approach is to do lots of keys simultaneously - so you set up this distributed effort which is continually re-sweeping the 40 bit keyspace, say every couple of days or whatever. You can sweep for more than one key at once at very low incremental cost, an extra key costs close to nothing. So say you are searching for 1000 keys at once - a dragnet approach - well keys just pop out at random as they are hit, maybe straight away maybe at worst case the sweeping roll-over time, but on average a key will fall out every 3 minutes. The same approach is applicable to 1 guy with 1 humble PC, it'll sweep the full keyspace it in a year or two, but what does he care if he gets a couple of keys a day, and they're all nice transactions he can pilfer / make nefarious use of. DES breaking schemes... Something similar applies to DES, I mean what's a piffling 56 bit keyspace if you don't really care *which* key of several thousand that you actually want. There are bound to be a large enough supply of DES encrypted banking transactions flowing around the various financial networks in the US to make a nefarious breaking of them emminently possible. It moves on the time for a complete sweep as you now have 56 bits to contend with - but I think with a team of say 1024 workstations like the one I am typing on (an SGI Indy ~$5k workstation) in a distributed effort, and a large supply of DES keys, you could get a workable break on *one* of those keys in a shortish time how long? Well I'm not sure how fast DES can be made to go for these purposes, but 60k keys/sec is a figure I have for DES set_key (Eric Youngs code on a Sparc 20) I'm not too sure of the details of what you'd need to brute a DES key, but setting up the key, and presumably a small additional cost to test the first byte and every 256 tries to test 2 bytes etc. Anyone know if 60k keys/sec sounds reasonable for a DES brute? Anyway working on that, 1024 workstations, 60k keys/sec = 60 M keys/sec = 37 years! But (here's the saving bit) if you try say 64k keys *at once* so you've hoovered up a stack of keys (hypothetically - technically plausible too a tap on a banking network should yield you a whole load of them) *then* you can get much nicer figures: A DES key every 5 hours! I'm thinking 1024 workstation equivalents shouldn't be insurmountable to organise - lots of people have faster / multiprocessor machines, and farms of workstations / PCs etc. Perhaps 64k keys is a bit generous, and 1024 keys would be a more sensible figure, even then that translates to 13 days expected. As some one said a while ago (breaking) Netscape is the big win! Breaking DES is *the* big win! Adam -- HAVE *YOU* EXPORTED RSA TODAY? --> http://dcs.ex.ac.uk/~aba/rsa/ --rsa--------------------------8<------------------------------- #!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL $m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa 2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*',$_)while read(STDIN,$m,($w=2*$d-1+length($n)&~1)/2) -------------------------------8<------------------------------- TRY: rsa -k=3 -n=7537d365 < msg | rsa -d -k=4e243e33 -n=7537d365

2 1

Cost to Crack Keys
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

Tim May <tcmay(a)got.net> writes: > >Hmm, I don't know about anyone else around here, but my workstation is > >idle 99% of the time. I could almost certainly get access to all the spare > >CPU cycles on 120 workstations for free, and I suspect that a lot of > >people (particularly hackers) could do so as well. There's no need to > >spend $ 10,000 on renting them. > > But, Mark, estimates of the cost to crack a key _must_ be based on market > prices, not on opportunistic access to machines. Such access is good for > occasional, or one-shot, deals, but not for routine use. > > For example, one doesn't say "Hey, I don't see how Hertz can charge $40 a > day to rent a car...my friend lets me use his for free." > [...] > "Standard accounting practices" dictate the way to estimate production costs. Agreed. *But* the real cost to a particular organisation, is subsidised by the amount of idle compute cycles they have. You can't take this into account very easily or accurately for a general figure, where raw $ are probably the best figure. For instance I know someone who works for a large UK newspaper (he's admin for their unix workstations), and he says there are acres of RS6000s just sitting there idling most of the time. They are used for document preparation only (what a waste all that lovely silicon just burning cylces, and being occasionally used as a glorified word processor). Anyway point being to that particular organisation, if they for some reason (I dunno but say a big scoop - they need to nefariously break something to get the low down on a politician - unofficially of course), their real cost is quite a bit lower than the raw $, perhaps 0 cost even if they can wait long enough for their impromptu farm to do the job. This doesn't really affect the raw $ cost as such, people just need to estimate the amount of wasted $ equivalent of idle compute they already have in their personal calculations. It would sound better if various news papers would care to print something along the lines of "with idle compute powers as many typical organisations have in abundance". Papers printing high sounding $ figures is though technically accurate (perhaps not too sure about the accuracy), mis-leading to general public who probably don't realise that there is a few $100 tho of idle compute lying around in the accounts department already! In summary, yes but it doesn't sound as good, and folks don't equate idle CPU to $ intuitively. Adam -- HAVE *YOU* EXPORTED RSA TODAY? --> http://dcs.ex.ac.uk/~aba/rsa/ --rsa--------------------------8<------------------------------- #!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL $m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa 2/d0<X+d*La1=z\U$n%0]SX$k"[$m*]\EszlXx++p|dc`,s/^.|\W//g,print pack('H*',$_)while read(STDIN,$m,($w=2*$d-1+length($n)&~1)/2) -------------------------------8<------------------------------- TRY: rsa -k=3 -n=7537d365 < msg | rsa -d -k=4e243e33 -n=7537d365

1 0

The Official Cypherpunks Screen Saver?
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:11 PM 8/17/95, Jim Gillogly wrote: >I would hazard a guess that 90% of the compute cycles in the world are used >running screen savers... this gives a <lot> of slack for people who would >like to harness them to perform productive work like making points about >the strength of security. It would really be cool to have a screen saver that did useful work while displaying pretty pictures. Imagine a screen saver, maybe with code modules running in "After Dark," that updates the screen with keys tried...could be a nice demonstration of bignums in crypto, etc. Every now and then the user would get lucky and alarms would go off... (Details: getting the modules to automatically divvy-up keyspace...or maybe just let user pick his own key, or from a list, or whatever. A la the "Chinese lottery" keycracking scheme, where set-top cable boxes (containing computers) crunch on keys and try to match to signals sent over the air...Schneier may have something on this in his book.) Just a thought. The "Official Cypherpunks Screen Saver"? I'd rather have this running on my Mac than have a t-shirt. --Tim May (Berkeley Systems, makers of "After Dark" for Macs and Windows, supports third-party modules. Maybe the "Flying Toasters" could swoop down, pick up a "key" laying on the "ground" and proceed to munch on it...the mind boggles.) ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net (Got net?) | anonymous networks, digital pseudonyms, zero 408-728-0152 | knowledge, reputations, information markets, Corralitos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

2 1

RC40 and what we still need to do
by Robert A. Hayden 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have been watching the backlash of the cracking of RC40 and am quite impressed with the fact that it is being used as a positive reason for repealing ITAR. I expected the media to jump on the "hacker" bandwagon and denounce the efforts. However, I think there is still value in writing the software that will allow cooperation amoung hundreds or thousands of people. That way, we could harness the space CPU of machines all over the globe and make the cracking of this kind of stuff routine. So instead of taking 8 days, it takes only a day or so, further eliminating the idea that it "takes too long to be worthwhile". Maybe there would even be value in going at a 128-bit key (granted, it would take a year). I'd anticipate with proper advertising, easy-to-use software, and little programming knowledge require, we could easily harness 10,000+ machines and a few dozen parallel machines. I know we have a 99.9% idle MasPAR I can contribute to the effort, which should be able to do 1million+ keys/sec. It's just dying to have a purpose.... -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Signed with PineSign 2.2 iQCVAwUBMDNwmDokqlyVGmCFAQEzTQQAtkDhi0XD1L1PGJgSYA0XcxMXOIszjtB0 sQcHdSqeVHBpIn7K0/F4JE0tiIgXFhmaKsU8FaIaf/5sbDpRj/cTZXnvE/evt4G0 GKploXjcqXQ/dBpSWakCzsKLJvqvhKEyZyAnF/5VHgSI5WChMKYm68qiuDNyN05Q He6bvbZGbBs= =oPni -----END PGP SIGNATURE----- ____ Robert A. Hayden <=> hayden(a)krypton.mankato.msus.edu \ /__ Finger for Geek Code Info <=> Finger for PGP Public Key \/ / -=-=-=-=-=- -=-=-=-=-=- \/ http://krypton.mankato.msus.edu/~hayden/Welcome.html -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++ E---- W+(-) N++++ o+ K+++ w--- O- M+ V-- PS++>$ PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++ G+++++ e++ h r-- y++** ------END GEEK CODE BLOCK------

2 1

Strong encryption for credit cards only
by Hal 17 Dec '03

17 Dec '03

In response to the SSL break, Netscape has said they are working on improved encryption specifically for credit card numbers. This would use 56 bit keys, presumably DES. I got this from the SJ Mercury News online, <URL:http://www.sjmercury.com/nav.htm>. While we can applaud any measure to increase user privacy and security, it will be unfortunate if this enhanced encryption, which will apparently be limited strictly to credit card information in order to get export approval, weakens support for efforts to allow expanded export approval of all sorts of encryption. There are many aspects to privacy beyond credit card numbers. The bottom line remains that overseas companies are able to put stronger encryption in their products than American companies can in their export versions. We need to keep offering good arguments for why users will need strong encryption for more than their credit card info. If the message gets out that this new measure solves the security problems on the internet then that will be a big loss for our goals. Hal

1 0

Dumb question (Re: RSA T-Shirt)
by George T. Talbot 17 Dec '03

17 Dec '03

Sorry to bother the entire list with this...anybody got the e-mail address of the USA seller of the 3-lines of Perl RSA T-Shirt? I haven't received mine yet and I can't find the e-mail address. Again...Sorry for adding to the traffic. ---------- George T. Talbot <george(a)phat.com>

1 0

Re: First known purchase of physical goods with cyberbucks
by Matt Thomlinson 17 Dec '03

17 Dec '03

don't forget GhostMarks! :) matt ---------- From: Timothy C. May <tcmay(a)got.net> To: "Marcel van der Peijl" <bigmac(a)digicash.com>; <mark(a)unicorn.com> Cc: <cypherpunks(a)toad.com>; <ecm(a)ai.mit.edu>; <steve(a)webmedia.com> Subject: Re: First known purchase of physical goods with cyberbucks Date: Thursday, August 17, 1995 11:59AM At 6:39 PM 8/17/95, Marcel van der Peijl wrote: >> Anyway, if anyone knows of an earlier transaction of cyberbucks for physical >> goods than this (at 15:00 GMT 17th August 1995), then please let me know. > >As far as I know, the first transaction took place when I (while >testing) bought a postcard from GlobalX, the first ecash store to >open besides our own (and mine). It is stored in the 'DigiCash >museum' next to early prototypes of all kinds of smartcards, >emulators, wallets etc. > >This must have been around October last year (or August? Can't make >out the postmark). Hundreds of cards were shipped by several shops, >and stickers, lotteries, etc. Check the 'physical objects' section >on http://www.digicash.com/shops/categorical.html > >Maybe you should restrict the 'first known' claim to 'first known >purchase of physical goods with cyberbucks traded at the ECM'. > >Sorry! Also, there are other potential claims for this sort of thing. Based on varying extents to which the "electronic money" is really secure, is cryptographically interesting, etc. For example, more than two years ago on this list (I think it was spring of '93, but it could've been spring of '94) there were a flurry of transactions involving the "MagicMoney" and "TackyTokens" of Pr0ductCypher and others. I recall Black Unicorn and others talking about transactional exchanges involving sixpacks of beer or soft drinks. I could check my archives, but you get the point. And before that, there were "HExmarks" being used on the Extropians list. There was a nominal conversion rate to real dollars, and at the time I left that list, I had more HExmarks than anyone else. And dozens of token-based systems, coupons, LETS systems, etc. Not to mention the various commercial smartcards and "e money" systems. Granted, most of these are not "Chaumian," which is what most of us think of us as digital cash. Claiming credit for being first is a tough issue. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net (Got net?) | anonymous networks, digital pseudonyms, zero 408-728-0152 | knowledge, reputations, information markets, Corralitos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

1 0