December 2003 - cypherpunks-legacy

Scientology subpoenas operator of "freezone" anon remailer
by modemac＠netcom.com 17 Dec '03

17 Dec '03

Path: netcom.com!ixnews1.ix.netcom.com!howland.reston.ans.net!swrinde!newsfeed.internetmci.com!cdc2.cdc.net!news.texas.net!nntp.primenet.com!news.cais.net!bofh.dot!news.his.com!news.lightlink.com!light.lightlink.com!homer From: "Homer W. Smith" <homer(a)light.lightlink.com> Newsgroups: alt.religion.scientology,alt.religion.scientology.xenu,comp.org.eff.talk,misc.legal Subject: Body of Subpoena (fwd) Date: Wed, 29 May 1996 15:12:09 -0400 Organization: ART MATRIX - LIGHTLINK Lines: 28 Distribution: inet Message-ID: <Pine.SUN.3.91.960529151032.12441B-100000(a)light.lightlink.com> NNTP-Posting-Host: light.lightlink.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: Multiple recipients of list IAP <IAP(a)VMA.CC.ND.EDU>, Remailer Operators List <Remailer-Operators(a)c2.org> Xref: netcom.com alt.religion.scientology:185032 comp.org.eff.talk:85083 misc.legal:174678 DOCUMENTS AND THINGS TO BE PRODUCED 1.) All documents relating to the posting, the header of which is attached hereto as Exhibit A, which was made through the anonymous remailer, freezone.remailer, including, without limitation, the identity of the person or persons who made the posting. 2.) All documents relating to logs or other records kept by the computer of any individuals who sent messages through freezone.remailer at the time the Exhibit A posting was made. 3.) All documents relating to how records are kept by the freezone.remailer computer of the source of postings made or messages send through the computer. Exhibit A is the header as received by netcom.com of Scamizdat #3, posted on April 1st 1995. Homer ------------------------------------------------------------------------------ Homer Wilson Smith News, Web, Telnet Art Matrix - Lightlink (607) 277-0959 SunOS 4.1.4 Sparc 20 Internet Access, Ithaca NY homer(a)lightlink.com info(a)lightlink.com http://www.lightlink.com -- Reverend Modemac (modemac(a)netcom.com) First Online Church of "Bob" "There is no black and white." PGP Key Fingerprint: 47 90 41 70 B4 5B 06 90 7B 38 4E 11 8A ED 80 DF URL: http://www.tiac.net/users/modemac/ (FINGER modemac(a)netcom.com for a FREE SubGenius Pamphlet!)

1 0

Re: Ok, what about PGP (was: MD5 collisions)
by wlkngowl＠unix.asb.com 17 Dec '03

17 Dec '03

I poked around the pgp.h and pgformat.txt files in the PGP 2.6.2 distribution. There *are* designator bytes for the hash (and cipher) algorithms, hash size, etc. It seems quite doable to add support for SHA-1 signatures (and possibly key generation for encrypting secret keys?). Adding 3DES (and maybe Luby-Rackoff-SHA, assuming it hasn't been cracked recently at the Fast Software Conf.... more info?!?) would be nifty too... unless, of course, there's meaning to the Real Soon Now that PGP3 folx claim. I d work on the hack now (and just might...) but I'm stuck stranded in the United States. :( Rob.

2 1

Re: TIC_hip
by jim bell 17 Dec '03

17 Dec '03

At 03:46 PM 5/29/96 GMT, John Young wrote: > 5-29-96. FiTi: > > Chips Galore [Editorial] > Texas Instruments' claim to have developed a technology > capable of inscribing 125m transistors, or computing > elements, on a thumbnail-sized slice of silicon is > remarkable chiefly because the technique is commonplace. Having been following the progress of IC technology for over 20 years, I can recall when 1 million transistors/chip was the furthest-out prediction "they" were willing to make. Jim Bell jimbell(a)pacifier.com

1 0

Re: An alternative to remailer shutdowns
by Bill Stewart 17 Dec '03

17 Dec '03

>>>Remailers on the attack points (first in chain, last in chain) simply MUST >>>be disposable as tissue. They must be run as anonymously as possible, .... >> Why the first in chain? If the anti-traffic-analysis provisions are >>working properly, it should be impossible to prove that a given first remailer >>was the first remailer for any particular message. [....] entrapment >Likewise, I don't see why the first address in the chain is vulnerable, as >long as the message subsequently passes through at least one trustworthy >remailer, and probably a temporary output address. There are two major problems, which have different impacts - protecting the users from corrupt remailers, and - protecting the remailers from spamming or entrapping users To protect users from corrupt remailers, you not only have to pass through at least one trustworthy remailer, you have to encrypt the message for each remailer in the chain so that any corrupt remailers can't read it at least until it's been through the trustworthy remailer. Protecting remailers from users depends on the threat. If the government wanted to claim that all the remailers were part of a Conspiracy to Distribute Laundered Narcoterrorist Tax Evasion Paraphrenalia, first-in-chain remailers become vulnerable, since the Postal Inspectors can send entrapment material to them and document where it comes out, though the path between first and egress can't always be documented, depending on how the remailers handle mail. On the other hand, if the Church of Spam tries to frame remailers by posting their own Secret Documents, they can only target the terminal remailers and as far back as they can subpoena, because they'd otherwise have to admit that they posted it. There's been some discussion of delivering outgoing mail by sending it through systems that don't add Received: headers; it may make sense for non-root-owned remailers to do this using telnet to port 25 instead of their local sendmail, to prevent local logging and prevent their sendmail from adding its own information. Some sendmails try to detect forgery, but systems that aren't even configured to do Receive: probably don't. Bill # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 # goodtimes signature virus innoculation

1 0

Re: [crypto] crypto-protocols for trading card games
by David F. Ogren 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > On Wed, 29 May 1996, Simon Spero wrote: > > > Design a set of crypto protocols to support the issuing, trading, > > and playing of such card games in real time (100ms compute time > > per move) > > I'd been thinking about it from the opposite point of view: make up > a card game (possibly electronic, like what you're proposing) that > acts as intro to crypto for the untamed hordes of game players. > I've had similar ideas, but there are snags. Card playing via encryption techniques is a great idea in theory, but in reality the technical requirements often prevent implementation. Think of the requirements of this system: 1. Cards must be transferrable. 2. Cards must not be duplicated by anyone other than the game company. 3. Cards must be able to be randomly shuffled. (Since most trading card games are two-player games our task is simplified greatly.) Here is one possible algorithm, and some of its weaknesses. The game company generates a master public key pair with which it will sign all game cards. Each player generates a public key pair to verify his identity. Each card is composed of the following fields: A serial number, so that each card is unique. A public key generated by that the owner as a proof of indentity. (Each card owned by a player will have the same public key.) The name of the card and (optionally) a desception of its effects. Each card is then signed using the game company's secret key. For each game both partners generate a public key pair. Alice then signs each card in her deck with the public key she generated for this game and then transmits the cards (in a random order) to Bob. Bob does the same thing for his deck. Each time Alice needs a card, Bob selects one of Alice's encrypted cards and Alice decrypts it. As an additional measure to determine that Bob's cards are genuine, Alice sends Bob a random string and asks that he sign it with the secret key that matches the indentity-verifying public key on his cards. If Bob can return a signed version of that string, the ownership of his cards is verified. This indentity verifying routine can be conducted as soon as Bob's first card is revealed. Bob of course, conducts the same procedure for Alice after she plays her first card. After the game is over (or Alice's deck needs to be reshuffled), she reveals her secret key and Bob verifies that her cards are genuine and that she played fairly. Advantages: This system prevents anyone other than the game company from duplicating cards (each card has a unique serial number), and from copying other people's cards (each card has an indentifying public key). Any cheating can be discovered at the end of the game. Bob knows the order in which he selected Alice's encrypted cards. After the game, when Alice hands over her game-session secret key, he can check to make sure that Alice revealed her cards in the order he selected them. Only a reasonably amount of encryption/decryption is required. Most importantly only one key per player needs to be generated for each shuffle. During play only decryption is required. In other words, a modicum of set up is required, but once play begins the decryption shouldn't slow the program down appreciably. Disadvantages: The entire integrity of the system relies on the security of the game company's key pair. If the secret key is comprimised, either by a disloyal employee or by crytographic techniques, all cards in existence must be recreated. Cards are not transferrable. In order to make cards transferrable the game company must be able to invalidate cards which have been traded to others. In other words if Alice wants to give a cards to Bob she must: 1. Contact the game company and tell them she wants to give the card to Bob. 2. The game company must issue a new card to Bob with a new serial number and with Bob's public key rather than Alice's. 3. The game company must invalidate Alice's old card. Since there is no way that the game company can make sure all copies of the card have been destroyed it must create a "invalid serial number list" and have the players dial into that list everytime the game is played. Since step 3 is so costly to implement, I think it is unlikely that a cryptography-based trading card game will have tradable cards. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMay5ZvBB6nnGJuMRAQHYFAQAl/PwCB0U/rQfjNgdoeLNpo9TyPAdebhT FWjE44zjTmr6Cbl6S5D9QsqLub6eDI5DsXhD+w4Tipjn9/GZwQtFpEORx9MeAUWh 9TCtcDY4Tn5d8aNwtVikHt971uW6ROU7qWikIDipxotWtTscl8NESZbgmZqGOBWW 4VzGRMuIr1E= =bXqs -----END PGP SIGNATURE----- -- David F. Ogren ogren(a)concentric.net (alternate address: dfogren(a)msn.com) PGP Key ID: 0xC626E311 PGP Key Fingerprint: 24 23 CD 15 BF 8D D1 DE 81 71 84 C8 2C E0 4B 01 (public key available via server or by sending a message to ogren(a)concentric.net with a subject of GETPGPKEY)

1 0

Broken Nymserver
by John A. Perry 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hello Everyone, It turns out that the nym server at nymrod(a)nym.jpunix.com was slightly broken. My tests indicate that it is fully functional now. I apologize for the inconvenience. John Perry - KG5RG - 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. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMayhBlOTpEThrthvAQH3NwP/fF8SMTlV+LkaeyTz0YrWcY3wfeNaTkV/ u5JATy0yRgW/U/l6KsxI5mc2onVD5em2+srlvqb9JkLcQ8PTQWRSULwRpFO8rDvI fEic0UBdObt8QpacbNUgWJeNfXzbgYfv6Po72fci3aWWBc6RLuLC/uAnYv4VaNej IPyui2isWT0= =PCKi -----END PGP SIGNATURE-----

1 0

forged addresses
by nobody＠nowher.com 17 Dec '03

17 Dec '03

Hi, I'm not sure if there was ever a thread on this, but I was wondering if anyone can determine your real email address, if you were to fake it to your email client. I hope that this doesn't offend anyone, since this is a high traffic list, but I was wondering if this would work. To try it out, I setup my client to think I was someone else, and sent myself an email. I could only figure out what ISP it came from. What I would like to know is, can any of the experts on this list determine my address from the header of this post?? again, if this is something that I shouldn't have done, just let me know, and it won't happen again.

2 1

Where does your data want to go today?
by Marshall Clow 17 Dec '03

17 Dec '03

>From <http://www.pcweek.com/news/0527/27stor.html>: >Helping pave the way toward cost-effective disaster recovery >systems, MCI Communications Corp. this week will join a growing >number of providers offering file backup and storage over the >Internet. [snip] >MCI and Connected house data on servers at two mirrored sites. >Both companies are adding an extra dimension of security over the >Internet by encrypting data. > >MCI's networkMCI Backup software, for Windows 95 or 3.x, will >scan a file for viruses, encrypt it using an RSA Data Security Inc. >public key and compress it before it is uploaded onto MCI's Internet >backbone network to a secure storage facility, said MCI officials in >Atlanta. [snip] Some comments (off the top of my head): * What kind of encryption? [The article says RSA. ] How big is the key? * Why encrypt before compression? If the encryption is any good, then the encrypted data won't compress much at all. However, compression before encryption has its own problems. * Who does the key management (if any)? * Does MCI store copies of the keys used? * How does MCI authenticate users who request copies of files, and do they then return them encrypted or as plaintext? If encrypted, how does the recepient decryt the files? (He/she just had a disk crash, and this is their backup medium, remember?) I looked on MCI's web site <http://www.mci.com>, but couldn't find anything. Besides, it's slower than sludge. [ 90 secs/page over my 128K link. :-( ] -- Marshall Marshall Clow Aladdin Systems <mailto:mclow@mailhost2.csusm.edu> "We don't have to take it; never have, never will. Gonna shake it, gonna break it; let's forget it: better still" --The Who, "Tommy"

1 0

Update on CDA and copyright (5/29/96)
by Declan McCullagh 17 Dec '03

17 Dec '03

ON THE CDA: Folks involved in the case expect a decision within the next week from the Philadelphia three-judge panel hearing our challenge to the CDA. The DoJ has a few weeks to appeal to the Supreme Court if they lose. -------------------------------------------------------------------------- ON COPYRIGHT: Regarding the online copyright legislation, there's plenty of action on the Hill -- and contrary to what I thought a week ago, there's even a fighting chance that this bill will pass this year. So far, full Senate judiciary and the House judiciary intellectual property subcommittee have held hearings. The House has taken the lead here, and the tentative date for the subcommittee markup of HR2441 is June 5. (It was to have been last week, but was cancelled at the last minute when no agreement was reached.) The Senate seems to be waiting to see what the House does before making any sudden moves. General feeling is that the legislation was on a fast schedule but has been slowed down considerably because of ongoing controvery over OSP liability and (especially) section 1201. The big snarl is over 1201, and some alliances of convenience are breaking down. More to the point, libraries are finally mobilizing grassroots opposition. Brock has a piece about this in a recent Muckraker on HotWired. (I'm hundreds of messages behind on cypherpunks so if you reply to this please copy me.) -Declan

1 0

Re: Where does your data want to go today?
by droelke＠rdxsunhost.aud.alcatel.com 17 Dec '03

17 Dec '03

> > >From <http://www.pcweek.com/news/0527/27stor.html>: > > >Helping pave the way toward cost-effective disaster recovery > >systems, MCI Communications Corp. this week will join a growing > >number of providers offering file backup and storage over the > >Internet. > [snip] > > >MCI and Connected house data on servers at two mirrored sites. > >Both companies are adding an extra dimension of security over the > >Internet by encrypting data. > > > >MCI's networkMCI Backup software, for Windows 95 or 3.x, will > >scan a file for viruses, encrypt it using an RSA Data Security Inc. > >public key and compress it before it is uploaded onto MCI's Internet > >backbone network to a secure storage facility, said MCI officials in > >Atlanta. > [snip] > > > Some comments (off the top of my head): > > * What kind of encryption? [The article says RSA. ] How big is the key? Web page, and sign-up email doesn't say... > * Why encrypt before compression? If the encryption is any good, then the > encrypted data won't compress much at all. However, compression before > encryption has its own problems. This is just confusing wording I am sure - marketing/press-release people rarely get the details right. I would guess, that in order it is scanned, compressed, and then encrypted. Nothing else makes sense. > * Who does the key management (if any)? > * Does MCI store copies of the keys used? > * How does MCI authenticate users who request copies of files, and do they > then return them encrypted or as plaintext? If encrypted, how does the > recepient decryt the files? (He/she just had a disk crash, and this is > their backup medium, remember?) These are all good questions.... > I looked on MCI's web site <http://www.mci.com>, but couldn't find > anything. Besides, it's slower than sludge. [ 90 secs/page over my 128K > link. :-( ] http://www.mci.com/productview/framelements/backupindex.shtml (probably need netscape2 for this.) I requested to be a beta-test member and got confirmation email. I guess I'll wait until they contact me "early this summer" and see what their software does.... Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

1 0