December 2003 - cypherpunks-legacy

Re: Mime/multipart (was Re: PGP Comment feature weakens remailer security)
by Dave Crocker 17 Dec '03

17 Dec '03

At 5:56 AM 11/9/95, Laurent Demailly wrote: >I've waited a bit, but as nobody seem to have pointed out, you can >definitly find a unique stream in a *single* pass (but maybe what you >really want is no pass at all ?) engineering versus math. you can do it in zero passes, sort of. Generate a heafty pseudorandom number and convert it to a heafty ascii string. What are the odds that that string will appear in ANY kind of data you are generating? Low. Measured in years and probably decades. As you do the mime encapsulation, also scan for a collision. When you get it (once every 20 years or so), abort the processing and start over. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker(a)brandenburg.com Sunnyvale, CA 94086 USA http://www.brandenburg.com

1 0

Re: Pegasus Mail 2.20
by Scott Staedeli 17 Dec '03

17 Dec '03

> From: Rich Salz <rsalz(a)osf.org> > Date: Thu, 9 Nov 1995 07:50:44 -0500 > To: scottst(a)ionet.net > Subject: Re: Pegasus Mail 2.20 > Cc: cyperphunks(a)osf.org > I sure hope some tells David Harris that his program is now export > controlled. From my reading of his message, it seemed like he thinks he > "beat the system" because he didn't include actual crypto code. > > Software that says "plug your own crypto here" is considered an anciliarry > device according to the ITAR. Or, as I heard some NSA people call it, > "the classic 'crypto with a hole'." Seems kinda silly that the hole is > the crypto, but hey that anciliiary device clause, you just gotta love > it. > > If Pegasus mail were written to support generic user-loadable content > transforms, that would be different. But even then, you have to be careful > how that's done. If just did some global search-and-replace and came up > with "keyed compression" you wouldn't get past anyone. But if you had an > opaque state block that the user modules could set/use/clear, and you > passed that along with your in/out buffers, then you'd be safe. Of course, > they'd know what is really going on, but are powerless to prevent it. > /r$ > Actually, David Harris is a citizen of New Zealand. If the US government tries anything, at least we'll know if ITAR applies to foreign written freeware. --scottst@ionet.net------http://www.ionet.net/~scottst-- >~<^xXx | "The Internet is simply a means of xX # | communication. Efforts to stop infor- (XXX) # | mation by enjoining it are doomed to (XXXXXXX) | failure in a free society." DON'T TREAD ON ME| -- Prof. Frank Tuerkheimer ======================================================== =========NSA trip phrase of the week: DEUTERIUM=========

1 0

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

17 Dec '03

At 3:58 PM 11/9/95, Beavis B. Thoopit wrote: >Does there exist a storage device that, due to _dynamics_ (or other >factor), prevents the total contents being read in one instance? > >Bubble memory device? Torsion wire memory device? "All crypto is economics." There's a literature of sorts on "tamper-resistant modules," or "tamper-responding modules." Chips or packages that either resist tampering (= reading, opening, etc.) or that give indication they have been read, opened, or otherwise accessed. "Quantum cryptography" aims at providing a "read only once" system. Consult the vast number of articles and comments available. Basically, any secret stored in (traditional) hardware can be gotten with enough money. The issue is the amount of money it takes, and how many tries, to open the hardware. (And it may take a lot. Or destroy a lot of chips in the process. The similarities to bomb disposal are obvious: it may be _possible_ to disarm a bomb, but a lot of "learning" is likely to take place first.) Search the archives if you wish for previous articles I and others have written on reverse-engineering chips with electron beam probes, for example. --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

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