December 2003 - cypherpunks-legacy

new o'reilly security book
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

------- Forwarded Message Date: Tue, 15 Aug 1995 14:08:44 -0700 From: Sara Winge <sara(a)ora.com> Subject: New "Computer Crime" book from O'Reilly FOR IMMEDIATE RELEASE August 15, 1995 TO REQUEST A REVIEW COPY, CONTACT: Sara Winge sara(a)ora.com 707/829-0515 O'REILLY RELEASES HANDBOOK ON FIGHTING COMPUTER CRIME SEBASTOPOL, CA--"Computer Crime: A Crimefighter's Handbook" is a resource for anyone who needs to know what today's computer crimes look like, how to prevent them, and how to detect, investigate, and prosecute them if they do occur. It contains basic computer security information as well as extensive guidelines for investigators, law enforcement, managers, and computer system administrators. The book has been reviewed by representatives of the U.S. Secret Service, the Department of Justice, local police departments, district attorney's offices, and law enforcement abroad. "Computer Crime" describes the varieties of computer crimes and profiles the computer criminal, using techniques developed for the FBI and other law enforcement agencies. It outlines the vulnerabilities of computer systems and discusses personnel, operational, physical, and communications measures that can be taken to prevent computer crimes. In addition, it contains a thorough treatment of effective methods for investigating and prosecuting computer crimes, ranging from the supplies needed for criminal investigation, to the detection and audit tools used in investigation, to the presentation of evidence to a jury. # # # Computer Crime: A Crimefighter's Handbook By David Icove, Karl Seger & William VonStorch, with Consulting Editor Eugene H. Spafford 1st Edition August 1995 464 pages, ISBN: 1-56592-086-4, $24.95

1 0

nontoxic neuron interface built
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

for all of you eagerly awaiting the day you can literally "jack in" to cyberspace.. ------- Forwarded Message Date: Wed, 16 Aug 95 13:44:34 -0400 Subject: FW: 'Cyberpunk' neural interface? - - ---------- From: James McDaniel X-MsXMTID: red-14-msg950816203742MTP[01.00.00]0000009e-34570 The following item is taken from: http://www.hep.net/documents/newsletters/pnu/1995/pnu-236.html James - - -------------------- PHYSICS NEWS UPDATE The American Institute of Physics Bulletin of Physics News Number 236: August 7, 1995 by Phillip F. Schewe and Ben Stein A SILICON DEVICE FOR TRIGGERING ELECTRICAL ACTIVITY IN A NERVE CELL has been constructed, opening possibilities for two-way, non-toxic communication between computer chips and nerve cells. Previous devices for stimulating nerve cells were metallic devices generating ordinary electric currents. Not only do such devices have corrosion-prone electrodes, but their currents create electrochemical byproducts and heat that could damage the nerve cells and themselves. The silicon device, constructed by researchers at the Max Planck Institute for Biochemistry in Germany, contains a "stimulation spot" that triggers neural activity simply through the rearrangement of electric charge. Insulated by silicon oxide, the stimulation spot has a size (between 10 and 50 microns) matched to that of a leech nerve cell to which it is connected. A voltage pulse applied to the spot rearranges electric charge on the silicon oxide film and the insulating membrane of the nerve cell, creating a buildup of positive charge in the nerve cell which causes it to fire above a certain threshold. The silicon device is capable of triggering a single nerve cell without affecting other nearby neurons. The device complements the previously designed "neuron transistor," which receives ionic signals from nerve cells and transcribes them to electronic signals in silicon. "These two devices join the two worlds of information processing, the silicon world of the computer and the water-world of the brain," says the Max Planck Institute's Peter Fromherz (fromherz(a)vms.biochem.mpg.de) Developing this device for biomedical applications, such as computer-controlled artificial limbs, is not envisioned at the present moment, as researchers will first need to build and understand devices that interact with connective tissue and other non-neuronal cells in the body. (Peter Fromherz and Alfred Stett, upcoming article in Physical Review Letters; text and figures are available from AIP Public Information, 301-209-3091, physnews(a)aip.org.) - ------- End of Forwarded Message ------- End of Forwarded Message

1 0

WANTED: anonymous remailer source code
by quazi＠banyan.com 17 Dec '03

17 Dec '03

Hi All. I'm interested in porting some remailer code to work on NT (most likely using NTMail as the smtp service). I'd like to be sure I'm starting my port from the most recent revisions, and the sources at the archive at berkeley seem a bit dated. Are they the latest sources? Are there more recent sources available somewhere? Thanks, Quazi

1 0

Non-News Govt Announcement on Key Escrow
by banisar＠epic.org 17 Dec '03

17 Dec '03

The White House and NIST annouced today that they were planning to hold two open meetings next month to develop standards for "acceptable" software key escrow. The standards will then be made into a FIPS. The programs cannot have keys larger than 64 bits. Its great to see that it only took them 18 months (since Feb. 94) to come up with a call for public meetings for something that nobody really wants anyway, expcept for the officals who plan to make it mandatory by slipping it through bit by bit and a couple of vendors. (sorry, sarcasm mode off...) -d (in non-official sarcastic mode today from home) David Banisar (Banisar(a)epic.org) * 202-544-9240 (tel) Electronic Privacy Information Center * 202-547-5482 (fax) 666 Pennsylvania Ave, SE, Suite 301 * ftp/gopher/wais cpsr.org Washington, DC 20003 * HTTP://epic.digicash.com/epic

1 0

Re: More on Netscape
by koontz＠MasPar.COM 17 Dec '03

17 Dec '03

>It says that the commerce server supports (among others) DES and DES3 >(same as 3DES?). They list the key sizes as 64 and 192 bits >respectively. My question is, isn't DES 56 bits? (with an 8 bit salt >that would be 64 I guess), but isn't DES3 112 bits, not 192? DES keys are specified as 64 bits, of which 8 bits provide odd parity. The 192 bits would specify three independent keys (not triple DES)

2 1

Re: SSL challenge -- broken !
by ab411＠detroit.freenet.org 17 Dec '03

17 Dec '03

John Pettitt <jpp(a)software.net> writes: >On Wed, 16 Aug 1995, Damien Doligez wrote: >> 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. > >Exactly. > >> It fails on the second count. Don't trust your credit >> card number to this protocol. > >Huh? So you run on 120 workstations worth how much? to steal a credit >card number worth how much? Get real - there are hundreds of ways >to get credit card numbers that cost less. ... SSL can of course be used to protect information other than credit card #s. It is supposed to be strong enough to resist the attempts of amateurs, yet it was broken not by a government, not by a three letter agency, not by a major corporation, but by a grad student with a lot of spare cycles. In other words, it was broken by an amateur. The real issue is not cc#s, the real issue is: does it do what it was designed to do (foil amateur attempts), and the answer is: no, not so long as it is export-restricted to only 40 secret bits of key. -- David R. Conrad, ab411(a)detroit.freenet.org, http://www.grfn.org/~conrad Finger conrad(a)grfn.org for PGP 2.6 public key; it's also on my home page Key fingerprint = 33 12 BC 77 48 81 99 A5 D8 9C 43 16 3C 37 0B 50 Jerry Garcia, August 1, 1942 - August 9, 1995. Requiescat in pace.

1 0

I need an exportable crypto algorithm.
by Darrell Perko 17 Dec '03

17 Dec '03

Greetings; I realize that bad crypto is offensive to some here but I am in desperate need of an exportable, public-domain, general-purpose crypto algorithm. Or at least the rules for creating such. Sorry to bother y'all with this, but I am in dire straights. Thanks, Darrell Perko dperko(a)efn.org

2 1

Re: WANTED: anonymous remailer source code
by Alex de Joode 17 Dec '03

17 Dec '03

Quazi sez: : I'm interested in porting some remailer code to work on NT (most : likely using NTMail as the smtp service). I'd like to be sure I'm : starting my port from the most recent revisions, and the sources at : the archive at berkeley seem a bit dated. Are they the latest sources? : Are there more recent sources available somewhere? Try ftp.hacktic.nl:/pub/remailer -- Alex de Joode Fear Uncertainty Confusion and Kaos, Inc.

1 0

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

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