December 2003 - cypherpunks-legacy

Re: [crypto] crypto-protocols for trading card games
by Joseph M. Reagle Jr. 17 Dec '03

17 Dec '03

At 12:15 AM 5/29/96 -0400, you 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) Well, not quite the same thing, but the cool stored-value cards in Japan (for things like phones and the like) are very collectible. Everyone wants a Armitage (anime) card! _______________________ Regards, If it weren't for the last minute, nothing would ever get done. Joseph Reagle http://farnsworth.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

What is the strength of the MPJ/Diamond algorithm (Michael Paul Johnson 1989)
by Jean-Paul Kroepfli 17 Dec '03

17 Dec '03

I have seen the Diamond2 algorithm in the dlock2 package, with its predecessors MPJ, MPJ2. This a thesis by Michael Paul Johnson for is Master of Science degree (1989), and a free softwar (date: 12/21/1995). Schneier's Applied Cryptography doesn't say anything about MPJ or Diamond. What is its strength? Jean-Paul Kroepfli ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Jean-Paul et Micheline Kroepfli (our son: Nicolas and daughter: Celine) eMail: JeanPaul.Kroepfli(a)utopia.fnet.fr Also Compuserve and MSNetwork Phone: +33 81 55 52 59 (F) PostMail: F-25640 Breconchaux (France) or: +41 21 843 27 36 (CH) or: CP 138, CH-1337 Vallorbe Fax: +33 81 55 52 62 (Switzerland) Zephyr(r) : InterNet Communication and Commerce, Security and Cryptography consulting PGP Fingerprint : 19 FB 67 EA 20 70 53 89 AF B2 5C 7F 02 1F CA 8F "The InterNet is the most open standard since air for breathing"

2 1

Science on Schrodinger's Cat
by jya＠pipeline.com 17 Dec '03

17 Dec '03

We've filed at our Web site two May 24 Science articles on the NIST team's research on quantum superposition, reported by the NYT yesterday (keyed ONE_two): A Research News article on the research by Gary Taubes, "Schizophrenic Atom Doubles As Schrodinger's Cat -- or Kitten." And, the Research Article: "A 'Schrodinger's Cat' Superposition State of an Atom." C. Monroe, D. M. Meekhof, B. E. King, D. J. Wineland. Due to the heavy use of equations and figures, the material is imaged in JPEG (compressed) format -- 150 resolution and enlarged a bit for readability, so the files are fairly large: The news article: http://pwp.usa.pipeline.com/~jya/scat0.jpg (234 kb) The research article: http://pwp.usa.pipeline.com/~jya/scat1.jpg (153 kb) http://pwp.usa.pipeline.com/~jya/scat2.jpg (223 kb) http://pwp.usa.pipeline.com/~jya/scat3.jpg (224 kb) http://pwp.usa.pipeline.com/~jya/scat4.jpg (248 kb) http://pwp.usa.pipeline.com/~jya/scat5.jpg (200 kb) http://pwp.usa.pipeline.com/~jya/scat6.jpg (179 kb) http://pwp.usa.pipeline.com/~jya/scat7.jpg (210 kb) http://pwp.usa.pipeline.com/~jya/scat8.jpg (245 kb) http://pwp.usa.pipeline.com/~jya/scat9.jpg (35 kb)

1 0

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: 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

INteresting tidbit
by JOlson 17 Dec '03

17 Dec '03

The following text is an e-mail I picked up from a firewall listserver. Return-Path: <jolson3(a)netbox.com> Date: Tue, 28 May 1996 10:03:11 -0700 X-Sender: bstout(a)osc.hidata.com To: Firewalls(a)GreatCircle.COM, Return requested <firewalls(a)GreatCircle.COM> From: Bill Stout <bill.stout(a)hidata.com> Subject: Re: Encryption Technology Sender: firewalls-owner(a)GreatCircle.COM Real-To: Bill Stout <bill.stout(a)hidata.com> At 09:05 PM 5/22/96 -0700, Michael Dillon wrote: >... >RTFM ><SNIP - Other literary content deleted> On the Encryption note, and I swear not along the lines of the 'DOJ' and 'FBI Snooping' Big-Brother events, I heard another story recently. # begin story A person working on the MBONE project did an unannounced experiment across the internet using Triple-DES for MBONE, and the very next day, 'ATF' agents knocked on his door and warned him against exporting munitions. The experimentor was shaken by the fact that agents approached him so quickly after the experiment. # end story Extrapolations of fact: 1. Internet traffic is monitored. 2. The ability to snoop for encrypted traffic is present 3. The ability to identify encryption levels is present (How else can they differentiate DES-1 from DES-3?) 4. The ability to crack DES-1 in near real-time mode is present. (See above). 5. If above=true, then Feds dropping the Zimmerman PGP case probably also points to it also being crackable in a similar manner. 6. Using encryption only flags traffic for capture and decryption, using strong encryption makes you all that more interesting. Sorry, couldn't resist. I'll try not to start a threads about electro-plasma propulsion craft at Area 51, metallic-ceramic skin and pulse-jets on the Aurora spy plane, heat-imaging video cameras on satellites and planes that can watch you through your houses' roof, etc. :) Bill

3 2

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

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