December 2003 - cypherpunks-legacy

CSPAN
by Alex Strasheim 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Although it was probably an exercise in futitility, I sent a note to CSPAN suggesting that they have PRZ as a guest on the Booknotes program that Brian Lamb hosts. I figured that maybe they could have him on in conjunction with the book version of PGP that the MIT press is coming out with. In my note I made the argument that policy concerning cryto is really policy concerning wiretapping and surveillance, and that technological changes are eroding the status quo and forcing us to decide whether we want a lot more surveillance (or at least the potential for it) or a lot less, that since this is going to have a lot to do with how the police interact with the public in the future, it's an important issue, etc. At the end, I appended the transcript of the talk PRZ gave in NYC that was recently posted to the list. I found that particular text to be pretty impressive, and I'm hoping that the folks at CSPAN will as well. There are a few details that I hope will go over well: MIT's involvement, the fact that PRZ has debated the NSA's general counsel, the quotes from the FBI director, etc. On top of that, the conference from which the transcript came seems like the sort of event that CSPAN would televise. I don't know Phil, and I don't know if he'd even want to appear on the program. But there are two things about Booknotes that I think would make it a very good forum for the cryto debate. First of all, Phil would have enough time to explain the issues. That's important, because this isn't something that can be easily packed into a sound byte. Also, although I don't know this for a fact, I would imagine that the program would probably be a pretty good way to reach people on this Hill, both members and staffers. Anyway, I sent them Phil's phone number and his email address. The encouraging thing is that I sent this out more than a day ago, and I haven't heard back from them yet. Ordinarily, when you send them email you get a form letter back within an hour or two. That gives me some hope that maybe some people over there are reading the transcript, and that perhaps they're thinking about it. I don't know if CSPAN is open to lobbying or not, but the more I think about it, the more it seems to me that it could be a very useful forum for the debate. I think it would be worthwhile to let them know the next time Phil's going to speak at an event similar to the one I took the transcript from, and see if they'd be willing to televise it. My feeling is that if we can get the word out to the public at large, we're going to win. == Alex Strasheim | finger astrashe(a)nyx.cs.du.edu alex(a)omaha.com | for my PGP 2.6.1. public key -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLt7LBhEpP7+baaPtAQF65AP+OAL3xt66v55U4Spd/5PenHYaRzs1v/vy P7HyVRI8RjH1Y+nR1cpLRYz+uilSrK9Fk1ew4Qhfja0RNh91kVe2aVHmw7dIxWHv rhFv569LFMQWj73JawdtePaXver+6deWhc8d1VL/PkgXgk5feg6mDEjRUB1GsjgZ FfkoHvrEBQA= =cHR2 -----END PGP SIGNATURE-----

1 0

Re: Cypherpunks@hks.net service
by dmandl＠bear.com 17 Dec '03

17 Dec '03

> From: cactus(a)bb.hks.net > > The cypherpunks(a)hks.net service is now available. > > It will sign any message sent to cypherpunks(a)hks.net with its (currently > 384 bit) key and forward the signed message to cypherpunks(a)toad.com. No offense, but what's the point? What's next, automated key-signing services? Is this just intended to help people who can't sign easily to get around Eric's proposed requirement? If so, it seems like almost an embarrassment--someone setting up a meaningless message signer to spoof the cypherpunk server, which it does easily. Doesn't sound too good to me. --Dave.

4 5

cypherpunk signing service
by sglass＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Operating System: SunOS 4.1.3_U1 Site: netcom12 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1021 Todd... | The cypherpunks(a)hks.net service is now available. | | It will sign any message sent to cypherpunks(a)hks.net with its (currently | 384 bit) key and forward the signed message to cypherpunks(a)toad.com. Does this look right? pub 384/27D5B76D 1994/12/01 Cypherpunk signing agent <cypherpunks(a)hks.net> Key fingerprint = 85 BA D4 6D B8 9D B6 B7 EB 74 11 48 42 45 61 F2 | I welcome any suggestions on the format of the message and the prepended | message. Why not stealth it and just appear as if the sender signed it? | I've made a couple of changes to the format of outgoing messages that | should hopefully make life easier for readers. Thanks, Todd! | The most noticable will be the movement of the blurb, but also very | significant is the removal of the "Reply-To: " (feh on the proliferation | of MUA behaviors) header, and way down on the "noticable" list is an | "Errors-To: " and a "Sender: " header. Lookin' good. | Thanks for y'all's comments: keep 'em coming. Good work. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBFAwUBLt7OeioZzwIn1bdtAQGndwF+JJkJwvNKoSw16//vyK7nbNfxeUxGG3ar 9Ek87KCkqlg+QKbwGcCisaV1PJcu+Lns =vnS5 -----END PGP SIGNATURE----- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address belonging to the signature and forwarded.]

1 0

using us crypto sw outside usa
by Tomaz Borstnar 17 Dec '03

17 Dec '03

Hello! I was wondering what is the legal status for using rsaref ooutside usa. Is it legal or not? Also, what is the legal status of RC4 code posted to the net? Thanks, Tomaz

2 1

hello
by Alan J Lacey 17 Dec '03

17 Dec '03

send me your zine pleas

1 0

Larry is at it again, and is flaming old Eric now.
by Anonymous User 17 Dec '03

17 Dec '03

[BIG flamo at Eric deleted... it ain't worth printing] To keep Larry from forging in my name, I am going to fight fire with fire, and am going to anon post this. Dude, what did Eric Hughes do to you to get you so rabid? As soon as you were found out, you started drooling. Ask your local vet school for your first series of rabies shots... you NEED them. Eric Hughes spends his time and money for support of this list. Do you? Probably not. If he wants signatures, ITS HIS DAMN LIST. Enough of flaming at you, buddy. You are too wasted to hear anything but your typing and drool dropping to the floor as you try to spam this list again. About two months ago, Tim May bitched about the coming of a ton of dillweeds on the Net. Guess I agree on this point with him. LD, there is something called Electro Convulsive Therapy. It does a good job of helping cases that would otherwise be too far gone for medicine. Take a good look at getting treatment. It seems you need it. -- A lurker who does not like the maintainer of this list getting treated like crap for trying something new.

1 0

Re: NYT Potpurri and Econo-cash
by frissell＠panix.com 17 Dec '03

17 Dec '03

>"And flirting with heresy, Mr. Spindler says he sees no need >for the so-called information superhighway. And 500 channels? >Sixty are plenty. 'This is not going to be an all-electronic Pretty stupid considering that the non-interactive 150 channel RCA/Hughes DBS system is one of the hottest sellers of this holiday season. DCF

1 0

Re: Brands excluded from digicash beta
by Wolfgang Roeckelein 17 Dec '03

17 Dec '03

Hi, paul(a)poboy.b17c.ingr.com (Paul Robichaux) wrote: >The more I deal with Digicash, the better First Virtual looks. My technical >preference is for using Brands or Chaum cash; at present, though, there aren't >any shipping Brands servers, and the Digicash folks don't seem to be able to >get all their socks in one bag. Does anybody know how the chaum patents (I think they claimed somewhere that they had applied for some) affect Brands system? Wolfgang --- Dipl.-Wirtsch.-Inf. Voice: +49 261 6509 173 Wolfgang Roeckelein Fax: +49 261 6509 179 WHU Koblenz E-Mail: roeckelein(a)wi.whu-koblenz.de Burgplatz 2 (NeXTmail ok) D-56179 Vallendar Germany

2 1

Re: using us crypto sw outside usa
by adam.philipp＠ties.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >I was wondering what is the legal status for using rsaref outside usa. >Is it legal or not? Depends on whether RSA has a patent in that country... I know of no countries besides the U.S.A. that have a patent on RSA. Using exact code may also violate copyright...that is a tougher matter to prove...but copyright treaties allow some level of international protection...use with care. >Also, what is the legal status of RC4 code posted to the net? It was a trade secret. It is no longer...Copyright issues still are still a problem, but ask an attorney in your country if you are going to use it in a commercial program. Adam Philipp - -- PGP Key available on the keyservers. Encrypted E-mail welcome. SUB ROSA: Confidential, secret, not for publication. -Black's Law Dictionary GJ/CS d H S:+ g? p? au+ a- w+ v++ c++ UL+ UU+ US+ P+ 3 E N++ k- W++ M-- V po- Y++ t++ 5+ jx R G' tv+ b+++ D++ B--- E+++ u** h-- f++ r+ n+ y++-- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBFAwUBLt74TCoZzwIn1bdtAQGrwgF/WOBO0J7eZDmrYd+TrirztXE+0DPG7ODN Gj8VMHuFpWEh92FV1/wkcOlBTQ7bfxtH =DdWH -----END PGP SIGNATURE----- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address belonging to the signature and forwarded.]

2 1

Re: Scalability of Ecash System / Article on Internet Cash available.
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Filched from buyinfo, where they've been talking a lot about e$ lately... >From: brands(a)cwi.nl >Original-From: Stefan.Brands(a)cwi.nl >Subject: Re: Scalability of Ecash System / Article on Internet Cash available. >To: www-buyinfo(a)allegra.att.com >Date: Thu, 1 Dec 1994 16:12:50 +0100 (MET) >Cc: hfinney(a)shell.portal.com >X-Mailer: ELM [version 2.4 PL23] >Mime-Version: 1.0 >X-UIDL: 786299434.063 > >I noticed that the discussion is currently about the e-cash system of >DigiCash. Some good issues have been raised in the discussion, and I >would like to comment in detail about my own opinion in these matters. >As it so happens, I recently wrote an article that addresses in detail >each of the raised concerns, and for this reason it seemed easiest to >simply make this article available by ftp. So I did. The paper is >entitled "Electronic Cash on the Internet," and will appear in the >Proceedings of the Internet Society 1995 Symposium on Network and >Distributed System Security, San Diego, California, Februari 16-17, >1995. To retrieve it: log in anonymously at ftp.cwi.nl, and go to the >directory pub/brands. There you will find the paper, in both dvi and >PostScript format (and Unix-compressed formats). The paper contains >several drawings; if you want to have the complete paper, including >the pictures, then you *must* retrieve the PostScript version. I made >a particular effort to explain the concepts behind the system (many of >which are due to Chaum); see Section 3, it is about five pages with no >math. > > Short abstract of the paper: It is generally realized that the Internet > will not be able to offer full-fledged electronic marketplace > capabilities without a suitable electronic mechanism for processing > payments. The electronic payment mechanism that is presented offers a > variety of features that are believed to be particularly appealing in > this respect. > > To participate, an Internet user must interface to his computer a > tamper-resistant device with an ordinary 8-bit microprocessor, > typically a PCMCIA card, and install some software. Internet service > providers do not need special hardware. Payments can be made > completely *off-line*, and are untraceable and unlinkable. > Multi-party security is guaranteed without parties having to trust > other parties. Transaction processing speeds are such that even > modestly equipped computers will be able to meet the performance > levels required by demanding Internet payment applications. One > particularly interesting such application is click-and-pay ability > when travelling World-Wide-Web links. > >The presented approach may seem to be less attractive than many other >proposals, because it requires tamper-resistant hardware for the >users. In the longer run, though, when the use of e.g. smart cards for >electronic payments has become commonplace, the advantages in my >opinion will significantly outweigh this objection. What will remain >are the advantages: click-and-pay ability to make instantaneous >off-line payments, the ability to cost-effectively serve tens of >millions of participants, the ability to guarantee one's own privacy, >multi-party security, support for different currencies, and >portability of tamper-resistant devices to other payment platforms. > > >Some brief comments on the current discussion: > >--- Michael E. Peirce (mepeirce(a)alf2.tcd.ie) wrote: > >I've been looking at the Ecash payment system and was wondering about > >the problem of scalability if it were to become popular. > >(For anyone who doesn't already know, Ecash is an electronic cash > >solution, details of which can be found at http://www.digicash.com ) > >It seems to me that, while their bank (bank.digicash.com) will be able > >to handle the 10,000 odd users in the trial, how would it cope with the > >possibly thousands of transactions that might take place all over the > >Internet, every minute, if the system were to become popular? > >Every transaction requires that the merchant shop, connect to the bank > >to validate the customers coins, right? > >With a popular Ecash system, the bank would be swamped, or what if even > >the link to the bank went down for a few days? > > Hal (hfinney(a)shell.portal.com) wrote: > >There has to be a single common database which all the banks share in > >order to detect double spending. Otherwise I could spend the same coin > >multiple times, going to a different bank each time. Granted, shared > >databases can work, but if a machine which holds part of the database goes > >down it will take special engineering to keep things consistent and > >available. > >There are two different senses in which we can speak of multiple banks. > >One is a setup where all the banks share the same type of cash, where > >they are logically a single bank but distributed to try to get increases > >in reliability. This has the database consistency and access problems I > >described above, which modern-day bank systems don't have to the same > >extent. > > I fully agree with these comments. Btw, it is correct that the e-cash > system of DigiCash is an *on-line* *coin* system. It is interesting to > take a look at their faq, at > http://www.digicash.com/ecashinfo/ecash-faq.html, item > "Does ecash really have to be online?". There is sais: "Actually, no. [...] > We'll add some more functionality in that area as soon as the on-line > system is completely operational." Furthermore, in item "If I copy my > money, can I spend it twice," it sais: "In an off-line > situation (future) ..." From these comments of DigiCash, it seems that > they very well realize the problems associated with on-line verification > when the system is used on a large scale, and that they hope to implement > an off-line system in the future. However, a problem with this might be > the following, as noted by Jim McCoy (mccoy(a)io.com) > >[first part] > >A digital money system can do that, but the current version of Chaum's > >system does not. The disadvantage of a system that does this > >self-identification of double-spenders is that it front-loads the cost of > >the identification protocol into everyone's withdrawls and purchases; they > >must use a cut-and-choose system during withdrawl to make sure that the > >coins presented for blinding are in the proper format and must perform an > >additional protocol negotiation during purchases. > >[...] The overhead involved in the necessary machinations to make sure > >that a malicious cheater did not send in bogus coins that mis-identified > >him increases the transaction cost of such a system significantly. It also > >increases the transaction cost of purchases by requiring the merchant and > >purchaser to perform an additional transaction to reveal halves of the > >identity bits after each purchase. > >[second part] > >It is an interesting version of the > >digital coin protocols, but one that is unlikely to be used in the > >immediate future due to the increased costs it places upon the system. It > >is likely that such a system will first appear in smartcard digital cash > >systems where dedicated hardware can cut down on the increased costs. > > The first part is correct, the overhead caused by the cut-and-choose > withdrawal protocols seems unacceptable. Another problem, which > certainly should not be forgotten, is that is can hardly be said to be > sufficient if only traceability of double-spenders after the fact is > offered. It is clearly desirable that there is prior restraint of > double-spending, and ideally the traceability ater the fact should still > be present (as a second line of defense). Now, doing off-line cash with > prior restraint of double-spending, *and* privacy of payments, seems to > result in extremely inefficient systems when one uses the cut-and-choose > technique of Chaum/Fiat/Naor (just try it, and you'll see what I mean...). > Probably these are the main reasons why DigiCash has not implemented an > off-line system. (Yet a third problem is that it is really cumbersome > to use a coin system if each coin is several kilo-bytes...) > > This is not to say that efficient privacy-protecting off-line cash systems > with prior restraint of double-spending do not exist. The system that I > present in my paper mentioned above meets all these criteria. The > reason for this is that I do *not* use a cut-and-choose withdrawal protocol. > As those of you who have tried to design off-line systems will > know, the design in fact consists of two protocols, one for paying and one > for withdrawal; designing the withdrawal protocol is by far the > hardest task (which is still an understatement...). The > technique that I use for my withdrawal protocols is a new one, called > restrictive blinding, and the only one known thus far that can provide > efficient withdrawal protocols. Curiously enough, most of the withdrawal > protocols that result from this technique are *not* ordinary blind > signature protocols as defined in > literature (because only the signature is blinded---the message is not!). > The withdrawal protocol in my Internet paper is a blind signature protocol, > but for instance the withdrawal protocol that I used in my technical > report (reference 5 in the paper) is not. > >-- Hal (hfinney(a)shell.portal.com) wrote: > >I wish I could. I have applied several times for the beta test at > >digicash, starting almost three months ago. Finally I got a reply at the > >beginning of November saying that I would be hearing from them in a few > >days. Since then, nothing. I wonder if people are actually being > >allowed to join the beta trial as are implied by all of these web pages? > >I would like to see a more honest explanation of the chances of being > >able to experience ecash than the simple "click here to try it out" you see > >everywhere. > > I had exactly the same experience; I sent in the registration several > months ago. I'm still waiting for my account, which was announced to me at > the beginning of this month. > > >Stefan Brands, >------------------------------------------------------ >CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands >Tel: +31 20 5924103, e-mail: brands(a)cwi.nl > > > > > > ----------------- 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

1 0