December 2003 - cypherpunks-legacy

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

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In my earlier message I said: > > 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: <snip> Gary Howland said: > This is the double spending problem. > Me again: > > Since step 3 is so costly to implement, I think it is unlikely > > that a cryptography-based trading card game will have tradable > > cards. > Mr. Howland again: > Given that untraceability of cards is less of an issue than with > e-cash, why not have a central registry of the owners of the cards > (which would consist of the card hashes paired with the public key > fingerprint)? Admittedly this means the players must be on line, > but then we all know how difficult off line detection of double > spenders is. > And herein lies the problem with an implementation of trading card games. In order to detect "double spenders", the system must be on-line. However, I believe going on-line will drive the costs of running such a game out of the range of commercial feasibility. First of all, it requires that all players have Internet access. This reduces marketability. Secondly, it requires that both players make an Internet connection with the game company everytime they want to play a game. This will incur costs to the game company that it invariably will want to pass on to the players. Players, however, will be very resistant to a game that requires a subscription fee as well as costs for purchasing "cards". Especially, if becomes known that the only reason for the game requiring on-line access is to prevent "cheaters". It also raises the question of whether the game program could be "hacked" to avoid checking for authenticity of cards. I think that a more realistic solution to the "double spending" problem is to not allow the transfer of cards between players. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMa6cjPBB6nnGJuMRAQGr3wP+K+DXJVM0rX0F6FSqwfTE/YCJbfiJXC7g dAlwBA1URYA96h4su6xRThD2SbL0vJSLhvi3djQiTeshdqgmD8MTzlDsqTDLPp+f Sw0GN7OjHWlt8VO5UOK9686L7u2Ev49EdGqkaR2NOy5qNdj079v0JydRCg3qhvmT 7LqcXhRbH7g= =h3Eq -----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

opinions on book "The Truth Machine"
by A.Back＠exeter.ac.uk 17 Dec '03

17 Dec '03

Anyone read this book? Available on line: http://www.truthmachine.com/ The book is a possible future world scenario exploring the social implications of another new potential technology, a 100% reliable truth test. What would society do with such a device? The book explores the direction in which it is no longer possible to speak untruthfully without detection. A different approach to AP to ensuring honesty in politicians. The political climate has moved to a situation were the population accepts a world government and loss of privacy for the payback of near zero crime rate. Is this utopia or has free will been removed? Certainly many of the premises in the book are contrary to cypherpunk goals in that privacy is erroded (you can not lie, and truth tests with the question as to wether you have committed a crime at routine points, for example when you need to renew a driving license, etc). Government regulation of many aspects of life have been increased. Position escrow or some near-relative is in there too, for the purpose of allowing one to prove what was said, the video stream is sent and encrypted in real time. Also cryogenics, and nano-tech. Interesting technology for cypherpunks to think about the implications, likelihood, desirability etc. Adam

1 0

Re: Where does your data want to go today?
by David F. Ogren 17 Dec '03

17 Dec '03

> > > What problems does compression before encryption have? It at least > > >seems to work for PGP. > > > > > Most compression schemes put a header/index on the front of the > > compressed data. > > This makes recognizing the correct decryption very simple. > > > > Call it a limited "known plaintext" situation. > Using a random IV also limits the effectiveness of using known headers for "known plaintext" attacks. Also note that a good block cipher isn't that vulnerable even to "known plaintext" attacks. -- 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

Re: remailers, mail technology
by Bill Stewart 17 Dec '03

17 Dec '03

>>>Why would anyone set up a remailer at Lance's (or Sameer's) machine? >>>They have remailers running already. If the thugs break root and obtain >>>one remailer key from a machine, they probably get all the keys on that >>>machine, compromising all the remailers in one single attack. Or am I >>>missing something? Is there any benefit of multiple remailers on a machine >>>where root is running his own remailer? There are multiple threats that remailers have to face; multiple remailers on one machine are jointly vulnerable to some of them, but separately vulnerable to others. If there are keys stored in plaintext on a machine, then root-breakers can steal them (unless it's running a multi-level secure operating system that can prevent that, if physical security is maintained.) Thugs confiscating the hardware or trashing the OS obviously break all the remailers at once, though that's only denial of service and not compromise. Offline remailers using POP, UUCP, or other mail forwarding also don't risk compromise (if they only accept encrypted messages), because they don't keep keys or perform encryption on the ISP's server. For all of these cases, the remailer-positive ISP provides a certain amount of flak catching, but can also avoid much of it because _he_ isn't running the remailer - his customers are, and if the remailer gets abused, maybe they'll have to become ex-customers. That's especially effective for ISPs that support customers with their own DNS names - foobar.com is owned by someone other than Sameer, and if Sameer has to squash them, maybe they start getting hosted by Lance instead, or by AOL, or by YAISP.SF.CA.US. Telnet-only shell account providers probably get a little less deniability than dial-only IP+POP providers or especially dial-only IP-only providers. (On the other hand, the fact that Sameer's systems are telnet-only means that users can be spread around to other dial-IP providers, including all those 10-hour AOLers he just has to keep squashing :-), while if he had dial-up users the thugs might go for telephone records. ==== What kind of technical infrastructure would help run remailers in environments like this? I can think of three things - Encrypted IP sessions (either IPv6, if it ever gets deployed, or swIPe) - Encrypted POP and SMTP client/server interactions. - User-based encrypted communications (SSH? SSL?) relaying POP/SMTP. If we're going to get convenient wide deployment before the millenium brings IPv6, the approach will either need to run on shell(-like) accounts only, or else will need to piggyback on SSL. Either way, rather than get everyone to replace POP3 with CryptoPOP (they haven't even done IMAP), it'll probably take some kind of relay that sits on your desktop machine, speaking POP3-server on one side and CryptoPOP on the other. And you'd have to handle firewalls. Is there any way to get Netscape to implement something like pop3: and smtp: services for the client software (or do them as plug-ins)? Adding them to a server (i.e.. Apache-SSL) would allow SSL to do the crypto, and would mean you could use https: proxies to handle firewalls, since everybody's got to deal with them anyway. # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 # goodtimes signature virus innoculation

1 0

Possible out-of-US remailer sites, 2nd edition
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

This is the second edition of my listing of possible good companies outside the US from which to run an anonymous remailer, assuming telnetting to a UNIX shell in most cases. (Those marked with a + have access through PPP, SLIP, or similar protocols). I have removed Malaysia from the listing due to its government's suppression of free speech/press, which Rich Graves was kind enough to point out to me. The countries on here are a mixture of those with strong support for free speech/press, and those with useful laws regarding offshore companies, through which a for-profit remailer might be run with limited liability. _Country/Area_ _Name_ _Email_ Anguilla Cable & Wireless webmaster(a)candw.com.ai Anguilla Offshore Information Services*** info(a)offshore.com.ai Antigua Cable & Wireless scholla(a)candw.ag Barbados CaribSurf webmaster(a)caribsurf.com Denmark cybernet.dk info(a)cybernet.dk Finland Clinet clinet(a)clinet.fi Finland Net People helpdesk(a)netppl.fi Finland Xgateway Finland* pal(a)xgw.fi Iceland Multimedia Consumer Services mmedia(a)mmedia.is Isle of Man Advanced Systems Consultants** info(a)advsys.co.uk Jamaica InfoChannel icquery(a)infochan.com Liechtenstein Ping Services afink(a)ping.ch Liechtenstein Online Store webmaster(a)onlinestore.com Malta maltaNET info(a)maltanet.omnes.net New Zealand +PlaNet Free NZ support(a)planet.gen.nz New Zealand +PlaNet FreeNZ Wellington tich(a)wn.planet.gen.nz New Zealand The Internet Group info(a)ihug.co.nz New Zealand +Manawatu Internet Services info(a)manawatu.gen.nz New Zealand Wave Internet Services accounts(a)wave.co.nz Sweden FX fx(a)uni-x.se Sweden Internet One** Support(a)one.se Sweden Kajplats 305 info(a)kajen.malmo.se * = This organization has on its main page a link to a document called the "Declaration of an Independent Internet." It thus may be possible to persuade them to support a remailer at reduced or no charge as part of this. ** = This organization's main page has the EFF blue ribbon, unlike others. *** = This organization is run by a cypherpunk, Vince Cate. It does have the disadvantages of requiring $50 a month or $420 a year for a telnet-only UNIX shell, with a limit of 50 MB/month for mail without extra charges. However, its charge is $20 a month or $168 a year for a POP account, although the limit is then 20 MB/month for mail without extra charges. I would appreciate comment on all aspects of this list. These include: additional companies and countries to add; companies or countries to take off (international politics & law is not my subject); and suggestions about where to look for more (it is quite possible that I did not locate all the lists of out-of-US ISPs). -Allen

2 1

Java Crypto API questions
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

Today, CP's own Marianne Mueller was scheduled to give a talk at JavaOne on the eagerly awaited (at least by this user) Java Crypto API. I could not attend the conference, but downloaded the slides for the presentation <http://java.sun.com/javaone/pres/Crypto.pdf> Viewing the slides left me with some questions that I hope someone that attended the talk might be able to answer: o "Developers do not call into Security Packages directly." It seems the developer calls java.security (presumably provided by Sun), which then will call the Security Packages. Is this view correct? o "Security Packages must be signed. Policy for signing is public and open." I assume the packages must be signed by Sun. How much will it cost to have a package signed? How do I obtain a copy of this "public and open" policy? o "Exportable API. Exportable applications." One code example shows performing a DES encryption. Another slide mentions "Support for [...] RSA." This is exportable? What am I missing? o Where can I get more info on "Jeeves", the Java HTTP Server? TIA, Disclaimer: My opinions are my own, not those of my employer. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

2 1

Re: Something that just crossed my mind. Sorry.
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C'punks, At 10:35 PM 5/30/96 -0500, snow wrote: >It is my position (until proven wrong--please) that larger business DON'T >want anonymity. They _want_ to be able to track purchases and use of their >product for several reasons. Two quick answers: 1) What big business wants and what it would be willing to accept in order to make sales, are two different things. While demographic data are nice, an more robust economy full of big spenders is better. 2) Big businesses are made up of individuals. Most individuals would still prefer to have their own privacy preserved even if they would prefer less privacy for others. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: opinions on book "The Truth Machine"
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C'punks, At 03:32 AM 5/31/96 GMT, A.Back(a)exeter.ac.uk wrote: >The book is a possible future world scenario exploring the social >implications of another new potential technology, a 100% reliable >truth test. What would society do with such a device? > >The book explores the direction in which it is no longer possible to >speak untruthfully without detection. A different approach to AP to >ensuring honesty in politicians. If such a device were to exist, you can bet your last e-buck that the politicians would be the LAST to be tested. Today, they ban or highly regulte the PRIVATE use of lie detectors. The excuse is "reliability," but the various levels of government still use them for their own purposes. With a 100% reliable device, they would either claim "national security"--the government needs to lie some times for your own good--or they would rig or evade its application to themselves. Count on it. S a n d y ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

NRC Report, 0, 1, 2
by jya＠pipeline.com 17 Dec '03

17 Dec '03

The first parts of the full NRC report are filed at our Web site: Preface, Executive Summary and Road Map: http://pwp.usa.pipeline.com/~jya/nrc00.txt (92 kb) Part I -- Framing the Policy Issues Chapter 1 Growing Vulnerability in the Information Age http://pwp.usa.pipeline.com/~jya/nrc01.txt (101 kb) Chapter 2 Cryptography: Roles, Market and Infrastructure http://pwp.usa.pipeline.com/~jya/nrc02.txt (80 kb) --------- Remaining 6 chapters and 14 appendices to be announced as completed. --------- Declan reports that an on-line version is due next week. Note that National Academy Press is accepting orders for the printed version, $45.00 + s/h each. For August. National Academy Press, 2101 Constitution Ave, NW, Lockbox 285, Washington, DC 20055. Tel 1-800-624-6242.

1 0

Re: Backdoor in RSA Discovered
by Gary Howland 17 Dec '03

17 Dec '03

> In this paper we present a mechanism that can quite easily be > added to PGP that allows the person who modifies PGP to learn > the private keys of those who use it to generate keys. Furthermore > the keys are leaked securely and subliminally, i.e. even if you > analyze the source code you cannot determine previously generated > keys or future keys, only the attacker can. The only way to detect the > presence of the mechanism itself is by looking over the source code, or > the compiled code. The attack has the effect of turning a database of > public keys into a database of public/private key pairs with respect to > the attacker *exclusively*. Sounds like they are doing something like this: Generate a prime P of 500 bits (say) Encrypt with Mallets public key Generate start_q using (E(P) << 524)/P Keep incrementing start_q until prime, and call this Q Generate N by multiplying P and Q to get a 1024 bit key Top 500 bits of N will be E(P) It could also be done like this: Generate a random H of, say, 290 bits Keep incrementing H until (H << 300) + 1 is prime and call this Q Encrypt H for Mallet H <<= 10 Keep incrementing H until prime Generate N by multiplying P by Q, to get a 900 bit key Bottom 300 (but 10) bits of N will E(P) I'm sure there are few mistakes, and there need to be a few other trivial tests in there somewhere, but I think this should work. The first method should produce "better" keys than the first (as if Mallet cares) I'll try and knock some code up to demonstrate this over the next few days. Gary -- pub 1024/C001D00D 1996/01/22 Gary Howland <gary(a)systemics.com> Key fingerprint = 0C FB 60 61 4D 3B 24 7D 1C 89 1D BE 1F EE 09 06

1 0