- cypherpunks-legacy - lists.cpunks.org

Cash, cheaters, and anonymity
by Anonymous User 17 Dec '03

17 Dec '03

(my apologies if you've seen this twice -- whizzywig) I thank Hal Finney for his thoughtful reply, and Tim May for his excellent essay. It looks like we can start to draw a stronger conclusion: there are serious holes in the assumptions made by offline digital cash protocols when applied to computer networks rather than manually operated smart cards. Hal's comparison of coin theft to digital signature protection and repudiation is apt, but usually Irving only has one or a few keys to protect, while he might have thousands of coins, issued by various banks. I doubt digital signatures will ever be used alone much for signing expensive contracts. A digital signature on an expensive contract, in addition to being repudiable, will be suspicious, since if few people accept such signatures as strongly binding (the initial state), they will not be widely used on expensive contracts, and thus their existance on an expensive contract will be suspicous. I predict it will become common practice, or even law, that digitally signed contracts over a certain amount are automatically invalid unless further precuations have been taken (signatures of notary witnesses, or perhaps some better crypto protocol designed for this purpose). The trouble with offline cash in a network environment is that the upper limit for fraud liability can be incredibly high. If there are hundreds of thousands of vendors on the net, a situation CommerceNet predicts before the end of the decade, and they are using this offline protocol, then even with small transactions the fraud could run into the millions of dollars. There's plenty of incentive for Irving to steal Jane's coins, run off to some place on the net that has no extradition treaty, and pump good change out of the vendors and into his Lichtenstein account to his heart's content. We may yet find protocols to mitigate or limit this kind of fraud -- make change traceable if linked to double spending, do random online checks as a cypherpunks poster suggested last year, or similar precautions layered on top of the basic protocol. But so far these problems haven't been put on the front burner of digital cash design, and already we have people out there selling offline cash on the network as a superior solution! Reliance on law enforcement flies in the face of cypherpunk goals, and indeed against the goals of good cops as well -- one of their most vocal complaints is about people setting up systems that are vulnerable to crime, putting them in unecessary danger. It also goes against political reality to think that a startup operation can lobby governments all across the globe to protect a system that is ideal for money laundering and tax evasion. Ain't gonna happen -- they'll let those "dirty money banks and money laundering net sites" rot; they may even give Irving a helping hand. I disagree that "there is no excuse" for double spending. If the software is implemented badly (no fault of the user), it might get mixed up with systems programs in such a way as to cause double spending. For example, if the system crashes and one must recover from a month old backup, one has to go through that old purse and determine which coins have been spent. If the software and/or user makes a mistake in this process, we get double spending. If a network burps and sends a vendor two coins where there should have been one, we get double spending. The possibilities for accident are legion and cannot all be foreseen. "Shit happens". A protocol that treats common accident the same as criminal fraud, when the stakes are so high, is pathological. In the online system the consequences of double spending (or million spending) are far more benign. At worst one customer is out stolen coins. In a networked offline system those same few coins are a potential loss for every vendor on the net. As Tim May noted, we may not even need to recongize fraud in online cash -- just treat all online double spending as accident. No bonding, secured accounts, investigators, ID badges or cops with guns busting down Janes's door after Iriving has million-spent her coins. Here we both have a simple liability system and much less chance of fraud. Tim May also suggested that most offline protocols are intended for manually used smart cards. This makes sense -- unlike an network environment with automated spending agents, the scope of multi spending for manually used pruchases in small amounts is quite limited. On the network even fraud of a few cents per transaction can quickly add up to big $$$ across thousands of vendors. What are the communications costs of online clearing anyway? Don't credit card clearings cost about two cents per transaction these days? If clearing costs are less than plausible offline cash fraud and fraud prevention costs, online cash is a winner, both now and increasingly in the future as bandwidth becomes even cheaper. sincerely, -- An Unauthenticated Agent with no credentials: whizzywig

1 0

Re: Dr. Dobbs Crypto CD
by Total Master 17 Dec '03

17 Dec '03

The delay is because "the man" is adding backdoors to everything! As usual, the beaurocracy is behind schedule (just like 1984 occuring way late too). Louie is trying to backdoor everything, Constitution be damned! Chelsie's father (Janet Reno) is in on it too, she loves the backdoor, given the proper tool! ma5ter ----Original Message Follows---- I just got off the phone with DDJ - according to the sales person "the editors are preparing a letter to explain the delay". Seems kind of strange that it is taking so long. Of note - The sales person indicated that there has been no mention of pulling the product. Regards, John Horton Mike Gurski wrote: > > Has anyone received their DDJ crypto CD that's been advertised for the > past half year? > > -- > Michael Gurski mailto:gurski@solipsys.com > Solipsys Corporation http://www.solipsys.com > 6100 Chevy Chase Drive, Suite 200 phone:(301)483-0423 > Laurel, MD 20707-2929 fax:(301)483-8901 ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

m2n@alpha.jpunix.com is down
by John A. Perry 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Now that I've posted that operating a mail2news gateway is a minimal effort, the m2n at jpunix.com has been under a steady spam attack for the past 72 hours. I fought it all day yesterday and came in this morning to find that the spammer had just moved to a different ISP and started spamming again. I have no choice but to shut down the m2n for now in order to stop the spam. If anyone is interested the body of the spam looks like this: Subject: Publicity agents are fun! Hoping you'll have a superly-NICE nite, a FUN day tomorrow, and the most excellent TIMES forever more. - -------------------------------------- This message was brought to you by MarketCom's MktAgent, the interNet's premier webwalking publicity engine. Locate over 100,000 Email penpals in only 5 days with our FREE demo model. http://www.MarketCom.com/MktAgent/ Of course everyone on USEnet is blaming jpunix.com for the SPAM but I knew that would happen when I first started the m2n. Anyway here's hoping that the spammer will get tired and move on and then I'll be able to start it back up. John Perry KG5RG perry(a)alpha.jpunix.com PGP-encrypted e-mail welcome! Amateur Radio Address: kg5rg(a)kg5rg.ampr.org 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 iQCVAwUBNJfAr1OTpEThrthvAQEdXQP/Sc7IVlvi1GbuVMZ+Nv3rWPluxybxZpuJ oSSNI0LObO20dBhI3IZIiWof5I3jpwoIuT8Ha/6IOLO7Rxmat9xj1h3E4j/Mrb6b diTaRiifPG1MiMeuNIYkPSefwqInlQrKSIQ28SEn3/Mc8WclWXEU3+8MQ/gsNc/c E3QZ71TegtM= =LH3k -----END PGP SIGNATURE-----

2 1

Re: UK spooks invent RSA, DH in 1973
by John Young 17 Dec '03

17 Dec '03

Steve Bellovin of ATT has posted a message on Cryptography in response to the CESG paper in which he discloses a 1962 National Security Action Memorandum by President Kennedy on permissive link devices for nuclear weapons which apparently led to NSA invention of PK crypto. Matt Blaze obtained the NASM under FOIA and Steve is offering it on his Web site as GIF images. http://www.research.att.com/~smb/nsam-160/pg?.gif where ? ranges from 1 through 7. We've transcribed the images and put them with Steve's message: http://jya.com/nsam-160.htm BTW, Professor Denning posted an announcement of the CESG paper to UK Crypto (where a notice had appeared earlier) with brief comment of prior art signficance.

1 0

primality code
by pjnesser＠asgaard.rocket.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Can someone point me in the right direction for any archives of code to do primality testing? I would rather not have to right something from scratch. - ---> Phil pjnesser(a)rocket.com (206)885-5010x5477 (voice) (206)882-5750 (fax) -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKuBCjeDb3D8TcGFAQGHyAQAg8SXnZrIpQuWznlLxFS0uU0YM5mhwtXj aG1qtts2vpOzbcNsIyV2zfx01yniOL5E7JycbQWUXJPmN0hRNxCovLWBL2rRJyrQ KqdVUmaOa7RQqtW/Zx7qyCF3jPG0UZJe4KAJg6InwK6Ts3MS9e57Ft0T5iQG6Ygd pb1f7+aiEE0= =NYh0 -----END PGP SIGNATURE-----

2 1

Re: VME As AES?
by Bruce Balden 17 Dec '03

17 Dec '03

I don't suppose the instinctive avoidance of security by obscurity (validated by many problems in the past, especially the Enigma cipher used by the Wehrmacht) has penetrated the great cryptographic minds o Meganet? -----Original Message----- From: John Young <jya(a)pipeline.com> To: cypherpunks(a)toad.com <cypherpunks(a)toad.com> Date: Wednesday, December 17, 1997 12:13 PM Subject: VME As AES? >PR Newswire, December 17, 1997: > >Los Angeles -- IBM telephoned Meganet Corporation ten days ago >after reviewing the Virtual Matrix Encryption (VME) algorithm and >highly recommended the VME technology to be the national >standard for data encryption, reported Meganet. The IBM >spokesperson from the Security Technology Division requested >immediate submission of VME to the National Institute of Standards >& Technology and the Institute of Electrical & Electronic Engineers to >facilitate the standardization. Obviously, Meganet's claim that their >VME technology is completely impenetrable has garnered much >support. > >Source: Meganet Corporation. http://www.meganet.com >

1 0

Re: Can I do Pubkic Domain that -
by Nobuki Nakatuji 17 Dec '03

17 Dec '03

As for me, posted MISTY source code from Japan. Why is it improper if permission isn't taken from NSA/Commerce Dept ? > >Are you looking for access to the MISTY source code? It's still illegal to >export it pending an appeal to the U.S. Supreme Court. Even if that appeal >fails, Congress will likely pass amended laws and/or the NSA/Commerce Dept >will issue revised regulations on the same day that an unfavourable decision >is announced. > >Those guys just never learn that not only is the barn door open, but that >contents were never theirs to begin with. > >-----Original Message----- >From: Nobuki Nakatuji <bd1011(a)hotmail.com> >To: cypherpunks(a)toad.com <cypherpunks(a)toad.com> >Date: Wednesday, December 17, 1997 6:22 PM >Subject: Can I do Pubkic Domain that - > > >>Can I do Pubkic Domain that I posted MISTY source code before? >> >> >>______________________________________________________ >>Get Your Private, Free Email at http://www.hotmail.com > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

e$: A prima facie business model for a digital cash underwriter.
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 3:07 PM 8/27/94 -0700, Rick H. Wesson wrote: >I've finished implementing the GNU mp library in perl of which I've >already extended to work with an Object Relational Database. All this >together gives me very fast access to numbers in the order of 8192 >digets in base 36, geesh I have no clue as to how many base 10 digits that >is but I feel that its proabably enough to play with some digital cash >prototypes... Rick, I've been thinking a little about what we all may see as business models for e-cash use. The least complex model I see, and the one I like the most, is that people simply buy digital cash from an underwriter through a link to some off-net financial entity. NetBank uses a 900 number phone call which generates so-many netbux. My favorite one, and the one which may be most apprehendable to the public, is an ATM-card gate in which the purchaser swipes his card into a secure mosaic screen using a card reader at home (they're pretty cheap these days, and could get cheaper if this became prevalent). If the underwriter could assure the bank in some fashion (maybe it's the bank's gate?) that they can't "sniff" the card key/pin number, then the bank could simply authorize the generation of digital cash from the underwriter to the purchaser on a "pay ya later" basis . That is, the money would be forwarded by the bank from the purchaser's account to the underwriter's suspension account by wire or whatever, trade settled in same-day funds, of course. This is somewhat analogous to the way traveller's checks are generated now, in the sense that the bank functions as an intermediary (buying the checks on a discount, and selling them for a premium) to an underwriter (the issuer of the check). In our case, the bank is just referring a customer and collects a fee for each customer sent to the underwriter. Pricing of the cash at purchase will probably be based on a combination of discounting the costs of the operation of the underwriter, the commission paid to the "sponsoring" bank, and the returns from holding on to the cash in a suspension account (however small that may be). As is the case in traveller's checks, there isn't a fee for using them with a seller, and there are hardly any ID requirements, because the signature's on the check. I believe that a traveller's check is as good as cash at a bank, so the check is "loaded" like a mutual fund at the front of the transaction. In keeping with Eric's point for charging a fee to exit the net, we could also put an additional exchange fee (which would be figured into the same equation which generated the front end fee). The beauty of this method is that the underwriter need not keep any "account" data per se. It has a database of outstanding cash, and it simply honors outstanding cash coming in. When a double-spent digital bank note comes, then the protocol for identifying the double spender is followed, and it's up to the redeemer to settle up with that person. Having said all that, my question is, will your machine handle all the routine activities of an underwriter in the above scenario? We'll ignore interacting with banks for the time being, because that's done in the financial markets already, and interbank operations methods will be different for different underwriters anyway. That means anything put up on your spiffy Sparc machine and it's attendant code should be able to: 1. Generate to purchasers and take in digital cash from sellers. 2. Identify double spenders. That's it. That's obviously a tall order, as lots of people have said here more than once. 1.) It implies an interface to the customer who buys the digital cash which ensures privacy between a bank and a customer, even though an ATM swipe and a PIN goes through it. 2.) It implies a wallet and a register with which to transact business offline, with the assurance that cash is not accidentally double spent. 3.) It implies the managment of what may be a large database of unspent cash that's out there representing contingent claims on a suspension account. It probably also means the need to keep at least sample statistics on spent certificates so that they can be used to determine the longevity of a piece of cash on the net, so that proper management of the suspension account can occur. Obviously, you don't have all that stuff. More to the point, I think 1.) and 2.) above are already out there somewhere. But from talking to you, I'd also think that you have most of the foundation for 3.) taken care of. Obviously, the problems are in legal and regulatory issues, folks. Whoever's algorithm is used to gen up digital cash will want their piece from whoever underwrites digital cash. That's pretty straightforward. Pay them royalties. The banks are going to want to make sure that they get a piece of this, so that they don't disappear (fat chance!). Pay them comissions. Regulators are going to want make sure, well, I don't know what they're going to want, but it'll probably be silly. Given them what they want within reason. Then pay them taxes. If they ask for a total audit trail on off-line transactions, tell them it's impossible. If they forbid off-line transactions because of decreased tax revenue, show them the potential for increased taxes on your operation to make up for it, and show them that you'll follow IRS cash handling protocols just like banks do. Like I've said before, it's a rare parasite which kills its host. If somebody tries to send out a million-quarter attack, it's known how to detect it and to stop it. If someone gets away with it, it's known how to hunt them down and send them to jail. No matter where they are. The point is, we're closer to digital cash than we think. I think that estimates for the delivery of working code for all of the above are way overestimated. I think that the cost of regulatory compliance is way overrated, especially if banks can see a way to make a moderately risk-free living from it. I think the cost of catching a thief and proving he stole money is the same it has always been. I'll sit down now. ;-). Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

2 1

Re: DSN authentication? (fwd)
by Lucky Green 17 Dec '03

17 Dec '03

Some of you may remember my post to the list a while back wondering which, if any, authentication is taking place on commands sent to space crafts such as the Mars Rover. Well, here is the official answer: "We use a private network and keep the protocol specs secret, therefore we don't have to worry about a thing". -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred ---------- Forwarded message ---------- Date: Wed, 17 Dec 1997 12:14:35 -0800 (PST) From: Public Info <info(a)deepspace1.jpl.nasa.gov> To: Lucky Green <shamrock(a)netcom.com> Subject: Re: DSN authentication? Dear Mr. Green: I now have a response to your questions of authentication from one of our Deep Space Network Operations Managers, as follows: The commanding of any spacecraft is performed via a closed and secured network not accessed by the internet or the public. Direct connections provided by NASCOM connect the DSN sites to the project operations centers. There is no other branches nor interconnections available outside this circuit. Each project center determines the bit structure of each command sent, and not even the DSN sites that transmit the commands are aware of the format, protocols, etc. Command data is not stored at the sites to avoid sending commands inadvertently to the spacecraft. As a matter of fact, DSN policy is not to accept responsibility for manually sending commands even in case of a disaster. And, even within this closed circuit, command data is given the highest priority and treated as sensitive data and the command subsystems receiving and transmitting this data have been classified with the with the highest NASA security level. I hope this answers your question. Thank you for your interest. DSN Outreach Office >What authentication methods are employed to authenticate commands sent via >the DSN to space crafts and landers such as the Mars Lander? Please be >specific. Algorithm names, key lenghts, protocol specs, etc. > > > >-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred > > "I do believe that where there is a choice only between cowardice and > violence, I would advise violence." Mahatma Gandhi

1 0

IBM Abandons Cryptolopes
by Fisher Mark 17 Dec '03

17 Dec '03

CNET has the full story at <URL:http://www.news.com/News/Item/0,4,17474,00.html>. Apparently (IMHO), someone at IBM realized that Cryptolopes were isomorphic to copy-protection -- and we all know how much widely-available commercial software is copy-protected today (i.e. none to speak of). As a veteran of the copy-protection wars on the side of the bad guys (the copy-protectors), it is just impossible to fully copy-protect software given the current state of PC and workstation hardware (though I expect most of you already know this). I predict that if someone tries to add features to computers to make copy-protection more tamper-resistant, there will be a great groundswell of protest by the mass of computer users, both private and corporate. Only if such protection were mandated by government (a la Stallman's "The Right to Read") would this even be close to feasible. To close, a quote from Eugene Spafford: "The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards -- and even then I have my doubts." ========================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm(a)indy.tce.com Indianapolis, IN "Their walls are built of cannon balls, their motto is 'Don't Tread on Me'"

1 0