December 2003 - cypherpunks-legacy

Re: Quants vs Congress
by Mike Markley 17 Dec '03

17 Dec '03

---------- | From: Timothy C. May <netmail!tcmay(a)netcom.com> | To: John E. Kreznar <jkreznar(a)ininx.com> | Cc: <cypherpunks(a)toad.com> | Subject: Re: Quants vs Congress | Date: Wednesday, April 13, 1994 8:13PM | | Received: from relay2.UU.NET by netmail.microsoft.com with SMTP (5.65/25-eef) | id AA14155; Wed, 13 Apr 94 19:20:40 -0700 | Received: from toad.com by relay2.UU.NET with SMTP | (5.61/UUNET-internet-primary) id AAwlnp10043; Wed, 13 Apr 94 23:21:22 -0400 | Received: by toad.com id AA17257; Wed, 13 Apr 94 20:13:54 PDT | Received: from mail.netcom.com (netcom5.netcom.com) by | toad.com id AA17248; Wed, 13 Apr 94 20:13:47 PDT | Received: from localhost by mail.netcom.com (8.6.4/SMI-4.1/Netcom) | id UAA15518; Wed, 13 Apr 1994 20:13:38 -0700 | Message-Id: <199404140313.UAA15518(a)mail.netcom.com> | In-Reply-To: <9404140219.AA09878@ininx> from "John E. Kreznar" | at Apr 13, 94 07:19:36 pm | X-Mailer: ELM [version 2.4 PL23] | Mime-Version: 1.0 | Content-Type: text/plain; charset=US-ASCII | Content-Transfer-Encoding: 7bit | Content-Length: 1913 | Sender: netmail!owner-cypherpunks(a)toad.com | Precedence: bulk | | John Krexnar writes: | | (Duncan Frissell's section elided) | | > Aw c'mon Duncan. Derivative of what? What's a quant? Where was the | > term ``intermediation of political risk'' used? | > | > I love your postings when I can make sense of them. This one is so well | > encrypted I can't. | | "Derivatives" mean secondary financial instruments, based on ("derived | from") things like stocks, bonds, and real estate. Things like futures | markets, "baskets" of other instruments, etc. These started, it may be | argued, in the trading pits of Chicago, but have now spread around the | world. I think I recall reading (in "Time"'s cover story last week on | derivatives and quants, ironically enough--the Wall Street nerd with | the "messy room" has replaced the hacker as the Number One Threat to | Civilization) that $ 4 Trillion in derivatives trades _daily_. | | "Quants," closely related to "rocket scientists," are those who use | math and statistics for investment purposes. Short for "quantitative." | | I urge all Cypherpunks who can afford to do so to subscribe to "The | Economist." It's filled with good, incisive articles, including the | best treatments of breaking science and technology stories in any | general magazine. Shoot your t.v., maybe, but don't let your | subsription lapse. Available also on newstands, whence information on | subscribing may be found (read the mag long enough, and you too will | speak in terms of "whence"). | | --Tim May | | | -- | .......................................................................... | Timothy C. May | Crypto Anarchy: encryption, digital money, | tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero | 408-688-5409 | knowledge, reputations, information markets, | W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. | Higher Power: 2^859433 | Public Key: PGP and MailSafe available. | "National borders are just speed bumps on the information superhighway." | The derivatives market is a very dangerous place also. In yesterdays financial section here in Seattle there was an article about how Proctor and Gamble is reporting a loss of over $100 million in the mortgage derivative market. Also in RISKS Digest 15.75 there is an article with the subject ' God Grants Granite Gift to RISKS Punsters' that talks about a company losing $600 million over the period of several weeks in the deriviative market. Mike. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mike Markley || The opinions here do not represent the mmarkley(a)microsoft.com || opinions of my employer. Attempts to || associate the two are pointless. "I want to look at life, In the available light" - Neil Peart -

2 1

Re: Soldier of Fortune
by Duncan Frissell 17 Dec '03

17 Dec '03

M > M >This seems counterproductive. PGP should not be portrayed as a tool M >for those that most Americans consider antisocial. M > M >M Carling M > A quote from pgpdoc1.doc: "If privacy is outlawed, only outlaws will have privacy. Intelligence agencies have access to good cryptographic technology. So do the big arms and drug traffickers. So do defense contractors, oil companies, and other corporate giants. But ordinary people and grassroots political organizations mostly have not had access to affordable "military grade" public-key cryptographic technology. Until now." Now Phil wrote PGP in part so that "grassroots" political organizations could have strong crypto. SOF is a "grassroots political organization." It happens that some people don't like SOF. It happens that some other people think that the organizations that Phil was thinking of when he wrote PGP are unamerican communist front organizations who should be on the Attorney General's List (if we still had an Attorney General's List)(if we still had an Attorney General). Tastes differ. The point of cypherpunks is that everyone (even FBI agents) should have strong crypto if they want it. I know that Phil feels a personal sense of embarrassment at being adopted by all sorts of nut groups (including ourselves) and he has pleaded for stories of "worthy PGP use." Standards of worthiness will vary. DCF Who, as it happens, *is* a member of an organization on the Attorney General's list. --- WinQwk 2.0b#1165

2 1

Re: fake pgp messages
by Ian Turton 17 Dec '03

17 Dec '03

> > > in the process of doing stuff to fight traffic analysis, i need to generate > > > a bunch of fake pgp messages. it is possible to asciiarmor random > > > bits, but this is pretty easy to spot. does anyone know a good > > > way to generate a large amount of bogus pgp messages? > > > > What better way than to generate real pgp messages that encrypt noise files? > > Just generate pseudorandom binary data of pseudorandom length (biased > > toward the length of real messages), and encrypt with pgp, using the > > public key of some person's key from a public server, selected at > > random. If you want to be able to spend less cpu time, you could hack a > > copy of pgp to simulate doing this, of course, using the symmetric key > > cipher (idea) in a stream cipher mode. > > > > Better "noise" might be _real_ words, paragraphs, etc. > > It occurred to me once that some of the remailer operators could > bounce the cypherpunks mailing list around through their remailers > to get more traffic/noise. why not take a random news group comp.talk.eff seems like a good one and encrypt that and mail out one article whenever you need or whenever your news server recieves one. You could then tailor the frequency by choosing high or low volume news groups. > > Cort. > > > Ian Turton - School of Geography, Leeds University 0532 -333309

1 0

Code review is requested.
by kafka＠desert.hacktic.nl 17 Dec '03

17 Dec '03

In article <199404110553.AA00997@xtropia>, you write the following: AN> Cypherpunks review code! AN> AN> I have written a hack to allow pgp's random.h and random.c to be used AN> with a hardware random number generator. I have mailed this to a AN> number of U.S. cypherpunks with the request that the hack be AN> distributed widely in the U.S. test --- "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 4 1994 == To get PGP, FTP /pub/unix/security/crypt/pgp23A.zip from ftp.funet.fi ==

1 0

NBC's Kaul
by Jeff Davis 17 Dec '03

17 Dec '03

Well, NBC's Alan Kaul and I had a discussion a few moments ago. Apparantly a helicopter crashed and this is old news. He has been instructed by NBC superiors to move on. The downplaying by the NSA was key. It wasn't another "Pentagon Papers" leak. He's got my unlisted number and asked if he could call from time to time to use me as an informed source, and asked to be kept on my mailing list. I guess I'll scrounge up that abitrary finger data from the AmEmbMoscow.gov deal and send that to him as an item of interest. Perhaps a CIA hand was logged on when that stuff popped up on the screen... This is not a topic for discussion. I know some of you have grown to care about me, and some rip me routinely. I am responsible and accountable for my own actions. "Those who risk nothing, are nothing, do nothing, and become nothing." By the time you rebut, that finger information will be gone. -- PGP PUBLIC KEY via finger! JAFEFFM Speaking & Thinking For Myself! * eagle(a)deeptht.armory.com email info(a)eff.org * *** O U T L A W S On The E L E C T R O N I C F R O N T I E R **** ***** Committed to Free Public Internet Access for World Peace *****

1 0

Re: Soldier of Fortune
by m＠BlueRose.com 17 Dec '03

17 Dec '03

I happen to like SOF, and I don't think most Americans have a bad opinion of it (certainly some do, but that is true of any publication). But SOF's appeal is much broader than just "mercs and wannabees" [Sandy's words], and that "mercs and wannabees" is probably the subfocus of SOF that most Americans find the least tasteful of what SOF is about. Most Americans don't think highly of mercenaries. If anyone is going write something for SOF about PGP, I hope that the article focuses on anything but "mercs and wannabees". M Carling Begin forwarded message: Date: Thu, 14 Apr 1994 12:33:04 -0400 From: Duncan Frissell <frissell(a)panix.com> To: CYPHERPUNKS(a)toad.com Subject: Re: Soldier of Fortune Sender: owner-cypherpunks(a)toad.com Precedence: bulk M > M >This seems counterproductive. PGP should not be portrayed as a tool M >for those that most Americans consider antisocial. M > M >M Carling M > A quote from pgpdoc1.doc: "If privacy is outlawed, only outlaws will have privacy. Intelligence agencies have access to good cryptographic technology. So do the big arms and drug traffickers. So do defense contractors, oil companies, and other corporate giants. But ordinary people and grassroots political organizations mostly have not had access to affordable "military grade" public-key cryptographic technology. Until now." Now Phil wrote PGP in part so that "grassroots" political organizations could have strong crypto. SOF is a "grassroots political organization." It happens that some people don't like SOF. It happens that some other people think that the organizations that Phil was thinking of when he wrote PGP are unamerican communist front organizations who should be on the Attorney General's List (if we still had an Attorney General's List)(if we still had an Attorney General). Tastes differ. The point of cypherpunks is that everyone (even FBI agents) should have strong crypto if they want it. I know that Phil feels a personal sense of embarrassment at being adopted by all sorts of nut groups (including ourselves) and he has pleaded for stories of "worthy PGP use." Standards of worthiness will vary. DCF Who, as it happens, *is* a member of an organization on the Attorney General's list. --- WinQwk 2.0b#1165

2 1

uses for PGP
by Ed Carp 17 Dec '03

17 Dec '03

Here's the text of a message I sent to Phil. Thought I'd share it with y'all... ----------

1 0

cypherpunks and politics (Re: USWA)
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 2:21 AM 04/14/94 -0500, Adam Lake wrote: >Did anyone ever think of involving the USWA (no, not the United States >Wrestling Association) United We Stand America in the Clipper fight? >Sounds to me like this would be a mass appeal if it appeared in their >newsletter. This is something I have been meaning to write to the list for several weeks, and this post is the perfect lead in. When I joined this list, I saw thought it was going to be much different. I had assumed 1) that people on this list would have much different politics and 2) that that wouldn't really matter, 'cause everyone here is concerned with one issue, which we could all agree on. 2) seems to have partially true, sometimes. Without expounding at lengths, my reaction was to unsubscribe on short order when I saw some of the first posts flying around. I didn't, because I try to keep an open mind and do change opinions sometimes. But not everyone who is a potential crypto supporter is gonna bother, and by tying (seemingly or not- impressions count here) the issue to a particular set of other beliefs, there is a huge chance that others are going to be alienated. I know *I* don't want to be associated with libertarianism or (even worse) Perot... The point is that even if you think anyone with a viewpoint opposing yours is automatically stupid and not worth your time (and I don't think that too many of you are that bad off ;), aren't they at least worth using to further something you believe strongly in? It might do well to be careful in alienating potential allys by flip political jokes and comments. -j

2 1

Re: fake pgp messages
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

What about a chron task that creates a new PGP key every x hours and encrypts random Usenet posts, according to traffic patterns (if there it tons of real activity, don't do much, if little, do more. just a thought. -j

1 0

Speech compression and encryption (Secure Phone)
by danisch＠ira.uka.de 17 Dec '03

17 Dec '03

Hi folks, we want to start a project for a computer science class at the University of Karlsruhe. We want to write software to use a workstation/PC with a modem, speaker, and microphone as a secure Phone with encryption and authentication. Therefore we need speech compression. Can anyone give me hints to books, articles, algorithms or software for speech compression? Is CELP public available? Thanks a lot Hadmut

2 1

Re: Need info re Clipper/encryptions
by PAPAMICHAIL 17 Dec '03

17 Dec '03

I'm writing a script, need someone to advise me on technical points re encryption, cracking computers and other things I probably shouldn't know. If there's anyone out there that can help please contact me via CompuServe 72133,1415 P.S. I'm no computer wiz. Thanks - ERB

1 0

Re: Another reason for anonymity
by Jim Sewell - KD4CKQ 17 Dec '03

17 Dec '03

Preface: I inadvertently sent this via regular mail to Tim directly instead of on the list. He noted, correctly, that it should have been put to the list so I'm copying it there. Jim <My computer told me that Timothy C. May said:> > > (You should carry these discussions on the main list, so I can justify > putting more time into the replies.) > > > <My computer told me that Timothy C. May said:> > > > [ discussion of anonymity and defamation of character omitted since it's been posted before. - JCS] > > > > But what about the credit checking systems now or the "Data Hiway" (I'm > > growing very weary of the I.S. catchphrase) of the near future? What if > > I can type, anonymously, that Tim May is a pedophile and every newspaper, > > and thus every home, in the world sees it? Do you think you'd get a job > > as a elementary school teacher? Not likely. People always remember the > > accusation but rarely the retraction. Do you think Michael Jackson will > > ever shrug off the child molestation charges? Not fully. Even now, if > > I have a business and I tell XYZ Credit Check Company that you didn't > > pay your bill and owe me $1,000,000.00 then you're ruined! Oh, that's > > right, for me to report it I have to say who I am and then you can sue > > me for ruining your life. > > False or frivolous accusations are often made, and people take into > account the source. This is what free speech entails. Once again, though, if someone is granted anonymity then people can not take into account the source unless reputations are attached to the pseudonym, as you mention: > Look into how "reputations" work. > > As to the Michael Jackson case, people believed it because his > behavior supported the charges, there were corroborating witnesses, etc. > But we are guaranteed the right to face our accusor in legal cases which would go away with complete anonymity. > > > (What about shouting "Fire!" in a crowded theater? Let those who see > > > there's no fire beat the shit out of the twerp who shouted "Fire!" > > > Seems fair to me.) > > > > > > > Oops, tactical error, Tim. Under your statements a guy can shout "Fire!" > > anonymously so who do you "beat the shit out of" then? Neither argument > > (for or against anonymity) is water proof. > > No, if its anonymous, then it can't be punished anyway. I'm in favor > of "screenable anonymity": set your e-mail filters to ignore any > messages except from those names or pseuodonyms you place faith in. > Simple. Ok, so it is not just blind anonymity but rather one with some degree of responsibility and reputation, thus your psuedonym becomes known as a distinct entity that is not tied to you. Perhaps... > (My point about the "Fire!" example is that a rare, and solvable, > problem has been used inappropriately for decades to place legal > limits on free speech.) And a valid point it is. It seems that in 50 years we could have come up with a better example of limiting freedom than this. -- Tantalus Inc. Bringing people together Jim Sewell-KD4CKQ 2407 N. Roosevelt Blvd. to have a little fun. Internet: jims(a)mpgn.com Key West, FL 33041 CIS: 71061,1027 (305) 293-8100 "We keep coding and coding and coding..."

1 0

re:My public key
by SGT=DARREN=S.=HARLOW%ISB%MCTSSA＠nwsfallbrook3.nwac.sea06.navy.mil 17 Dec '03

17 Dec '03

Enclosed is my public key. I am new to the list and have a lot of catching up to do. Please excuse my ignorance. Sgt Darren Harlow - Computer Security MCTSSA, Camp Pendleton, USMC Internet: harlow%isb%mctssa(a)nwsfallbrook3.nwac.sea06.navy.mil Voice: Comm: (619) 725-2970 DSN (Autovon): 365-2970 Fax: Comm: (619) 725-9512 DSN (Autovon): 365-9512 "The views expressed are my own, and always will be..." -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAi2pYOoAAAEEAJ0Fdc1HDwlww3Wz8JPeQDZT2Gk/q1gh0J+4njtUC66HXngN DNyxzoGnZVcA0bbkirsCdjvvZlsP84QVgxdijzgW4pNOJKowJgrQWFftGEqJKH5b I2NxJrk0kmKt/jli5kV/wDs9Rr4PxXQjGN4B+uJOCSlyWX+fnWNyHMOkIY2tAAUR tENEYXJyZW4gSGFybG93IDxoYXJsb3claXNiJW1jdHNzYUBud3NmYWxsYnJvb2sz Lm53YWMuc2VhMDYubmF2eS5taWw+ =v34V -----END PGP PUBLIC KEY BLOCK-----

1 0

PGP encryption
by marssaxman＠aol.com 17 Dec '03

17 Dec '03

Are there any shareware/freeware/PD PGP-like encryption systems for the Macintosh? Or is there a Mac version of PGP and I just haven't heard about it? -Mars

1 0

Re: Remailer reply addresses
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

Ah! I'm glad conversation on this thread has picked up - I was afraid no-one was interested. :Graham's suggestion about automatic remailer reply chains reminded me of :a simpler system which I would like to see. :Suppose one site, somewhere, would create new mail addresses upon request, :and map them to encrypted remailer chain blocks. (These are nested remailer :requests, where the outer layer is encrypted for the first remailer and tells :it where to send the message, the next layer is encrypted for the 2nd remailer :and tells it where to send, and so on. No remailer sees anything more than :where it is sending the message and where it received it from.) A new account :is created which maps, say, to a file which has one of these "anonymous return :addresses" in it. Any mail incoming for that address simply gets sent to the :remailer in the file, with the ARA stuck in front of it. That's pretty much what I was thinking of, except you don't need the pseudonym server. I find this stuff easier to talk about with examples than in general, so here's what I'm thinking about: I mail to first remailer (R1). The remailer inserts my reply address into the mail, encrypted, and either mails it to the recipient if I gave one, or to the next remailer if I specified a remailer chain - or to another remailer at random on it's own whim if it feels like doing so. Let's assume it's going to another remailer then. This next remailer (R2) takes the header block with my reply address in it, and prepends what *it* sees as the reply address, ie remailer R1. It then encodes this into an identically-structured reply block, and inserts *that* in the mail instead of the original reply block, before passing it on. This can be repeated as often as desired - the mail will always have only two parts where-ever it turns up - an encrypted reply-block and the text. Let's say it ends up on the n'th remailer, Rn. When the real recipient gets the mail and replies to it, the reply goes to remailer Rn, and Rn can decode the header block. The decoded header block contains an address, and extra text which happens to be a fully-formatted header block itself. This extracted, smaller, header block is put back into the mail instead of the one which was just decoded, and the mail is sent back to the address that was extracted. eventually it goes through umpteen remailers, and R2 passes it back to R1. R1 decodes the header block, finds *only* the address - no nested header block, and passes the mail back to the user at that address. So the whole thing is really a trivial protocol - just <start of header block marker, for remailer to locate it> email address djhfkjsdhfdshf (opaque text from previous encryptions) kjfhkdhfkdhfkd dfkdfkjdfkhdf (possibly on multiple lines) jhldkjodkfdjfljdlfkjldjdl <end of header block marker> Sure, this could be extended to put all sorts of neat features in the encrypted area, but I rather like the simplicity of just keeping it to a plain username@site on a single line. :With this software I could do something which cannot be done today. I could :send mail to which someone could hit "r" to reply, and receive that reply, :without any one person knowing my pseudonym. This is not that much to ask :for! I'd say it is the bare minimum for the use of pseudonyms on the net, :yet we don't have it, after all this time. And look how close we are to :being able to do it. Absolutely! That's what I want too. :With this basic system in place, some of Graham's ideas about time-limited :or use-limited pseudonyms could be applied as well. Other extensions people :have suggested would have the pseudonym server hold messages in inboxes until :people trigger a dump to a freshly created anonymous address. A lot of things :are possible. I agree entirely except I don't see the need for a pseudonym server - just the normal remailer reply address should be enough (so that people who can't create aliases can run this stuff on remailers out their personal accounts) which is why I think the blinded reply addresses should be in the *body* of the mails. (Smart mail software would scan the text for these and handle stuff like indentation etc. It doesn't seem too difficult - I already use procmail for something like this where I scan for PGP blocks in mail and decrypt them on receipt where possible) :But we should walk before we run. Right now I don't feel that we are even :crawling yet. hh@soda seems to have shown us how to walk :-) G

1 0

Rejected mail
by John C. Brice 17 Dec '03

17 Dec '03

ag588 is rejecting mail from you

1 0

Re(2): Cyber PsyOps & Media
by Harry Shapiro Hawk 17 Dec '03

17 Dec '03

------ From: imsi.com!perry(a)panix.UUCP, Thu, Apr 14, 1994 ------ Jeff Davis says: > I just got off the phone with David Wilson with the Chronicle of Higher > Education. @ A really well known publication. Actually among staff and administration of colleges, schools, etc., this is a rather well know publication of much note... having the article appear there will certainly educate the the "campus" folks... but to agree with what I think was Perry's intent this not a mainstream publication. /hawk Harry Shapiro Hawk Manager of Computer Services Warwick Baker & Fiore habs(a)uucp.warwick.com

1 0

Re: New anon mailer idea?
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: Graham Toal's suggestion for automatic insertion of an encrypted : return address block is interesting. We had some discussion here last : year of a similar approach, although Graham's twist of using a symmetric : rather than PK cypher for the return address is new. A few thoughts: I'm not sure it matters; it was just to focus the mind on the point that even if a PK cypher was being used in practice, it was *in effect* a private key cypher because its security depended in part on keeping the decoding key secret within the remailer. Primarily I suggested something like DES/IDEA because RSA keys are expensive to generate, and for this scheme you definitely need one new password for every incoming mail. : - You'd want this feature to be optional. Some people might not want : their anonymity limited by having their return address recorded, even : in encrypted form. Yes, I agree. I think Eric von Hollander is doing this for *every* posting in the soda implementation he hacked up impressively quickly, and I'm not sure that's wise. (Eric will correct me if I read his docs wrongly) I've a feeling some of his customers might complain when they realise! (*I*'m not complaining - I think it's great that he added this feature so quickly) : - Graham is right about the advantages of use-once (or use-only-a-few-times) : return addresses. Chaum discusses how multiple use of return addresses : allows these systems to be broken, similar to the way Graham describes. I also hope Eric is using individually-created DES keys for every incoming post and not a single shared key. That would be a serious risk. I get the impression he's not, from his comment about the system being vulnerable to known-plaintext attacks. (Eric, if I'm right, could you change your hack to use disposable DES keys asap please?) : - The use of a symmetric cypher is a very nice way of getting the use-once : capability, along with the "burn after reading" effect of a remailer : chain which destroys itself as it goes. But it could be a considerable : burden on the remailer operator to maintain the database. One possibility : would be to fix a maximum time limit on how long the return addresses are : kept "alive" and require some real money to keep them longer. I'm not sure I agree with that. Actually I think the database management might be trivial - here's one suggestion. Let's say the invented random key is a hex string - well, we need 64 bits for a DES key, that's 16 hex digits, so lets be generous and make our random hex string 24 digits instead. We just take the first six digits as an identifying tag and use that tag as a filename to store the rest of the key. The tag is output in front of the encrypted block too, so when you come to decrypting the data, it's a straight file-open call to find the correct key. We don't have the problem here that we do with the pgp key-id's clashing, because if the key generator returns a clash, it can easily generate a second key. (If you're saying that deleting time-expired keys is onerous, well, it's just a case of mastering the unix 'find' command ;-) ) So if you're saying that finding a key will be expensive, I disagree; if you're saying that the database might get rather large, I do agree. Since these reply tokens aren't the same as well-known anonymous addresses, maybe it's sensible to insist from the start that they have a lifetime of no more than (say) a year; which can be shortened by user request on creation, but not extended. This is a plus feature in my opinion, because it avoids the problems Julf has had with lots of stale ID's needing to be purged. : - What we would really like is for the recipient to hit the "reply" button : and be able to send his mail back. It sounds like this system would still : require some cut-and-paste. We already have programs to create encrypted : remailer chain addresses fairly automatically. It would be nice to automate : this last little bit. Unfortunately, there seems to be no easy way to : make this work under Graham's scheme. No, I don't think that any cut and paste is required *at all* over the normal inclusion of the sender's mail in your reply. The remailer could grep the body of the mail for the magic tokens that delimit such a header block, and find it that way. (Allowing for indentation markers etc - not hard - the current usenet voting software does something similar) eg if you had: > : *** Remailer reply block *** > : jdhfkhdfkshfkhgkhfgkhf > : *** End remailer reply block*** in your mail, you can see it's still pretty easy for a program to extract the encoded bit... - just find the magic start token, note the stuff on the line before it, and strip similar stuff out until it finds the end token. : - It doesn't look like this would be an easy drop-in to the current remailers, : unfortunately. The syntax for how the address would be built up as it : passes through a chain of remailers is a little unclear as well. I've discussed this in a previous post. I think it's actually easy. The very first message goes out from the first remailer looking like this: (original text is the single line: username(a)real_site.com ) which encodes to: *** Remailer reply block *** jdhfkhdfkshfkhgkhfgkhf *** End remailer reply block*** which is inserted at the top of the mail. The next remailer extracts the encoded data, and prepares this text: last_remailer(a)wherever.edu jdhfkhdfkshfkhgkhfgkhf and encodes it, and sends it out in the mail in place of the original block, looking like this: *** Remailer reply block *** dfkjgahfskghfghfskhgkfhgfs kjfdskjsfdhgkjfhsgkjhf *** End remailer reply block*** (OK, slight poetic licence here - I'm using 1 1:1 cypher; in fact you'd expect the text to get bigger each time to cover the binary encoding method used) So the net effect is that the encoded text gets larger, but the mail is otherwise identical as it passes from site to site. : The idea does have a lot of promise, though, and I think it is definately : worth keeping in mind for the next generation of remailers. I might even start using them myself :-) One more point... I've been saying that the encrypted reply block is most easily thought about if *all* it contains is an email address. I think in practice you'd probably want to be able to store arbitrary remailer flags in here, like the command 'delete this DES key as soon as you've handled this reply' - this would in fact be more robust than keeping the same information in the DES key file itself, which was my original suggestion. And it would allow fairly arbitrary extension of the whole scheme. One way of implementing it that I can see is if the encrypted part of a block was a series of mail-header-like lines, eg: The cleartext would be: Reply-To: gtoal(a)an-teallach.com Initial-Usage-Limit: 5 Expire-Completely-After: 12/25/94 Decrement-Use-Count-By: 1 Random-Remailer-Hops-Left-In-M&M-Machine: 3 Previous-encrypted-Block: jhufdkjlwhfsjhgflkjfshkjfdhkjffsvjlfsjvkl lkjdhfkldshfksahfkshdgkhfgvkhdfkvbghfdkvhfdkj jhflkdsajhfkljshdfkjhsdkfljhdskhfksdhfkjdshf ljdsfhdkghlksfhglkfdjhglkjfhglkjhfgkjfh which would be wrapped and inserted in the usual way. G

1 0

Re: New anon mailer idea?
by Anonymous 17 Dec '03

17 Dec '03

> Graham Toal's suggestion for automatic insertion of an encrypted > return address block is interesting. We had some discussion here > last year of a similar approach, although Graham's twist of using > a symmetric rather than PK cypher for the return address is new. [...] This is new? I thought Matt Ghio's remailer at andrew.cmu.edu did this already!?!?

1 0

Rejected mail
by John C. Brice 17 Dec '03

17 Dec '03

ag588 is rejecting mail from you

1 0

advance info on upcoming Clipper hearings
by Stanton McCandlish 17 Dec '03

17 Dec '03

Date: April 27, in the A.M. Committee: Senate Judiciary; Law & Technology Subcommittee, Chaired by Sen. Leahy Current witness list: Whit Diffie, Steve Walker, someone from the Justice Department, NSA Director. More will follow when available. -- Stanton McCandlish * mech(a)eff.org * Electronic Frontier Found. OnlineActivist "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 14 1994

1 0

1st case of email libel won (fwd)
by Arthur Chandler 17 Dec '03

17 Dec '03

Is this indeed the first such case? ------- Forwarded Message One of the students at our law school has provided the following regarding a recent Australian case of email defamation , and I will post further information she obtains. Archie Zariski * (zariski(a)csuvax1.murdoch.edu.au) * * Senior Lecturer, School of Law * * * Murdoch University * * * Murdoch, Western Australia 6150 * * * Ph +619 360 2761 Fax +619 310 6671 * * * * * * >From _The West Australian_ : Saturday, April 2, 1994 _COMPUTER LIBEL WINS ACADEMIC $40 000_ by Margot Lang Sacked University of WA Academic David Rindos has won $40 000 in a Supreme Court action against Derby anthropologist Gil Hardwick, who defamed him in a computer bulletin distributed worldwide. Dr Rindos' lawyer, Robert Castiglione, said he did not know of another case in which damages had been awarded for defamatory language on a computer message network. "Computer users who use these worldwide bulletin-boards should be aware that they could be exposing themselves to defamation actions," he said. "It's an informal system where people say quite personal things, but making allegations of paedophilia and bullying is going too far." An elated Dr Rindos said it was the first of many defamation actions he planned, adding: "I have to clear my name." About 23 000 people worldwide, mainly academics and students, have access to the science anthropology bulletin board on which Mr Hardwick's message appeared. Dr Rindos, who has a doctorate from Cornell University in the United States, became the centre of an international controversy after he was sacked from UWA last June. The University dismissed him on the ground of insufficient productivity. Protests poured in from academics at international archaeological institutions, many of who [sic] described Dr Rindos as eminent in his field. US anthropologist Hugh Jarvis put his protest in a message on the computer network. Three days later an answering message appeared from Mr Hardwick. Justice David Ipp said it contained the imputation that Dr Rindos's professional career and reputation had not been based on appropriate academic research "but on his ability to berate and bully all and sundry." He said that the message also suggested that Dr Rindos had engaged in sexual misconduct with a local boy. The inference was that these matters had some bearing on his dismissal from the university. "I accept that the defamation caused serious harm to Dr Rindos's personal and professional reputation," Justice Ipp said. "I am satisfied that the publication of these remarks will make it more difficult for him to obtain appropriate employment. "He suffered a great deal of personal hurt. The damages award must compensate him for all these matters and vindicate his reputation to the public." Mr Hardwick did not defend his action. He wrote to Dr Rindos's lawyer: "Let this matter be expedited and done with ... I can do nothing to prevent it, lacking any resources whatsoever to defend myself." ------- End of Forwarded Message

1 0

Re: cypherpunks and politics (Re: USWA)
by jamiel＠sybase.com 17 Dec '03

17 Dec '03

At 11:37 AM 04/14/94 -0700, Timothy C. May wrote: >Jamie Lawrence wrote: >The list is what people make of it. Nothing more and nothing less. If >you have held off on writing 'til now about topics that are of great >interest to you, then why are you surprised that the topics others >write about don't match your interests? First off, don't dismiss me as a whiner. I personally could care less about your personal politics until they overlap with crypto. But you misread my post consistently. Perhaps I did poorly at expressing myself. I haven't been writing due to time constraints. It is not *my* political interests being underrepresented here that I was rambling about. It was the potential loss of other people. Extreme example- If you started to read a book called _Crypto for the Masses_ by someone who rambled on for 400 pages about socialism, and then got to the point and made really valid, cutting observations about the state of crypto, what are the odds you'd read to that section? >Nobody's asking you to be "associated with libertarianism," for >example. That many of us are libertarian-oriented is hardly >surprising, this being the Net. And the nonlibertarians are welcome, >but they seldom make persuasive arguments contradiciting the lib. >views, in my opinion. Certain non-lib (though *I* call him >libertarian!) folks like Dave Mandl are very welcome here, and make >their views known. What I was trying to say was not that I feel torn between being on this list and my own views, but that disregarding what anyone here may or may not believe in, first impressions are gonna chase a lot of people away who otherwise could be sympathetic to many beliefs that seem to be held as important. >> The point is that even if you think anyone with a viewpoint >> opposing yours is automatically stupid and not worth your time >> (and I don't think that too many of you are that bad off ;), >> aren't they at least worth using to further something you >> believe strongly in? It might do well to be careful in >> alienating potential allys by flip political jokes and >> comments. >I don't know if this is a jab at me or not, perhaps for my sin of >poking fun at Ross Perot.....I felt a satirical, but probably close to >the truth, point about Perot's authoritarian streak would make my >point better than a simple statement of my views. I wasn't replying to you so much as using this thread as a jump point for (!!) a new topic, specifically that of perceptions of others Re: this list. No, it wasn't a jab at you (I think Perot is scary as well)- sorry if my comments lent themselves to this interpretation. I do think, however, it would be valid to say that a Perot supporter should be considered a potential ally- as much as a libertarian or even a Clinton supporter. >If you want your brand of politics discussed here, as it relates to >cryptography, privacy, Clipper, etc., then *discuss* it. You can't >blame others for making their own comments. That was not my point. I do not blame others for anything. The goal was to inform others of the perceptions of a relative newcomer to the list who differs significantly in opinion on numerous points in relation to a attracting newcomers to the wonderful world of crypto. If I thought this list didn't interest me, I wouldn't be on it. >--Tim May -j

1 0

[hughes@hughes.network.com: Encrypting tunnel negotiation protocol]
by Eric Blossom 17 Dec '03

17 Dec '03

This came across the ipsec list. Apologies to those who have already seen it. Eric Blossom ---------------------------------------------------------------- Return-Path: <ipsec-request(a)ans.net> From: hughes(a)hughes.network.com (James P. Hughes) Date: Thu, 14 Apr 1994 12:51:56 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: ipsec(a)ans.net Subject: Encrypting tunnel negotiation protocol Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 This is a discussion that I promised to start at the last IETF. This is a long email, so I will ask for any comments here at the start. Thanks jim ------------------- Introduction. This note is to start a discussion regarding key negotiation for encrypting tunnels. There are several specific attacks and authentication capabilities that will be addressed. The tunnel establishment protocol must negotiate several parameters and well as reliably negotiate a session key. A 2 message authentication/session key negotiation was chosen because of the complexities of multiple messages. Authentication will be accomplished with RSA. Getting certified public keys will be beyond this document. It is expected that they will be distributed via "secure sneaker-net", via secure DNS or X.509 certification services. An example of a secure sneaker-net is where the public keys are gathered together on a disk and then distributed to potential partners. During this phase the disk mst be guarded to ensure that "Mallet" can get at the disk and replace the keys. After the keys are loaded into the partners, they must be protected form unauthorized external writes and/or erasures. Attacks addressed will be "denial of service because of message playback", "man in the middle", and "rubber hose" attacks. Denial of service It is expected that processing tunnel establishment messages will be an processor expensive task, and this protocol is intended to minimize the processing required to determine if a tunnel establishment packet is not an old packet or a malicious packet created to "clog up" the tunnel establishment task. If the tunnel is established, a tunnel request will be ignored unless the request has the proper identifier. If there is an active tunnel, then there will be an active tunnel negotiation request identifier. A malicious user can not interrupt an exiting tunnel without this "once". Once a request is received, that request identifier is (probably) not used again. When a tunnel is not established, there is not an existing tunnel negotiation request identifier, and a malicious user can create a packet that passes the initial checks. All a malicious user can cause is a one block of RSA decryption, one block of RSA encryption and a MD5 calculation. This vulnerability can be limited by queueing only the oldest packet per requestor IP address if the tunnel renegotiation task is busy. If the malicious user sends in old packets, the increasing time of day check will be enough to catch them. if the user modifies the time of day, then the RSA and MD5 checks will catch that. In either case, the malicious user can not interrupt existing tunnels and if the tunnel request processing is a background, low priority task, throughput will not be adversely effected. Other attacks. Man in the middle is addressed with (unspecified) trusted public key distribution mechanism. Rubber hose attack is where the private key is extracted through (possible painful means) and all previous messages passed can then be decrypted. The more common method of using this would be to "steal" the host or router and then use in circuit emulators or the like to extract the public key. After an attack like this the key would be compromised and never used again. What this is trying to protect is all previous messages passed before the rubber hose is applied even if the private key is compromised. The key establishment protocol The protocol is comprised of two messages. Requestor Responder Tunnel Request -----------------------------> <---------------------------------- Tunnel Reply If there is not a reply from the first packet, the source will resend the packet with a new time of day (and recomputed MD5). Sending traffic on the new tunnel or sending a Tunnel alive message will complete the negotiating. Tunnel keep alive messages are sent and acknowledged at a predetermined regular basis. Both sides send the requests and both sides send the Ackd. These messages are passed within the tunnel and are encrypted by that process. The format of the tunnel alive messages are in the tunnel document. The contents of the tunnel request is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Requestor IP address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Responder IP address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Request Identifier | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Time of Day (2 words) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Diffie-Hellman modulus Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | g (16 through 64 words) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MD5 | Modulus (16 through 64 words) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Diffie-Hellman (X=g^x mod n) (16 through 64 words) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | Reply identifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Tunnel request and parameters (TBD) (? words) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Tunnel Lifetime | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + RSA | MD5 residue (2 words) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (Random data) (? words) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + "Request Identifier" is the value from the last tunnel negotiation that identifies this packet as the correct tunnel renegotiation packet. If there is not a current tunnel in effect then this is 0. "Time of day" is the unix format time of day, that is, the high word contains the number of seconds since January 1, 1970 GMT, and the second word contains the number of microseconds elapsed during the current second. The clock needs to be monotonically increasing, but does not need to be synchronized. The microseconds can be an increment. "Tunnel request parameter" contains information which is used in the negotiation of the tunnel. This includes tunnel ID (SAID), encryption type(s), compression type(s). Details TBD. "Reply identifier" is the value expected in the reply. This is a random number. "Tunnel Lifetime" is the expected time for the tunnel to live. This value, added to the local time of day creates both the expected time of day to be used in the next request as well as allowing the Responder to calculate the time after which it is to expect that negotiation to occur. Tunnel renegotiation can occur sooner if the tunnel keep alive messages show that the tunnel has collapsed. "Random Padding" is used to pad out the block to the RSA modulus. RSA is used to double encrypt this with the requestors private key and the responders public key. The double protection will obscure from any potential eavesdroppers the exact encryption methods, compression options as well as renegotiation times and reply identifier. The Diffie Hellman modulus length (in bytes) is then followed by the 3 values, g, n, and (g^x)mod n. (x is the secret value to be used to calculate the key later.) The length can be from 512 to 2k bits. When the packet is received the following steps are performed. 1. The IP address, request ID are validated to ensure that the packet is from the correct requestor. If the requestor id is 0, and the tunnel is still operational (as of last tunnel alive request), then toss the packet. (The requestor id should be 0 only if the tunnel is not operational.) If the request is 0 and the tunnel is not operational, the time of day is checked to ensure it is increasing. 3. The RSA protected data is decrypted by the responders private key and then encrypted by the requesters public key. 2. MD5 hash of the entire packet is calculated and determined to be correct. The originator and this packet has been authenticated. 5. The time of day is saved as being correct. 7. Create the random number y and calculate the value X^y mod n. A number of these bits are used as the session key. The responder then creates a reply packet. Once the packet is sent, the responder should be ready to accept packets using the new SAID. (Packets using the existing SAID can continue to be sent.) The reply should be resent after time-out until a packet is received on the tunnel. The responder can not use the SAID until a packet is received on the tunnel. The contents of the tunnel reply is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Requestor IP address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Responder IP address | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Reply identifier | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Time if Day (2 words) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Diffie-Hellman modulus Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MD5 | Diffie-Hellman (Y=g^y mod n) (16 through 64 words) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | Next Request identifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Tunnel request and parameters (TBD) (? words) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSA | Tunnel Lifetime | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | MD5 residue (2 words) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (Random data) (? words) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Where "Time of day" is the time received in the request. (Actually, this is not used, but it is easier to leave the space there.) "Tunnel request parameter" contains results of the negotiation. This includes tunnel ID, encryption type(s), compression type(s). Details TBD. "Fixed Pattern" A value to ensure that the RSA decryption was successful. "Tunnel Lifetime" is the value received in the request or smaller. "Random Padding" is used to pad out the block to the RSA modulus. RSA is used to double encrypt this with the responders private key and the requestors public key. The Diffie Hellman modulus length (in bytes) is then followed by the (g^y)mod n. (y is the secret value.) When the packet is received the following steps are performed. 1. The source, destination and time are validated to be correct. 2. MD5 is calculated over the packet. 3. The RSA protected data is decrypted by the requestors private key and then encrypted by the responders private key. 4. The fixed pattern is checked. The packet has now been validated. 5. Verify MD5(2) is correct. 5. Calculate the value Y^x mod n. A number of these bits are used as the session key. The new SAID can now be used. -- jim

1 0

Little known facts about the infohigh....
by Ophir Ronen 17 Dec '03

17 Dec '03

Greetings all, This was forwarded to me from rec.video.sat. Does anyone know any concrete details about the CC decoders installed in televisions? -Ophir | ------------------------------------------------------- | | > ... Here is some | > important information about the use of televisions. | > | > In an effort to gain access to the homes of millions of Americans, | > the FBI, CIA, and NSA have collaborated on a scheme which will | > finally bring to fruition George Orwell's nightmare scenario. | > | > American citizens will be the unwitting accomplices in this plan | > as they purchase new televisions and bring them into their | > livingrooms and *bedrooms*. I'm speaking of the CC decoders that | > have secretly been mandated by law. These decoders supposedly | > provide captions to TV shows for the hearing impaired, but in | > fact they are also rebroadcasters which will allow the gov. | > to spy on anyone they want. | > | > The television already comes with everything necessary to be | > a spying apparatus. Speakers are essentially no different than | > microphones and therefore can be used to pick up sounds in the | > room. The infrared eye which detects the remote control | > signal also receives an infrared picture of the room, especially | > detecting heat sources like people. Thus, all that is needed is | > a way of gathering this information and relaying it to the government. | > The little understood "Decoder" is the solution. | > | > The congress has recently passed a Law (in virtual secrecy) | > that requires all new TV's to have the "Decoder." This is | > claimed to be for the benefit of deaf people but that is | > obviously a smoke screen. | > | > How we know the congressional law mandating the "Decoder" is not | > for the deaf: | > 1) Legitimate CC decoders are already available for TV's. | > 2) The law doesn't cover other things, like telephones, | > which are obviously in the same situation w.r.t. the deaf. | > 3) There is no law requiring that shows even be broadcast with | > closed captions, only that the TV have the "Decoder". | > | > Clearly we see that there is no real justification for mandating | > decoders other than for gathering intelligence. | > | > How to deal with the decoder: simply removing the decoder will not | > be an option because it will undoubtedly be integrated in such a way | > that the television will not function without it. Also, if you open | > the TV to get at it, you will void the warrenty and then when you | > get it fixed, they will just replace the "Decoder" without telling. | > | > The best way to avoid the "Decoder" is to avoid it by not buying any | > new TV's. This will be made difficult by the predictable introduc- | > tion of High Definition Television soon after the "Decoders" are | > on line. In this way you will be forced to buy a new TV because the | > old one will not get HDTV. When HDTV is made a standard by the govern- | > ment, the old style sugnal will not be allowed to be broadcast on the | > grounds that it interferes with the HDTV. This is all to force people | > to buy new TV's with the "Decoder". | > | > When you find yourself with a TV equipped with the "Decoder" there | > are several things you can do to protect yourself. First, don't | > put the TV in your bedroom, this is where the government is most | > interested in spying. When not watching, push the antennas all the | > way in or disconnected the cable. Unplugging the TV will not help | > because the "Decoder" will use passive broadcasting to continue | > sending its signal. Also turn the volume down when not watching. | > When you watch the TV, place a candle or other heat source to confuse | > the infrared EYE. Don't say anything secret or get undressed near | > the TV. Don't be seen smoking near the TV. | > | | ________________________________________________________ Ophir Ronen <a-ophirr(a)microsoft.com> (Myself != Microsoft) E67065:66 57 94 27 D9 70 C5 B4 95 31 F6 41 FD 5C EB 1A

2 1