December 2003 - cypherpunks-legacy

Re: Cypherpunks the movie
by nobody＠replay.com 17 Dec '03

17 Dec '03

why stop at a video why not a musical.... "Cypherpunk The Musical" Broadway here we come... Featuring Songs: "PGP why is it so hard to break" "We write code" "Why were we called shitopunks?"

1 0

Re: Husband/Wife jailed for saying Clinton Sucks
by pjb＠ny.ubs.com 17 Dec '03

17 Dec '03

true, then there are those who are brain dead, and continue to participate, notice that i did not say serve, in public office for years. -paul > From zachb(a)netcom.com Thu Aug 22 19:18:40 1996 > Date: Thu, 22 Aug 1996 16:18:23 -0700 (PDT) > From: "Z.B." <zachb(a)netcom.com> > Subject: Re: Husband/Wife jailed for saying Clinton Sucks > To: pjb(a)ny.ubs.com > Cc: cypherpunks(a)toad.com > Mime-Version: 1.0 > Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII> > Content-Length: 487 > > On Thu, 22 Aug 1996 pjb(a)ny.ubs.com wrote: > > > perhaps we should all add a line to our sigs to the effect that we hope > > he dies, and soon, natural causes, of course. Hmmm, what exactly does > > 'natural death' include? > > > > -paul > > When I read this, a quote from a certain famous sci-fi writer came to mind: > "All forms of death are ultimately due to heart failure." > > > --- > > Zach Babayco > > zachb(a)netcom.com <----- finger for PGP public key > http://www.geocities.com/SiliconValley/Park/4127 > > >

1 0

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

Middleman has a new name!
by John A. Perry 17 Dec '03

17 Dec '03

It has been brought to my attention that the name "middleman" is too long for the DOS-based remailer programs. In lieu of this I'm changing the listed name middleman(a)jpunix.com to middle(a)jpunix.com. The change will be effective for both the type-I and type-II remailers. I will also make this change to the type2.list/pubring.mix files shortly. The remailers will continue to also answer to middleman(a)jpunix.com. John Perry - perry(a)alpha.jpunix.com - PGP-encrypted e-mail welcome! WWW - http://www.jpunix.com PGP 2.62 key for perry(a)jpunix.com is on the keyservers.

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

IE Security Flaw
by jya＠pipeline.com 17 Dec '03

17 Dec '03

Markoff reports today on the MS IE security flaw discovered by the Princeton team and posted here recently. See: http://www.nytimes.com/yr/mo/day/news/financial/web-browser-flaw.html

1 0

Re: Lesson 2 in cracking (cryptoanalysis 001)
by Scottauge＠aol.com 17 Dec '03

17 Dec '03

In a message dated 96-08-21 20:43:50 EDT, you write: >The point is that if you took two novels by the same author and >completely sorted them alphabetically they'd be almost the same. The examples cited did this by word, not by message as your stating. >So a block of PGP encrypted ascii-armored (i.e. 8=>7-bit encoding) >wouldn't affect the frequency counts? Tell me, how long have you been on >your current medications? I was talking about the algorithm as given, not PGP. > That's the point!! IT'S A JOKE!!! You know, "hahaha - very funny"? Not a > serious proposal? I know! But at least it is relevent to the group! How many points of attack have you seen on here? How many techniques have shown up here? P.S. My apologies to the fella I called a troll. It was uncalled for - lacking in social skills.

1 0

Re: Spamming (Good or Bad?)
by James C. Sewell 17 Dec '03

17 Dec '03

At 03:35 AM 8/23/96 +0000, Vipul Ved Prakash wrote: > >This is peculiar. Nobody seems to mind ads in Newspapers, printed >magazines, TV, and for that matter web sites. That is unwanted stuff I'd suggest that most/all of us 'mind' ads in papers, tv, etc. The difference is that while we can do nothing about commercials on TV (short of breaking federal law and jamming the signal) we can do something about spam. If there is enough concensus we can develop/distribute/encourage the use of new mailers that will help defeat spam. For example: If mail comes into a server that has more than 25 recipients then it is only forwarded to those who have "signed up" for that sender. When we subscribe to Cypherpunks we also have to register that with our network of mail servers. Then if Mr. Spam sends stuff out it's not been "signed up" for so it gets trashed. I don't really like mail servers redirecting my mail, but perhaps we could arrive at a reasonable criteria for filtering if we tried real hard. Jim Jim Sewell - jims(a)tansoft.com Tantalus Incorporated - Key West, FL

2 1

Verdict in "MTV" Case
by tcmay＠got.net 17 Dec '03

17 Dec '03

Indiannapolis, IN (A.P.) -- A jury has awarded the State of Indiana $25 million in damages in the case of "Indiana v. Music Television." Music Television, also known as MTV, was accused of costing the state of Indiana more than $100 million in additional educational expenses due to students watching MTV when they should have been doing their homework. The jury foreman in the case was quoted as saying, "Like, like the kids are, like, goofin' off. Besides, MTV doesn't like play enough old stuff, like Zeppelin and Floyd." Following the various court decisions to award damages to states for medical costs associated with smoking by state residents, a barrage of similar lawsuits is happening across the country. School systems are suing book publishers, movie makers, television broadcasters, shopping malls, and miniature golf arcades. Makers of sports equipment are facing crippling lawsuits by insurers. The last remaining American bicycle maker, Trek, announced that it is withdrawing from the U.S. market, following the $37 million judgement against it in "Oregon v. Trek." --Klaus! von Future Prime

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

"Regulation of Commerce" and the Crypto Issue
by tcmay＠got.net 17 Dec '03

17 Dec '03

It seems to me that in recent years nearly any type of sweeping legislation is justifed, constitutionally, by the clause in the U.S. Constitution which says Congress shall have the power to regulate commerce. (More precisely, the clause says: "To regulate commerce with foreign nations, and among the several states, and with the Indian tribes;" This is usually interpreted to mean _interstate_ commerce, and not sales/commerce/etc. that do not centrally involved more than one state....obviously nearly all things sold in one state are sold in other states, so there is lattitude for applying the commerce clause, albeit wrongly.) Today's news is the sweeping new restrictions on tobacco and cigarettes, including restriction on advertising and even on the placement of tobacco and cigarette logos and names on sports jerseys and shirts. (The much-publicized press event is not for another hour, as I write, so I don't know all the details. I'll be watching.) Note that similar restrictions on alchohol advertising were recently struck down by the Supreme Court as being unconstitutional infringements on free speech. Many expect the same outcome with these latest proposed restrictions. (The issue of advertisements of hard liquor, cigarettes, condoms, and other "unhealthful" [sic] products on television and radio is of course complicated by the role of the Federal Communications Commission and by "gentlemen's agreements" not to carry advertisements for some products.) Personally, I have never smoked, nor chewed, nor mainlined nicotine. Personally, I dislike cigarette smoke. But this is all _personally_. If a restaurant, bookstore, airline, bar, antique store, gym, or whatever wishes to allow smoking (or not), this is there choice. As many of us see things, it is not for the government to take a kind of "poll" of what people like and dislike and then to impose rules on property owners as to what smoking or nonsmoking policies they may set. Likewise, if I want to silk-screen a "Joe Camel" image, or a "Bud Frogs" image, on a t-shirt, this is between me and the putative owner of these images. Free speech and all. Or, to remove any confusion with the issue of owned logos, to silk-screen a fictitious cigarette brand on a shirt and then wear it, or sell it. It seems likely that individual wearers of such shirts will not be busted (think of how many already exist, and there is no plan for confiscating them), but that the burden will be placed, as it is so often conveniently placed, on the shirt makers. The catch-all for these laws seems to be the "regulate commerce" language in the Constitution. Cigarettes are sold in multiple states, the logic goes, so the commerce clause gives the government the power/authority to regulate it. (Well, Steven King novels are sold in all 50 states, too. Does this "regulate commerce" clause give the government the power/authority to regulate what King puts in his novels? Or to ban advertising for Steven King novels? Or to require that stores only sell such novels to adults?) This language is already being cited for some as a justification for regulating encryption (hey, some businesses use it!), digital signatures (ditto), and other forms of crypto. In fact, since nearly everything involves "commerce" in some way, whether interstate or not, the "regulate commerce" clause can presumably be used as a jusitification for interfering in all sorts of areas. The several legal experts out there on this list can clarify any errors of interpretation I have made. I certainly know that the commerce clause cannot be used to suppress certain kinds of speech, though the boundaries of where it may be applied seem unclear. I do expect it to be used for crypto, though, and this might even be upheld by the Supremes, especially in any areas directly involving "digital commerce." We should watch for this, and think about ways to deflect or derail such interpretations. --Tim May We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

3 2

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

strengthening remailer protocols
by peter.allan＠aeat.co.uk 17 Dec '03

17 Dec '03

This is long enough. I've been brutal and cut sections less likely to promote discussion. (I've also contacted OUP about Ganley's book, and may buy it if I can kid myself I don't need the money.) ============================================================ August 1996 Peter M Allan peter.allan(a)aeat.co.uk Strengthening Remailer Protocols STATUS OF THIS MEMO This memo proposes improvements for the Mixmaster protocol and requests discussion and further suggestions. Distribution of this memo is unlimited. INTRODUCTION Lance Cottrell's documents [1] and [2] describe the current Mixmaster protocol and attacks against it. This memo began as a response to those thoughts, but has developed in discussion with Cottrell. SPAMMING ATTACK [2] describes an active attack where many messages are sent to an honest remailer to separate a message of interest from other traffic. The aim is to clear other messages out of the message pool, wait for the target and finally eject that from the pool. The target message is identified because the attacker can recognise his own messages. Attempts to defeat this attack could well be based on preventing the attacker from recognising his own messages. That is the approach taken here. RE-ENCRYPTION AS A SPAM DEFENCE In this diagram remailer 'A' has received a message addressed to himself. Inside that is one to 'B' - unreadable to A. Further layers are hidden of course. AB????? decrypts to B????? This means that our remailer can only disguise the message by re-encrypting it on the outside. But the message has got to make some net progress toward delivery. The trick is that a remailer can find the outer two headers addressed to him and process both of them. Two headers processed and one rewound is net progress. When the header rewound is addressed to the same recipient as was next on the list anyway the diagram looks like this. Actions at 'A': AB????? decrypts to B????? B????? encrypts to BB????? Actions at 'B': BB????? decrypts to B????? decrypts to C???? encrypts to CC???? The beauty of this is that it is compatible with the existing protocol. If a remailer only knows about removing layers of encryption it still fits into a network where some can do both actions. Whether it sends or receives the message it still works. RE-ENCRYPTION IN THE MIXMASTER ROTATING QUEUE MODEL Instead of layers like an onion, Mixmaster has a queue of headers that get rotated. A used header goes to the back of the queue where it can never again be read. At some point the header at the front of the queue is found to be the last one, and the message is sent on its final hop. For a header queue the above actions look like this: Actions at 'A': AAAB??? -> AAB???a -> AB???aa -> BB???aa In general when the first H headers are addressed to the remailer reading them, (H-1) rotations will be performed, and the top header will be overwritten with another one with a random key and IV to encrypt the rest of the message. The number of headers present remains 20, however many or few of these are still to be read. No valid header block is ever overwritten, only used header blocks that are good for nothing. This is always possible because after a remailer receives a message at least the one header it has just read must be of no further use. This will hide the message content from eavesdroppers, but not from the next remailer in line - 'B'. Assume that remailer B is operated by an attacker, and that he directs spam messages there after host A (which is holding your message in the pool at the time of the attack). B can read all messages sent by the attacker (who knows B's private key). This is also why I think link encryption offers incomplete protection. RE-ENCRYPTION WITH CHEATERS Mixmaster assumes that no particular remailer in the network can be trusted and that the user does not know which remailers cheat. The message passes through a chain of remailers, who aim to hide information from each other so that the compromise of some of them will not disclose the original sender and final destination. Central to the spamming attack is the idea that the attacker can recognise the messages he is trying to trace. This is done by eliminating his own messages. The whole set - not just some of them. It can be arranged that the attacker does not obtain the whole set until it is too late to trace the target message (i.e. after a few hops, when it is likely to have met other legitimate traffic). The partial information the attacker obtains before all the spams are identified will be of some use, but following each of several leads with a new spam attack is unappealing as the number of suspect messages will just grow. The remailer needs the freedom to divert packets to another remailer. This is shown below; where remailer C was chosen at random. Actions at 'A': AAAB??? -> AAB???a -> AB???aa -> CB???aa Each remailer could have three options when sending a packet to its next host. 1) rotate all possible headers, and send the result (current protocol) 2) re-encrypt message with new 3DES key and IV. Do not divert. 3) re-encrypt message with new 3DES key and IV. Divert at random. Good probabilities for these options might be: 1) 20% P(1) = P(3) The number of headers the next host can read should not reveal whether a diversion has just been made. (We care about this because it discourages cheaters deliberately refusing to pass on your mail.) 2) 60% Other outgoing packets are not distinguishable from spams. 3) 20% Should not approach 100%. (To arrive is better than to travel in hope.) A spam attack as described in [2] would use many more packets than those in the message pool (N) on the host under attack. The number of spam packets diverted to honest remailers (a proportion R of the whole) would be about MANY . N . P(3) . R and those diverted twice in succession to honest remailers would be about MANY . N . P(3) . P(3) . R . R and I'd expect a figure above 5 here to thwart the spammer, because of the time taken to collect the 5 spams. This diversion (adding steps to the middle of a chain) seems different from a Middleman scheme [3] where extra hops are added at the end. This scheme does NOT allow a remailer to choose the rest of the chain to be followed. A dishonest remailer cannot bypass any remailer chosen by the original sender (in the hope of following the message to its destination) using only cooperating dishonest remailers) because the message has been encrypted in the public key of each remailer the sender chose before it entered the network. REFERENCES 1 Frequently Asked Questions about Mixmaster Remailers FAQ Version 1.8 July 4 1996 by Lance Cottrell <loki(a)obscura.com.> 2 http://www.obscura.com/~loki/remailer/remailer-essay.html by Lance Cottrell <loki(a)obscura.com.> 3 email "Re: middleman - what is it ?" "John A. Perry" <perry(a)alpha.jpunix.com>

4 3

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

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

Intel to rule the basic crypto engine market?
by Bruce M. 17 Dec '03

17 Dec '03

InfoWorld, August 19, 1996, p1 By Luc Hatlestad & Tom Quinlan ------------------------------ Looking to bring a standard infrastructure to hardware- and software-based encryption offerings, Intel Corp. has started developing a Common Data Security Architecture (CDSA) designed to integrate security software, operating systems, and third party applications. [...] ------------------------------ http://www.infoworld.com/cgi-bin/displayArchives.pl?960816.encryption.htm ________________________________ [ Bruce M. - Feist Systems, Inc. ] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ "Official estimates show that more than 120 countries have or are developing [information warfare] capabilities." -GAO/AIMD-96-84 So, what is your excuse now?

2 1

[off-topic] Re: Verdict in "MTV" Case
by Daemon 17 Dec '03

17 Dec '03

At 10:15 AM 8/23/96 -0700, Timothy C. May wrote: As the youngest Cypherpunk in the world (or at least i am aware of) I think a little reply is in order from my self. > "Like, like the kids are, like, >goofin' off. Besides, MTV doesn't like play enough old stuff, like Zeppelin >and Floyd." Thats what those old records are for. (no offense) If they are sueing MTV why not other TV stations.... If I was going to sue someone for not doing my homework i would sue Jarkko Oikarinen, the creator of IRC. I just think that this is really pathetic.... but then again I am famous for my flame replys in the past. Why not make the school pay MTV for keeping kids away from there station while they are doing homework (hehehe) FYI i thought this reply out. Blake Wehlage ========================================== Blake Wehlage <jwilk(a)iglou.com> ±» RëVðLû¡ØÑ Bø+ ©ÖmP@ñ¥ «± Goto: http://members.iglou.com/jwilk

1 0

Some cypherpunks-relevant Risks articles
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

In regards to the first part (the 911 transcript), I was considering the idea (common in cyberpunk RPGs) of a privately-set-up ambulance and emergency room service, with monitors (possibly with action capabilities) on registered clients. You'd want the data flow from and to the monitors encrypted, of course. -Allen From: IN%"rre(a)weber.ucsd.edu" 20-AUG-1996 22:41:21.74 To: IN%"rre(a)weber.ucsd.edu" CC: Subj: Risks: Atlanta 911 transcript, SSN's, web plagiarism [If you've never seen the famous Olympic Park 911 transcript, it's worth reading closely. I'm embarrassed to say this, but it always reminds me of the time I couldn't get a taxi in Chicago because I could tell the dispatcher what intersection I was standing on but I could not see any of the street addresses anywhere around me, and her dispatch computer needed an address to dispatch a cab. Dispatch systems requiring addresses are one of those absolutely classic cases of system being driven by the database designer rather than by the people who know how the system will actually be used. Database designers are fine people, but they shouldn't be doing requirements analysis unless they're trained for it. Also in this issue of Risks is an interesting message from Robert Ellis Smith about managing social security numbers and other identifiers for privacy, and a funny/scary piece about web plagiarism.] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was forwarded through the Red Rock Eater News Service (RRE). Send any replies to the original author, listed in the From: field below. You are welcome to send the message along to others but please do not use the "redirect" command. For information on RRE, including instructions for (un)subscribing, send an empty message to rre-help(a)weber.ucsd.edu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Date: Mon, 19 Aug 1996 18:11:10 -0700 (PDT) From: risks(a)csl.sri.com RISKS-LIST: Risks-Forum Digest Monday 19 August 1996 Volume 18 : Issue 35 ---------------------------------------------------------------------- Date: Fri, 16 Aug 96 10:45:34 PDT From: "Peter G. Neumann" <neumann(a)csl.sri.com> Subject: The Atlanta 911 transcript [The following transcript of the Olympic 911 bomb call and the ensuing conversation suggests that many of our nontechnological risks are not being adequately addressed. PGN] http://www.cnn.com/US/9608/09/olympics.bomb.911/911.transcript.wir/transcri… Excerpts from a transcript released Thursday by the Atlanta Police Department regarding the bomb threat telephoned to 911 on July 27. Times have been converted from military time to standard notation, and punctuation and spelling have been edited. Parenthetical notes are part of the police transcript except where labeled as an editor's note. The transcript refers to these police terms: Code 73, bomb threat; and Zone 5, a police precinct near Centennial Olympic Park. The transcript did not explain the Zone 5 dispatcher's references to Code 17 and Code 8, which apparently were unrelated to the bomb call. 12:58:28 a.m.: [Call to 911] 12:58:32 a.m.: Atlanta Police Department 911 Operator: "Atlanta 911." Caller: "There is a bomb in Centennial Park, you have 30 minutes." 12:58:45 a.m.: Caller hangs up. 1:01:20 a.m.: 911 operator calls APD Agency Command Center (all lines busy). .... 1:01:30 a.m.: 911 operator calls Zone 5 and notifies Zone 5 of Signal 73 and requests address of Centennial Park -- unable to get street address. Dispatcher: "Zone 5." 911 Operator: "You know the address to Centennial Olympic Park?" Dispatcher: "Girl, don't ask me to lie to you." 911 Operator: "I tried to call ACC but ain't nobody answering the phone ... but I just got this man called talking about there's a bomb set to go off in 30 minutes in Centennial Park." Dispatcher: "Oh Lord, child. One minute, one minute. I copy Code 17. OK, all DUI units are Code 8 and will not be able to assist on the freeway. Oh Lord, child. Uh, OK, wait a minute, Centennial Park, you put it in and it won't go in?" 911 Operator: "No, unless I'm spelling Centennial wrong. How are we spelling Centennial?" Dispatcher: "C-E-N-T-E-N-N-I -- how do you spell Centennial?" 911 Operator: "I'm spelling it right, it ain't taking." Dispatcher: "Yeah." 911 Operator: "Centennial Park is not going. Maybe if I take 'park' out, maybe that will take. Let me try that." Dispatcher: "Wait a minute, that's the regular Olympic Stadium right?" 911 Operator: "Olympic Stadium is like Zone 3, though. Centennial Park." Dispatcher: "That's the Centennial Park?" 911 Operator: "It's near the Coca Cola Plaza, I think." Dispatcher: "In 5?" 911 Operator: "Uh huh." Dispatcher: "Uh, hold on. Sonya, you don't know the address to the Centennial Park?" 2nd Dispatcher (in background): "Downtown." 911 Operator: "Male, about 30." Dispatcher: "1546, Code 17, 23." 911 Operator: "White." Dispatcher: "Uh, you know what? Ask one of the supervisors." 911 Operator: "No, Lord help me, you know they don't know." Dispatcher: "I know, but it gets it off you." 911 Operator: "Alrighty then, bye." Dispatcher: "Bye." 1:02:40 a.m.: 911 operator calls APD ACC for address (telephone line problem; operators cannot hear each other.) ... 1:02:50 a.m.: 911 operator calls APD ACC again and requests address for Centennial Park and is given the telephone number. ACC: "Atlanta Police, Agency Command Center." 911 Operator: "Hey, can you hear me now?" ACC: "Uh huh." 911 Operator: "OK, can you give me the address of the Centennial Park?" ACC: "I ain't got no address to Centennial Park, what y'all think I am?" 911 Operator: "Can you help me find the address to Centennial Park?" ACC: "I can give you the telephone number of Centennial Park." 911 Operator: "I need to get this bomb threat over there to y'all." ACC: "Well." 911 Operator: "But I need the address of Centennial Park. It's not taking, the system is not taking Centennial Park, that's not where it came from, but you know the system is not taking Centennial Park, that's where he said the bomb was." ACC: "No particular street or what?" 911 Operator: "He just said there's a bomb set to go off in 30 minutes in Centennial Park." ACC: "Ooh, it's going to be gone off by the time we find the address." 911 Operator: "Are you kiddin'? Give me that, give me that." ACC: "I mean I don't have an address, I just have phone numbers." 911 Operator: "Give me the phone number." ... 1:05:10 a.m.: 911 operator calls Centennial Park for street address and is placed on hold. Receives address at 1:07:10 a.m. Centennial Park: "Centennial Park, this is Operator Morgan." 911 Operator: "Hi, can you give me the address to Centennial Park?" Cen Park: "The address?" 911 Operator: "Uh huh." Cen Park: "Uh, hold on a second." 1:06:30 a.m.: 911 operator notifies Communications Supervisor, Sgt. Montgomery. 911 Operator: "Does anybody -- Sgt. Montgomery, do you know the address of Centennial Park? Do you know the address to Centennial Park. Well, I need to get the address of Centennial Park 'cause, I mean I don't mean to upset nobody, but we got a bomb threat over there." (Editor's note: The transcript does not further indicate whether this comment about a bomb threat was directed only to Sgt. Montgomery in the 911 center or to Centennial Park's Operator Morgan, who is shown to come back on the line just after the comment.) Cen Park: "Ma'am." 911 Operator: "Yes." Cen Park: "OK, it's 145 International Boulevard." 911 Operator: "145 International Boulevard." Cen Park: "Uh huh." 911 Operator: "OK." Cen Park: "All right, uh huh." 911 Operator: "Thank you. Bye bye." 1:08:35 a.m.: 911 operator sent call to dispatch. 1:11:10 a.m.: Dispatcher: "1591. Radio raising 1594." Unit 1594: "1594. You call?" 1:11:20 a.m.: Dispatcher: "1594, that's affirmative, got a Signal 73 at 145 International Boulevard. It came from the pay phone at the Days Inn. The caller is advising that he has one set to go off in 30 minutes at Centennial Park. Sounded like a white male." (Editor's note: The same information is then given to Unit 1593 and the dispatcher calls Unit1546.) 1:12:30 a.m.: Dispatcher: "Did you copy?" 1:12:40 a.m.: Unit 1546: "1546. I copy. Advise the state police, they police that park. I'll go the Days Inn and see if I can locate the caller." Dispatcher: "OK, that's affirmative." (Editor's note: There are sporadic entries over the next seven minutes. Another officer, designated Unit 1593, also instructs the dispatcher at 1:18:50 a.m. to "contact the state police supervisor." The transcript contains no indication, however, that state police were notified.) 1:20:00 a.m.: Unit 2924: "2924 to Radio, be advised that something just blew up at Olympic Park." ------------------------------ Date: Fri, 16 Aug 96 15:24 EST From: Robert Ellis Smith <0005101719(a)mcimail.com> Subject: Alternatives to Social Security Numbers Last spring, I asked readers of RISKS for suggestions on alternatives to Social Security numbers in organizations with large data bases of information about individuals. Many such organizations find they do not need to use SSNs, and avoid privacy problems associated with using them. For a copy of all of the responses, send a request to us and specify whether you want hard copy or electronic edition of our August issue, and provide postal address or e-mail address. Robert Ellis Smith, Publisher, Privacy Journal newsletter, Providence, RI, 401/274-7861, e-mail 5101719(a)mcimail.com. Excerpts from the suggestions follow: * FROM WASHINGTON, D.C.: Maryland uses Soundex (of name and birth date concatenated [linked in a chain]) both for driver and vehicle registrations. * FROM CAMBRIDGE, MASS.: "Against Universal Health-Care Identifiers" in the JOURNAL OF THE AMERICAN MEDICAL INFORMATICS ASSOCIATION 1:316-319, 1994, by Dr. Peter Szolovits of MIT and Dr. Isaac Kohane of Children's Hospital in Boston, discusses a number of ways in which cryptography- based health care identifiers can be used to preserve privacy while remaining manageable for typical medical purposes. This is publication #49 (in Postscript format) at http://medg.lcs.mit.edu/people/psz/publications.html. * FROM YARDLEY, PA.: One way is to use a simple scheme like three letters from last name, the first initial, and some digits; another is just to use sequential numbers. Another is an MD5 hash of the full-name string [a one-way mathematical function as a stand-in for the name that makes translation back to the original name impossible]. This is always unique for a unique string, so you might need to add some numbers. * FROM MADISON, WISC.: When I was working on the development of the Wisconsin Student Data Handbook - we tried to develop what we called an "SSN surrogate," also of nine bytes per individual. It involved an algorithm which combined year, month, and date of birth with sex and two consonants each extracted from the first and middle names. * FROM CYBERSPACE: I worked with a banking software company that set up employee records simply by exact hire date and time. Since they never hired anyone at exactly the same time, it gave each person a unique number. You could do the same for any data base in which records are added gradually one at a time - just number them based on exact date and time added. * FROM PALO ALTO, CAL.: At Stanford University we made a decision long ago not to use SSN for identification except where required by law (payroll taxes, for example). We use a unique Stanford University ID (SUID), which is a lifetime number and applies to all students, alumni, faculty, staff, and patients. It serves all the same purposes that the SSN would do if it were used. ------------------------------ Date: Wed, 14 Aug 1996 00:03:42 +0200 From: "Roy Dictus, NET" <roy(a)net.be> Subject: The risk of plagiarism with Websites My company recently got ripped off by a competitor. We build Websites and thus had constructed a site detailing our products and services. A rival Website constructor (!) copied practically the entire site, changing the background color, changing our name into theirs, and making other slight changes like alignment, add and delete a word or phrase here and there... I complained about it, not only to them directly, but also on a local USENET newsgroup (we're both located in Belgium, so the newsgroup was be.providers). On the phone they just laughed at me and admitted to copying, but on USENET they claimed I had copied their site! There's nothing I can do to prove them wrong, even though we both know what happened. The risk: if you put your materials on the Internet, where they can be freely copied, make sure you have some way to prove you made them yourself, and when you did it. Roy Dictus, NET bvba, Internet Projects & Consulting roy(a)net.be http://www.net.be [Interdictus becomes Enter Dictus. PGN] ------------------------------ End of RISKS-FORUM Digest 18.35 ************************

1 0

Re: CyberTerrorism
by jya＠pipeline.com 17 Dec '03

17 Dec '03

On Aug 23, 1996 18:34:42, '"Institute for Security and Intelligence" <isi(a)hooked.net>' wrote: >John: > >Your message regarding my comments on CyberTerrorism was forwarded to me. >Rather than waxing poetic beration, how about some actually useful >perspective? > >If you have experience in this area, let's talk. If you have something to >contribute, let's get it out where it can be useful. > >It's time to put up, or shut up John. > >Regards, >Barry C. Collin --------- Dear Mr. Collin, Thank you for writing. And for the cyber-terrorism hoot, which helps purge ignorant fears with insightful laughter. The best way I know for citizens to ease their induced- panic of terrorism in all forms -- gov, com, edu, org -- is to become more informed. And to be wary of "terrorist threats" in all their burgeoning guises -- "national security" being one of the most deceitful. To counter Nat Sec snake oil in the rising commerce in "cyber-terrorism" (a residue of the natsec oil tank) citizens should participate in the wit and wisdom of wide-open Internet mail-lists dealing with computer privacy and security. The best of these is the list Cypherpunks. (E-mail "info" to majordomo(a)toad.com.) Cypherpunks, far more tolerant and less treacherously commercially self-serving than all others, explores an amazing range of CompSec issues, technologies, policies, strategies and fantasies. Its archive of several years offers a historical treasure on the transformation of state control of comp tech to its service of the citizenry. This is exemplified by Cypherpunks primary focus, cryptography, and the diverse ways it has moved from narrow use to conceal privileged power to widespread application to protect individual privacy (especially those dissenting to heirarchical authority -- gov, com, edu, org). Your agent provocateurist comedy on cyber-terrorist inebriation could be enriched by hanging on Cypherpunks, say, your buffoonery for secret briefing. "If you knew what I knew" is a natsec-butt joke there, as it is becoming globally to liberated citizen-units bellowing "FA." Congrats on exposing TLA-dementia of cyber-terrorism and defanging its counter-agents by encouraging belly- laughing at the all-too-blatant hype-artistry. Only Jim Kallstrom does it better. Best regards, jya

1 0

SecureDrive News 8/24/96
by Edgar Swank 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- SecureDrive Users: It's been brought to my attention that users who attempt to compile SecureDrive 1.4b using Turbo C++ 3.00 are haveing a problem in that the MD5 routine does not produce a correct result, so that the key generated from a given passphrase will not be the same as the pre-compiled version. This is a bug in Turbo C++, not SecureDrive! However, a bypass for the problem is possible by modifying SD source as follows - ------------------------------cut here----------------------- *** C:\SECDR14B\UNC\MD5.C Sun May 09 19:38:36 1993 - --- MD5.C Wed Aug 14 00:58:46 1996 *************** *** 12,17 **** - --- 12,20 ---- * of the MD5 routines in RSAREF. Due to this alteration, this * code is "derived from the RSA Data Security, Inc. MD5 Message- * Digest Algorithm". (See below.) + * + * Simplified some expressions to avoid incorrect compiles with + * some compilers, e.g. Turbo C 3.0 EWS 8/96 */ /* *************** *** 135,145 **** - --- 138,158 ---- /* transform if necessary */ if (mdi == 0x40) { + #if defined (__TURBOC__) for (i = 0, ii = 0; i < 16; i++, ii += 4) + { + in[i] = (((UINT4)mdContext->in[ii+3]) << 24); + in[i] |= (((UINT4)mdContext->in[ii+2]) << 16); + in[i] |= (((UINT4)mdContext->in[ii+1]) << 8); + in[i] |= ((UINT4)mdContext->in[ii]); + } + #else + for (i = 0, ii = 0; i < 16; i++, ii += 4) in[i] = (((UINT4)mdContext->in[ii+3]) << 24) | (((UINT4)mdContext->in[ii+2]) << 16) | (((UINT4)mdContext->in[ii+1]) << 8) | ((UINT4)mdContext->in[ii]); + #endif Transform (mdContext->buf, in); mdi = 0; } *************** *** 167,178 **** padLen = (mdi < 56) ? (56 - mdi) : (120 - mdi); MD5Update (mdContext, PADDING, padLen); ! /* append length in bits and transform */ for (i = 0, ii = 0; i < 14; i++, ii += 4) in[i] = (((UINT4)mdContext->in[ii+3]) << 24) | (((UINT4)mdContext->in[ii+2]) << 16) | (((UINT4)mdContext->in[ii+1]) << 8) | ((UINT4)mdContext->in[ii]); Transform (mdContext->buf, in); /* store buffer in digest */ - --- 180,201 ---- padLen = (mdi < 56) ? (56 - mdi) : (120 - mdi); MD5Update (mdContext, PADDING, padLen); ! /* append length in bits and transform 1.4c*/ ! #if defined (__TURBOC__) ! for (i = 0, ii = 0; i < 14; i++, ii += 4) ! { ! in[i] = (((UINT4)mdContext->in[ii+3]) << 24); ! in[i] |= (((UINT4)mdContext->in[ii+2]) << 16); ! in[i] |= (((UINT4)mdContext->in[ii+1]) << 8); ! in[i] |= ((UINT4)mdContext->in[ii]); ! } ! #else for (i = 0, ii = 0; i < 14; i++, ii += 4) in[i] = (((UINT4)mdContext->in[ii+3]) << 24) | (((UINT4)mdContext->in[ii+2]) << 16) | (((UINT4)mdContext->in[ii+1]) << 8) | ((UINT4)mdContext->in[ii]); + #endif Transform (mdContext->buf, in); /* store buffer in digest */ - ------------------------------cut here----------------------- This code will be inserted into any future version of SecureDrive, but no new release is planned at this time. For those users of Win95 and SecureDrive who are concerned about loss of 32-bit disk access, I've recently learned that use of Secure Device ftp.demon.co.uk:/pub/ibmpc/secdev/secdev14.arj instead avoids this requirement. Although the Secure Device virtual drive is listed as in compatibility mode, the real drives are not so affected. And since the virtual drive is mapped to a dos file on one of the real drives, I believe you get 32-bit phyical drive access there as well, although access is still slowed by CPU time necessary to encrypt and decrypt. Edgar W. Swank <edgar(a)Garg.Campbell.CA.US> Edgar W. Swank <EdgarSwank(a)Juno.com> Edgar W. Swank <Edgar_W._Swank(a)ilanet.org> Home Page: http://members.tripod.com/~EdgarS/index.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCUAwUBMh7d4t4nNf3ah8DHAQHNdAP3RKd07B55fkW5CazT8mMaGUoTtjxSvUBv 3ykPvBhHvu7egb4EB1/XcBTM3K/6QeE8Dt10XJVX15Fd9nHY+XI0c0VB8Trlb/NB 0ymq+/SchedtUNmCgDeycbF104bfirpuXKy0OChDfpgMe0d/ifCXny6Co0BqIbRi fQyKtXzOxQ== =h1RT -----END PGP SIGNATURE----- -- edgar(a)Garg.Campbell.CA.US (Edgar Swank) The Land of Garg BBS -- +1 408 378-5108

1 0

"----- Message body suppressed -----"
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 1:10 AM 8/21/96, Skip wrote: > ----- Message body suppressed ----- > Sounds good to me. Keep it up. --Tim May -- [This Bible excerpt awaiting review under the U.S. Communications Decency Act of 1996] And then Lot said, "I have some mighty fine young virgin daughters. Why don't you boys just come on in and fuck them right here in my house - I'll just watch!"....Later, up in the mountains, the younger daughter said: "Dad's getting old. I say we should fuck him before he's too old to fuck." So the two daughters got him drunk and screwed him all that night. Sure enough, Dad got them pregnant, and had an incestuous bastard son....Onan really hated the idea of doing his brother's wife and getting her pregnant while his brother got all the credit, so he pulled out before he came....Remember, it's not a good idea to have sex with your sister, your brother, your parents, your pet dog, or the farm animals, unless of course God tells you to. [excerpts from the Old Testament, Modern Vernacular Translation, TCM, 1996]

3 2