December 2003 - cypherpunks-legacy

Re: U.S. Army Private Faces Spying Charges
by Peter Trei 17 Dec '03

17 Dec '03

> > Thomas C. Allard wrote: > > > > His father said an Army major at Fort Bragg, whom he declined to name, > > had urged him to persuade his son to sign a confession, so prosecutors > > would not seek the death penalty. > > Isn't plea bargaining wonderful? > > Gary Iff this guy is guilty (and I have no particular reason to doubt it), I was still under the impression that treason carried the death penalty only in wartime. Peter Trei trei(a)process.com

2 1

BOD_ies
by jya＠pipeline.com 17 Dec '03

17 Dec '03

8-23-96. FiTi: "The race is on for global groups to develop 'electronic purses' using smart cards." "We are moving into the electronic age where money will just be information about the wealth you have," says Visa. Some companies believe that parts of the body, rather than paper or coins, can be used to establish the amount of money somebody has available to spend. WaPo: "Group Plans Challenge To Net Address Monopoly." The end may be at hand for the virtual monopoly that Network Solutions holds over the registration of Internet addresses. The Internet Assigned Numbers Authority, the Internet Society and IETF will organize a competition for the right to operate new registries. The group's aim is to create alternatives to the established categories of Internet addresses. NYP: "Flaw Said to Be Found in Microsoft's Browser." Markoff's report on the Princeton group's discovery. ----- http://jya.com/bodies.txt (17 kb for 3) BOD_ies

1 0

The Future Of Cyber Terrorism
by Joseph M. Reagle Jr. 17 Dec '03

17 Dec '03

The Future Of Cyber Terrorism The proceedings or a recent conference on the subject of Cyber Terrorism are now available online. The conference looked at terrorism carried out with the tools of today's information age and against the computer and information systems that the world increasingly depends upon. World Wide Web: http://www.acsp.uic.edu/OICJ/CONFS/terror02.htm _______________________ Regards, I hate quotations. -Ralph Waldo Emerson Joseph Reagle http://rpcp.mit.edu/~reagle/home.html reagle(a)mit.edu E0 D5 B2 05 B6 12 DA 65 BE 4D E3 C1 6A 66 25 4E

1 0

secret message
by JOHN E. HOLT 17 Dec '03

17 Dec '03

Date: 01-Aug-96 14:50 EDT From: JOHN E. HOLT [76473,1732] Subj: puzzle ^%}{{ ZZ VVPAGMIGJEKMCCHIAKKPEHJDDDLOABGAMMJOCDFNOLNOKKKNIADPBGPPOEPIDCEMPGWW VVFCMOPKLKPJOHCNCJBDGOOJKFANCJJBDBMDIFIEKEDPLKDDGMPLHMIIPIJFMKOLENWW VVCAKJGJCKPAEOOMLJPNFJEKEINIHFKHNOLPCAHLEKHHLMHJFCOEKAFAGPHJBCPBHBWW VVOKLAENICAFDHEOEODMHMFGIONMAACAOHEOHDAJDNENGAHABNHGOCCPJNFDMAMKADWW VVMGDHKGPKBEIDBNLOCMLFMEIOKBFBFKJIMIIIFKJDFENCBPAPFBAOFMHEDODBFFPDWW VVOMFFJBNGEJPLGHJLFOBLFOGCBKAACEICLBIKHGILKCLMHPFIAHPDEOOODPPMLGDNWW VVGLDNEBDINMILDJDOJOJNKCLIBBKBCBEJPBJCFHGKMFLLEPGLGOOIIGAKJEGNPFHDWW VVIJBMFLALHPEHHGEGPCLGILBDBMEGMOGOIFBPPONGEDJPNFNMPCJFJPAEMIDOEMBLWW ZZ ZZ Distribution: To: ME > [76473,1732]

1 0

Re: (fwd) ANNOUNCE: Free Little PGP Credit Card App
by Alan Olsen 17 Dec '03

17 Dec '03

At 07:54 PM 8/22/96 -0400, Damaged Justice wrote: >>From: "David j. Sopuch" <djs(a)iwinpak.com> >Newsgroups: comp.infosystems.www.misc >Subject: ANNOUNCE: Free Little PGP Credit Card App >Date: Thu, 22 Aug 1996 12:00:24 -0400 >Organization: Datamax Research corp. >Lines: 10 >Message-ID: <321C8418.2647(a)iwinpak.com> > >v2.08 of the iWinpak Internet Payment System is now available in >both freeware and shareware versions at http://www.iwinpak.com An interesting little piece of CGI code, but the demo leaves a bit to be desired. The demo is for bank checks. The order form has you sending your bank information (including bank number and check info) in the clear. So the hooks into your credit card are not sent in the clear, but the ones to your bank are... Double plus ungood. It is a start... How good of one, I am not certain though... --- Alan Olsen -- alano(a)teleport.com -- Contract Web Design & Instruction `finger -l alano(a)teleport.com` for PGP 2.6.2 key http://www.teleport.com/~alano/ "We had to destroy the Internet in order to save it." - Sen. Exon "Microsoft -- Nothing but NT promises."

1 0

ctcp.0.9
by Damien Lucifer 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is a program i found on unimi that offers secure socket connections, utilitizing a simple server/client. It can be installed without root priveledges and uses d/h for key transfers. Anyone looked this package over, and if so what is your oppinion about it? Included below is the THEORY file that describes the key exchange: The encryption negotiation is performed using a protocol similar to FTP/SMTP/NNTP. The client sends commands to the server and the server returns a four-digit response code. Unless stated otherwise, all numbers in this document are hexadecimal with the most significant byte first. When a connection is initiated, the server should send a 2000 response indicating that it is ready to accept commands. Commands: DH3DES - Diffie-Hellman Key exchange followed by Triple-DES encryption If supported, 3001 is returned. The following commands are then expected: MOD - If an argument is supplied, it is the number, in hexadecimal, to use as the modulus. Responses: 2210 - okay 4031 - invalid number 4032 - too small 4033 - too large If no argument is given, the server should supply the modulus, sending 2211 followed by the modulus. If the server is unable to supply a modulus, 4034 should be returned. GEN - this should follow MOD. The generator to use. The format is the same as that of the MOD command. The response codes are 2210, 2211, 4031 or 4034 EXCH - Key exchange Client sends exch followed by gen raised to hir secret exponent. Server sends 4030 if a gen/mod has not been agreed upon. otherwise 2212 followed by gen raised to its exponent ENCR - Begin encrypted Session 4020 - No key selected for encryption 2300 - Encrypted session begin LPORT xxxx - this command takes a 16-bit hexadecimal port number argument, and connects to the specified TCP port on the local host. Responses: 2400 - connected 4010 - Unable to connect 4011 - Access denied RPORT xxxxxxxxxxxx - Connect to remote port The argument to this command is a 48-bit hexadecimal number representing the IP address and port number to connect to. The response should be first 2500, then when the connection has been attempted: 2400 - connected 4010 - Unable to connect 4011 - Access denied QUIT - quit Response: 2100 - Goodbye Summary of error codes: 1xxx - informational messages 10xx - server is supplying additional information that the client may ignore. 11xx - server is responding to a client's request for information 2xxx - okay 20xx - Server is ready 21xx - Disconnect, goodbye 22xx - Command okay 23xx - Encrypted session begins now 24xx - Session with another service begins now 25xx - Command ok, operation in progress, please wait 3xxx - ok so far, send the rest 4xxx - command was okay but could not be processed 5xxx - command not understood or not implemented Triple-DES The triple DES encryption uses output feedback exclusive-ored with a non-sequential counter. There are three counters, each of which is exclusive-ored with the data block before encryption with the corresponding key. The counters are incremented in each round by a shared, secret value which is part of the total key. The result of each round of encryption is exclusive-ored with the data stream. I0 ------ ----- | | | I1 ----- | ---A1------- | ---> \ | | \ | --XOR | --XOR | | | E1 | E1 | | | I2 ----- | ---A2------- | ---> \ | | \ | --XOR | --XOR | | | E2 | E2 | | | I3 ----- | ---A3------- | ---> \ | | \ | --XOR | --XOR | | | E3-------^ E3-------^ | | v v XOR with data stream I0 - Initialization Vector I1 - Initialization of counter 1 I2 - Initialization of counter 2 I3 - Initialization of counter 3 E1 - Encryption with Key 1 E2 - Encryption with Key 2 E3 - Encryption with Key 3 A1 - Add increment value 1 A2 - Add increment value 2 A3 - Add increment value 3 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMh219rGlo8DEMb2JAQEzWgP/VpcWiL8+UN+7l7wCtUr6N5Bk4iqG5fYq Jb9ImvVA3h2k8cGz/ETBQW/3H9GA9jCsqzLrgcUewAa8CgdmhPoVE04e2scAxp4l y2peJlQmakCl2RCKHJZPTTaOLnsBU4NCZxwW8Q4xeUb0KBYfiW9XeULleyhhfsO2 n7XYpc4XhaY= =vGhK -----END PGP SIGNATURE-----

2 1

Anonymous Remailers
by chris230＠juno.com 17 Dec '03

17 Dec '03

When you mail an item through more than one anonymous remailer, how does that make it anymore anonymous, or doesn't it?

1 0

FW: Cryptography Revisited
by Paul Robichaux 17 Dec '03

17 Dec '03

Anybody want to give this guy The Business? Earlier attempts didn't seem to sink in. -Paul >Path: HiWAAY.net!imci2!imci3!newsfeed.internetmci.com!news.mathworks.com!nntp.primenet.com!news.primenet.com!btcarey >From: btcarey(a)primenet.com (Brent A. Carey) >Newsgroups: comp.sys.mac.programmer.help >Subject: Cryptography Revisited >Date: 23 Aug 1996 01:15:01 -0700 >Organization: Primenet Services for the Internet >Lines: 67 >Message-ID: <btcarey-2308960115290001(a)news.primenet.com> >X-Posted-By: @198.68.41.180 (btcarey) >Mime-Version: 1.0 >Content-Type: text/plain; charset=ISO-8859-1 >Content-transfer-encoding: 8bit >X-Newsreader: Yet Another NewsWatcher 2.2.0 > >I am posting again to hopefully clear up my last post on this topic. I >have received a dozen e-mail replies since I posted less than a day ago. >I believe I poorly represented my request earlier. > >I am retired professional with several years of training and experience in >intelligence analysis and cryptanalysis. The encryption scheme I >developed was employed for 3 years for passing sensitive data over >unsecure channels. Working for the government, the original program was >written for DOS and enjoyed the benefit of physical security. That is to >say, access to the encryption program itself was carefully restricted. > >Where I feel I was unclear is on the key to the scheme's security. Any >encryption scheme can be cracked provided the cryptanalyst has enough of a >sample to work with, enough time, and/or enough processing power. My >encryption scheme relies on data bursts of time-sensitive packets. Each >machine running the program has its own time and packet signature. The >unique signatures make it impossible (nothing is impossible) to decrypt a >complete file without access to both the sender's and receiver's >signatures. Even then it would take an enormous amount of processing >power to crack (more than big business can justify, but not much for major >governments). The only way to obtain a computer's signature (which is >easily changed on a regular basis), is to have physical access to the >computer's encryption application and support files. > >With the help of a more experienced DOS programmer, an application was >built that provided adequate protection that would increase the time >required to extract a computer's signature (even if one knew exactly how >to do it), that it was impractical to attempt. > >I am now porting the application to the Mac with the intent to sell it to >a private contractor that is developing RISC-based computers for >specialized use in the government. I have been assured that a PPC native >application will run on the computers, and was encouraged to develop the >application. Mostly what I need to know is how long it would take a >super-human cracker to obtain a signature and how she would do it. If I >can increase the expected time to 96+ hours, I'm in business (I always >assume half of my best guess - 48 hours is the required specification). > >I am developing the code with the help of an excellent Mac programmer. >The problem is, that neither of us can crack it at all, although we know >that is theoretically possible. He lacks sufficient crypto understanding, >and I lack sufficient computer knowledge. Working together we make little >progress, and truthfully don't have enough time to develop and crack at >the same time. I will not be comfortable with the final product until >someone cracks it and I have a sound understanding of the weaknesses that >I have not considered. > >Finally, MacPGP is a GREAT program. I didn't mean to belittle any of the >PGP programs. PGP carries much more protection than necessary for it's >intended and practical uses. Granted, it could use a new interface, but >it is certainly functional and not lacking in features. Initially, I >considered releasing a public version of my application in response to the >need for a more Mac-like encryption program. There is no reason for the >average Mac user to switch from PGP to my program. It lacks (and will >always lack) the features of MacPGP, and although it is more secure than >PGP the user must accept some increased inconvenience to realize the bulk >of the added security. For most users, this is adding overkill to >overkill. > >I extend my apologies for posting this huge message off topic, but I felt >I had grossly misrepresented my request. I feared the influx of e-mail >tomorrow morning if I didn't clarify. I appreciate all those that >extended advice. I will follow up on much of it, and I thank those who >replied. > > >Brent A. Carey -- Paul Robichaux LJL Enterprises, Inc. paul(a)ljl.com Be a cryptography user. Ask me how.

1 0

Re: Re:phoneco vs X-phone
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

Don't forget opportunity costs. With the money it spent to put in the fiber optics, the phone company could have made some loans and gotten interest back. -Allen

1 0

Re: The Future Of Cyber Terrorism
by jya＠pipeline.com 17 Dec '03

17 Dec '03

http://www.acsp.uic.edu/OICJ/CONFS/terror02.htm This quackery-puffery is truely hilarious. Worth reading for brave attempt to distinguish between our-adorable-intelligent-children qua hackers and terrifying next-door-neighbors so differently-abled-from-us cyber-terrorists. Unsubtly shaded white, off-white, black and blacknet movie-plotting. Thus Sprachen Zarathrustran Klaus: Commerce in ignorant-inner-fear-panderings regulation time.

2 1