December 2003 - cypherpunks-legacy

Caching Cash (ecash speed)
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 9:14 AM 11/9/95, Bill Stewart wrote: >For penny-a-page on-line services, unless ecash transaction costs are >_radically_ >cheap, it probably makes more sense for the service to sell its own tokens, >bought with (anonymous or non-anonymous) ecash, which you then trade for pages. >No calculation required, just an on-line lookup for double-spending >and you don't get your page if you double-spend. An alternative to them >picking the token numbers is for you to give them the numbers and them >to keep them in their database, but that's probably unlikely to be done >and doesn't really buy you much privacy. > >If that's not anonymous enough for you (because your IP address could be >traced when you buy the tokens, and coordinated with them later), >use a packet laundry, or connect from your dialup access provider, >which will tell the newspaper you're port43.server29.netcom.com or >something equally uninformative; or dial in from the public library or cafe. Tokens, coupons, gift certificates, etc., are all good examples of _caching_. As, looked at in a certain way, ordinary folding or jangling cash is an example of caching. (Yes, quibblers, it is true that we view folding money as "real money," but really it's a series of claims against some store of value, formerly gold and silver, and now...?) Instead of constant interactions with a bank, we place money in "cash memory" (I mean, "cache memory"). The concerns Hal raises about ecash speed are important. CPU speeds are not the problem, network speeds are---many home and small business users have very fast CPUs, able to funtion as Web servers all by themselves, but have relatively slow network connections. So, various schemes for reducing the network bottlenecks will be likely. Tokens are a good example. And as Bill notes, token laundries can make them _effectively_ untraceable, good enough for many of the low-value transactions for which they are intended. (As usual, more security means more computation, more delay, all other things being equal. "TANSTAAFL"--There Ain't No Such Thing As A Free Lunch.) --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

New patent rules
by Hal 17 Dec '03

17 Dec '03

Reading the latest Foresight Update articles in the sci.nanotech newsgroup, I came upon an analysis of upcoming changes to the patent laws. With the signing of the GATT treaty the laws will change next year. here is one of the changes, quoting from the article: Infringement. Present U.S. patent law grants to a patent holder the right to exclude others from making, using, or selling the patented invention in the United States. After about January 1, 1996, a patent holder has the right to exclude others also from offering for sale patented products or products made using a patented process. Thus, under the law as amended, the mere offer for sale of a patented product may be treated as an infringing act. In addition, it will be illegal to import a product covered by a U.S. patent. At first I thought this would not have much impact on crypto software, which is of course heavily patented. The current laws already prevent people from making, using, or selling software which uses patented algorithms. The new restrictions on products made using a patented process would not seem to be relevant. But there is a possible interpretation which would be very significant. What if data which has had cryptographic transformations applied were viewed as a product of a possibly patented process? An RSA-signed or -encrypted message might then be such a product. A blinded coin or other credential, a key signature or certificate, virtually all of the things we are interested in could be thought of in those terms. We have occasionally discussed setting up offshore servers and such to perform patented cryptographic algorithms. But if the resulting data is itself illegal to import, that would make this strategy much more difficult. Would it become illegal to "import" messages from non-RSAREF versions of PGP, or to hand someone a Chaum-type cash token issued by an offshore bank in a jurisdiction where his patents don't apply? I wonder if the lawyers on the list have any thoughts about whether such an interpretation of the GATT rules is likely to stand. Hal

1 0

checksums for Netscape Navigator 2.0 Beta 2
by Jeff Weinstein 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This file contains checksums for the Netscape Navigator 2.0 Beta 2 distribution files that are available on the Netscape ftp site under the directory ftp://ftp.netscape.com/2.0beta/. This file has been digitally signed using PGP to assure its authenticity. The version of PGP which was used to create the digital signature on this document was obtained from http://bs.mit.edu:8001/pgp-form.html/. This file was signed using my personal PGP key. My PGP public key, which can be used to verify the signature on this file, can be obtained from my web page using this URL: http://home.netscape.com/people/jsw/my-pgp-key.txt or by searching for 'jsw(a)netscape.com' from the PGP key server at mit: http://www-swiss.ai.mit.edu/~bal/pks-commands.html#extract There are three sets of checksums in this file. The first set of checksums uses MD5 to create 128-bit checksums that can not be forged. The second and third sets of checksums were generated using the two forms of the unix 'sum' command. The 'sum' command creates a 16-bit checksum, which can be used detect accidental corruption during download, but is too small to protect you from malicious tampering. There are two version of the checksums for the unix 'sum' command because unix vendors follow two different standards. I have labeled the checksums with the systems that they are good for. If you are performing the checksum operation on a unix system that is not listed, check both lists and make sure that one matches. Note that some Sun systems have both versions of the sum command, so the results you get will depend on your shell PATH variable. --Jeff ======================================================== These MD5 checksums were generated with the 'md5sum' program from the PGP2.6.2 distribution, which was obtained from http://bs.mit.edu:8001/pgp-form.html/. f4624a2afa4fbab3b91df62a9c9ebe71 unix/netscape-v20b2-export.alpha-dec-osf2.0.tar.Z 0039da76358854a8dbf81297f8695aa4 unix/netscape-v20b2-export.hppa1.1-hp-hpux.tar.Z cbf1b480f74cd0f3545184f441670a81 unix/netscape-v20b2-export.i386-unknown-bsd.tar.Z b5e27641d344cafb15711ccabd02aa62 unix/netscape-v20b2-export.i486-unknown-linux.tar.Z cb22244b63c4b1f0a484a10a2bed3059 unix/netscape-v20b2-export.mips-sgi-irix5.2.tar.Z 160a862a2628a80dd68a9cccccb1a938 unix/netscape-v20b2-export.rs6000-ibm-aix3.2.tar.Z 2b90a96e95f28867b62d037df4e98c9d unix/netscape-v20b2-export.sparc-sun-solaris2.3.tar.Z 4352513f5672c7292bf2d47a2bb61ecd unix/netscape-v20b2-export.sparc-sun-solaris2.4.tar.Z faaebbbc60565fbe9ab6d36b22dfc375 unix/netscape-v20b2-export.sparc-sun-sunos4.1.3_U1.tar.Z d6641fbd95fcf5b27b5f07766f688f3a mac/netscape-2.0b2.hqx 00949f13e3b663dbe8cce6da3be2c39a windows/n1620b2a.exe 06c3e13f81bc3086c3a49b4268718d2a windows/n32e20b2.exe ======================================================== These checksums were generated using the Unix 'sum' command. These checksums are for the form of the sum command that is on Sun, SGI IRIX and HPUX systems. 61292 4184 unix/netscape-v20b2-export.alpha-dec-osf2.0.tar.Z 1449 6837 unix/netscape-v20b2-export.hppa1.1-hp-hpux.tar.Z 18430 4342 unix/netscape-v20b2-export.i386-unknown-bsd.tar.Z 36543 4298 unix/netscape-v20b2-export.i486-unknown-linux.tar.Z 39565 4718 unix/netscape-v20b2-export.mips-sgi-irix5.2.tar.Z 37161 3554 unix/netscape-v20b2-export.rs6000-ibm-aix3.2.tar.Z 49003 5273 unix/netscape-v20b2-export.sparc-sun-solaris2.3.tar.Z 2638 3733 unix/netscape-v20b2-export.sparc-sun-solaris2.4.tar.Z 7356 10974 unix/netscape-v20b2-export.sparc-sun-sunos4.1.3_U1.tar.Z 26809 5065 mac/netscape-2.0b2.hqx 26811 4017 windows/n1620b2a.exe 59280 5512 windows/n32e20b2.exe ======================================================== These checksums were generated using the Unix 'sum' command. These checksums are for the form of the sum command that is on Sun, DEC OSF/1, AIX, BSDI, and Linux systems. 62443 2092 unix/netscape-v20b2-export.alpha-dec-osf2.0.tar.Z 61292 3419 unix/netscape-v20b2-export.hppa1.1-hp-hpux.tar.Z 61270 2171 unix/netscape-v20b2-export.i386-unknown-bsd.tar.Z 06430 2149 unix/netscape-v20b2-export.i486-unknown-linux.tar.Z 23707 2359 unix/netscape-v20b2-export.mips-sgi-irix5.2.tar.Z 36711 1777 unix/netscape-v20b2-export.rs6000-ibm-aix3.2.tar.Z 60075 2637 unix/netscape-v20b2-export.sparc-sun-solaris2.3.tar.Z 22223 1867 unix/netscape-v20b2-export.sparc-sun-solaris2.4.tar.Z 13909 5487 unix/netscape-v20b2-export.sparc-sun-sunos4.1.3_U1.tar.Z 16389 2533 mac/netscape-2.0b2.hqx 38581 2009 windows/n1620b2a.exe 58788 2756 windows/n32e20b2.exe -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMKJFGKwWZfp0yzT1AQGxagP+I81vOCxoKOiqo6oJOYs4YeySjz1Yli9d LmdEXJ6FIsFeiPMws8nTirH3NFNGMSp2jlmfs4ySCh0v4w6xwbZFUpNldnMz0N5c IBUFi5Xcv5qF1aNezkkDVGkFJLfNTuVmXm3LChr1kxVifcsM52vLJis6QzgkwGCT RTs0G3Xwo5s= =1b+c -----END PGP SIGNATURE----- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw(a)netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.

1 0

Re: Timed-release crypto and information economics
by Beavis B. Thoopit 17 Dec '03

17 Dec '03

> That's a pretty large number of assumptions: > > tamper-proof delay line > => tamper-proof crypto box ("transformation function with state") > => tamper-proof delay line > > Why not just put a tamper-proof clock in the tamper-proof crypto box > and not bother with the delay lines? The tamper proof aspect is really secondary to the math question. The idea that if I set up a stream of bits through a transform, that the original state of the transform affects the final outcome after N iterations. If the transform exists, it will ease/eliminate the reliance on the "economics" of cryptography to build a tamper-proof physical device. Here is another implementation of the idea: initialize buffer to '12#fjKL3_*(ASDdj1ll3_13 asdfasd-1-3!#!23' do forever /* actually until the plaintext spews out */ sleep 1 unit for each element in the buffer buffer[ element ] = magictransform( buffer[ element ] ) The initial buffer must be secret! Calculating the intial buffer in such a way that after N iterations the plaintext message appears is what must happen.

1 0

Re: Caching Cash (ecash speed)
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 10:41 11/9/95 -0800, Timothy C. May wrote: >The concerns Hal raises about ecash speed are important. CPU speeds are not >the problem, network speeds are---many home and small business users have >very fast CPUs, able to funtion as Web servers all by themselves, but have >relatively slow network connections. Tim is of course right that network speeds are the problem. However, the network limit is the speed of light and not current network technology. If your bank is half-way around the world, the 1/7 second round trip will kill any chance you have of offering 1/10 second response time. For some thinking on the subject of caching cash, see the "Digital Silk Road" paper accessable through the Agorics home page: http://www.webcom.com/~agorics/ BTW - I don't think we should be talking about a penny/page cost because it is way too high for the current market. For example, my copy of Applied Cryptography V2 cost about $.067/page AND came with the media to keep it "forever". My (used) copy of Snow Crash cost closer to a penny/page and also came with the media. I would think that somewhere between 1/100 to 1/10 of a penny/page is closer to the current market value of the page content. Bill ----------------------------------------------------------------- Bill Frantz Periwinkle -- Computer Consulting (408)356-8506 16345 Englewood Ave. frantz(a)netcom.com Los Gatos, CA 95032, USA

1 0

New address
by mclow＠owl.csusm.edu 17 Dec '03

17 Dec '03

Everyone -- This morning, without any warning, the local university decided to change all their mail aliases. Mail sent to "mclow(a)coyote.csusm.edu" now bounces, and the new address is "mclow(a)mailhost2.csusm.edu". Please update your address books. Sorry about that :-( P.S. Those of you who send mail to Laurie, her email address is now "lclow(a)mailhost2.csusm.edu" -- Marshall Marshall Clow Aladdin Systems mclow(a)mailhost2.csusm.edu Warning: Objects in calendar are closer than they appear.

1 0

Re: ecash speed
by jimbell＠pacifier.com 17 Dec '03

17 Dec '03

>At 09:08 PM 11/8/95 -0800, Hal <hfinney(a)shell.portal.com> wrote: >>Consider, though, what happens in the current ecash system if it were >>used to charge a penny per page. You would click on a link in your web >>browser to go to the new page. It would set the GET request to the >>remote server as usual. > >For penny-a-page on-line services, unless ecash transaction costs are >_radically_ >cheap, it probably makes more sense for the service to sell its own tokens, >bought with (anonymous or non-anonymous) ecash, which you then trade for pages. >No calculation required, just an on-line lookup for double-spending >and you don't get your page if you double-spend. An alternative to them >picking the token numbers is for you to give them the numbers and them >to keep them in their database, but that's probably unlikely to be done >and doesn't really buy you much privacy. I think that one thing that's needed is the concept of probabilistic payments. The problem: How do you pay, say, 1/10th of a penny for a good or service if the minimum denominated coin is a penny? This is important, because as we all know the cost of providing computer services of all kinds (and data transmission) can be expected to continue to drop as time progresses. If we allow the minimum size coin to control our lives, it will keep prices higher than they ought to be and prevent low-cost services from existing. The answer, I suggest, is that the payer and payee should "flip a coin," actually a probability, such that the likelihood of making the payment times the size of the payment equals the intended payment. If a seller wants to sell access at 1/10th of a penny per page, he and I can flip a 10-sided coin (using encryption principles already established) leading to a 1/10 likelihood that I would have to pay 1 cent, and a 9/10 likelihood that I'll get the service for free. On the average, it'll be a payment of 1/10th of a cent.

1 0

Re: Java insecurity - long - argumentative - you are warned.
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Mon, 6 Nov 1995, Ray Cromwell wrote: > > WARNING - THIS MESSAGE CONTAINS INFORMATION THAT MIGHT BE CONSIDERED AS > > A FLAME BY SOME READERS - IT IS LONG AND TEDIOUS - YOU ARE WARNED! > > > > >From the Java Web pages (as combined in Firewalls/BoS): > > > > > The language's security features (not just applets): > > [Long list of bullshit deleted] I don't think that this is *bullshit* ... the questions I mean ... but, I for one am tired of people promoting products in a manner which flies in direct contravention of expert consensus. No one would accept a pharmaceutical company that says a product is X, if it is in fact Y. And no one would question if a researcher came forward, and corrected the company and set the record straight. This is generally called ETHICS ... not bullshit. The problem is not in the messenger, it's in the organization that is simply willing to roll the dice when it comes to public safety and security. > "Dr" Cohen. If you want to criticize Java, why not read the technical > papers rather than spewing questions and assertions based from ignorance. I've got a better suggestion. Why don't companies like Sun ensure that their sales and technical material is reviewed for gross inaccuracies and/or misrepresentations? > When you want to criticize a piece of engineering, you don't look > at the feature list or white paper. As is made clear in your post, > you don't know the meanings of phrases used in the Java paper, nor do > you understand how the machinery works. (e.g. byte code verifier) I won't speak for Dr. Frederick B. Cohen, but I will speak for myself, and provide this list with but a single example. And I won't quote from a white paper, but will instead quote from some Sun literature which crossed my desk the day before yesterday, literature that Sun provided as part of their worldwide introduction of Ultra workstations. What they called a "breakthrough for network computing". What follows is not "technical commentary", but is simply what they provide as information to MIS managers, Sun resellers and invited press. This copyrighted brochure, which looks like it was printed 11/95 makes the following verbatim comment on the "Java Internet Application Language". > Java has an extensive library of routines for coping with TCP/IP > protocols such as HTTP and FTP. Java applications can open and access > objects across the net via URLs with the same ease that programmers are > used to when accessing a local file system. > > Java is intended to be used in networked/distributed environments. > Therefore, much emphasis has been placed on security. The product > enables programmers to create virus-free, tamper-free systems through > public-key encryption authentication techniques. Hmmm, maybe I'm confused, but this is grossly overselling a product's capabilities, and is setting absolutely unrealistic expectations -- expectations which are doomed from the start never to be met, let alone exceeded. This expectations/satisfaction gap will ultimately lead to customer dis-satisfaction. Then again ... the solution to virus-free, tamper-free systems with TCP/IP protocol "coping" has always been a problem that's been waiting for a "product solution" to help all of us to enable our programmers. God help us all. As part of my copious spare time, I might make a personal comment which hopefully gets to some of the powers that be at Sun. Firstly, I wasn't aware that HTTP was a TCP/IP protocol. I didn't even think that there was a draft RFC on it. I thought that all that there was, was an internet-draft, which is a different kettle of fish. I never realized that HTTP was on standards track, and part of the appliction protocol. It really is news to me. But that's a quibble, and I'm really behind on my reading, so, I could be wrong. My second comment is perhaps more actionable. I would much rather that a product clearly and definitively state what it has implemented. Maybe something like the following. Implementation of the following IETF (Internet Engineering Task Force) protocols :IP (RFCs 791, 894; MIL-STD 1777); UDP (RFC 768); TCP (RFC 793, MIL-STD 1778); ARP (RFC 826); RARP (RFC 903); ICMP (RFC 792); BootP (RFCs 951, 1048); RIP (IDEA004); DNS (RFCs 1034, 1035); Internet Subnetting (RFC 950); and Internet Assigned Numbers (RFC 1010). Maybe, also that the product complies with Requirements for Internet Hosts Communications Layers (RFC 1122) and with A Standard for the Transmission of IP Datagrams over IEEE 802 Networks (RFC 10.. something or other). This is far more informative (ironically) than saying that: > Java has an extensive library of routines for coping with TCP/IP > protocols such as HTTP and FTP. Hmmm, FTP. That's RFC 7?? or something like that, isn't it?? As an example, I'd like to know how Java handles a file, that is called foo.bar.au. Does a .au file refer to an audio file, or does it refer to something from Australia?? I'll stop here, and not continue with my deconstruction, especially the part that continues: > Java is intended to be used in networked/distributed environments. > Therefore, much emphasis has been placed on security. The product > enables programmers to create virus-free, tamper-free systems through > public-key encryption authentication techniques. To every problem, a product solution ... we can leave mathematician's at the door, and simply enable our programmers. Those technical analyst rocket scientist types, really can't know anything, at all. Can they? Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E. P.P.S. To Sun: I was also a bit disappointed that nobody thought to show what a vice-presidential tribble looks like on satellite simulcast ... then again, I was thrilled with the female "trader" who spoke about patterns in chaotic systems to her cab driver. Did she work the back office at Daiwa, or something?? Probably believe's in runs of luck, too ...

2 1

Re: Newt on Crypto
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Tue, 7 Nov 1995, Bill Stewart wrote: > >From John Young's posting CYB_lip of a column from the Washington Post > > > "At some point in the not-very-distant future," said > > Speaker Newt Gingrich (R-Ga.) in an August interview in > > Wired with computer guru Esther Dyson, "somebody is going > > to have encryption you can't break.... Governments are not > > going to be able to stop it." > > Newt's an optimist (from the government perspective.) > At some point in the not-very-distant future, > _everybody_ is going to have encryption the government can't break! Oviously, Newt missed a briefing somewhere. His comments leave the impression that -- in the recent past and even at present -- we only had encryption which Governments could break. This is nonsense. We've always had encryption which the government couldn't break. We've had it in the past. We have it at present. And we will have it in the future. We've always had "non-breakable" private communication. A simple example. If I was negotiating at a table with my legal team around me, and the opposing team across from me, and I wanted to send a message to my team that is for their eyes only, all I have to do is write something on the writing pad in front of me, and I have a secure communications channel to them. I can even write it in plain text. My team sees it, while the other team doesn't. This _really_ should not surprise anyone ... especially Newt. Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

1 0

Re: Timed-release crypto and information economics
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 6:52 PM 11/9/95, Beavis B. Thoopit wrote: >> That's a pretty large number of assumptions: >> >> tamper-proof delay line >> => tamper-proof crypto box ("transformation function with state") >> => tamper-proof delay line >> >> Why not just put a tamper-proof clock in the tamper-proof crypto box >> and not bother with the delay lines? > >The tamper proof aspect is really secondary to the math question. >The idea that if I set up a stream of bits through a transform, that >the original state of the transform affects the final outcome after >N iterations. The tamper-proof (more correctly, "tamper-resistant" or "tamper-responding") hardware is so that attackers do not alter the clocks, as one example, to "speed up" the time release. Or grab the key, as another example. (Cranking up the clock speed may or may not be possible and still have the device work, but it's still an attack to consider.) If the attacker can grab the internal state of the device, he can of course run the "transform" talked about above on his equipment. >If the transform exists, it will ease/eliminate the reliance on the >"economics" of cryptography to build a tamper-proof physical device. You'll need to more carefully argue your thesis. I cannot imagine a method, save perhaps for quantum computing techniques, which can avoid the need for "secure secrets," either via a person keeping a secret or a box keeping a secret. If the box is not secure against tampering, and an attacker gets in, he effectively "knows" all of the secrets. BTW, the "launch into solar orbit" scheme that has again surfaced here is just a variant of making the costs of an attack very high. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1