December 2003 - cypherpunks-legacy

Re: RemailerNet
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <199408120649.XAA07108(a)ucsd.edu> Lance Cottrell writes: > >Actually, the odds are better than this, .8^5, about 0.33. You will be > >compromised "only" 1/3 of the time. > > > >But if you are sending regular messages to another party, then traffic > >analysis will quickly show that you are communicating, because even if > >the boys at Langley are really dumb, you won't make send more than > >two or three messages without having all the cherries lining up. > > > >You will be protected if you have encrypted your messages, but using > >a remailer network offers little additional protection. > > I am not sure I see why you think that the "cherries" will line up. Remember that the original assumption was that you were choosing five remailers at random, on each transmission. I argue against this strategy; I think that if you know someone is reliable you should stick with them. 80% of the remailers are compromised, so 2/3 of single messages get through OK, 45% of two message sequences, 30% of three message sequences, etc. If a population of users selects five remailers at random and sticks to their initial selection, 1/3 of the population will be compromised immediately. Langley will have to try harder to get the rest. -- Jim Dixon

2 1

POST:Gaining ISDN Privacy with data encryption
by Claborne, Chris 17 Dec '03

17 Dec '03

I received a ton of requests for the article below. One comment. This looks like a perfect application for PGP mainly because of the ease of use and the fact that it includes compression. I may send something in to the editor. REMEMBER: What fallows is a direct quote from the zine. ------------------------------------------------------------ Communications News - August, 1994 Gaining ISDN Privacy with data encryption by Kevin Tanzillo Making the public ISDN network private is possible though data encryption to maintain security, say a pair of ISDN researchers whose organization is soon to become and ISDN user. Wunnava V. Subbarao, professor of electrical and computer engineering Florida International University (FIU), along with research associate Irma B. Fernandez, wrote a paper on testing and evaluating encryption based data security in the ISDN environment. Their interest goes beyond academic. The university, located in Miami, will become an ISDN user when classes resume this fall, linking remote campus in a distance learning application. So far, though, the use of ISDN has been in the university+s research lab. Subbarao explains that BellSouth and Northern Telecom grants have enabled the university to bring in five basic rate ISDN lines and work with a range of equipment. Why we have gotten heavily involved in this is because ISDN is quickly emerging as a real, operational, reliable and cost-effective technology for end-to-end digital connectivity, says Subbarao. Here at FIU a large number of ISDN-based applications are being developed. Some of these are point of sale, security monitoring, medical network and medical imaging. In any of these high-speed data transfers, security is a pressing concern. We have investigated possible standards for ISDN security that allow data, including voice, transmitted over ISDN to have encrypted so that only intended receiver can decipher it. This will make the public network behave like a private network and allow ISDN to be a solution in applications that require authentication, privacy and confidentiality without the expense of leased lines. In a software implementation developed a the FIU lab, the overhead incurred to add security to an ISDN communication is small enough that it will be transparent to the end user, says the paper. We have successfully implemented the DES algorithm in software and the results obtained are satisfactory. The hybrid cryptosystem developed at FIU uses RSA public key cryptogrophy for key pair generation and encrypts a random DES key, then uses DES for encryption of the contents. They used an RSAREF cryptographic tool kit from RSA laboratories. On an average, it takes 68 seconds to generate a pair of 508-bit keys running on a 486 PC base. The RSAREF tool kit allows creation of a key pair of up to 1,024 bits, but the overhead incurred in the time to generate these keys is not warranted, given these keys will only be valid for one communication session. The time to seal, encrypt and decrypt an eight-character file was less than a second, and the time to verify the signature was around three seconds. RSAREF allows for signature and encryption of message files of length up to 1,000 bytes, and timing studies for a file length of 700 bytes resulted in the same overhead as that of the length of eight bytes. We are currently updating our software to test signature and encryption of large binary files, such as image files. Taking more than a minute to create an encryption key may be acceptable in some applications, Subbarao observes, but he has his eye on transmission of medical data, when every second counts. As a result, the FIU lab is working on a time-saving hardware implementation for creating keys. As the Subarao-Fernandez paper concludes, hardware implementation of DES and RSA scheme to privatize public ISDN are virtually transparent to the end users, and the time penalty incurred is insignificant. Regarding privacy of voice, the research paper observes: In the implementation of the ISDN prototype, the voice digitization will require encryption eight characters (64 bits) at a time. Also, for voice applications, since the length and contents of the full voice message is not known beforehand, the message digest and signature for integrity is not applicable. Data transfers over ISDN on the other hand, can take advantage of the message digest and signature for integrity. The appropriate data files will be parsed into eight character (64 bit) blocks for encryption in DES CBC mode. As far as the particulars of the encryption research, the paper explains that the file transfer software was implemented in C programming language. To transfer binary files, we wrote an interrupt-driven serial communications program based on the XModem-1K protocol, which extends the packet size from 128 to 1,024 bytes. File transfers were tested using the B channel in a BRI line. future enhancements include implementation of the Zmodem protocol, which uses a 2K packet size, to take full advantage of the digital characteristics of the transfer medium. What the future holds for this security concept is terminal adapter security extension module that plugs into the PC bus and provides security to the ISDN user while protecting the investment in existing terminal adapters. That module could support speeds to 4 Mb/s. ------------------------------------------- [end of article] ... __o .. -\<, chris.claborne(a)sandiegoca.ncr.com ...(*)/(*). CI$: 76340.2422 PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Avail on Pub Key server.

3 2

Re: Mail-Future Free Remailers
by VACCINIA＠UNCVX1.OIT.UNC.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Karl writes: >> People often like to postulate on the list that eventually there >> won't be any more of these philantropic free remailers, and people >> will be charging small amounts for every remailed message, to make >> some money off it. >> I've thought of a pretty good reason why this might not ever happen. >> [...] one's primary reason might be to ensure oneself anonymity. >Interesting point... I guess that is a good reason why free anonymous >remailers might not ever die out, but pay remailers may be able to >offer enhanced features and services that would tend to attract the >vast majority of customers (assuming such a service would be >considered as valuable by enough people ;) In actuality having only purely commercial remailers in a chain would likely lead to security concerns of the following nature. When remailers end up requiring postage, people will tend to use the cheapest remailers to cut down on costs. Who will be in a position to offer the cheapest rates under a commercial proposition? Someone who has deep pockets, perhaps? An entity that really doesn't rely on profit to stay in business? Our own governmental TLA's could attract much remailer traffic by offering unbeatable prices (with our own taxes), even a modest price edge skews traffic in their favor. This speaks highly for the "every man a remailer" concept. If you know people who run remailers and trust that they are not compromised, a mix of commercial and philanthropic remailers may actually be the most secure chain of remailers to use. One could then safely use the price edge of the commercial remailers and the advanced features they offer and at the same time thwart the TLA planted remailers attempts to trace traffic (at least ideally). This could be done by inserting personally trusted philanthropic remailers into the chain in strategic places. Hal has been mentioning such strategic placement of remailers which is very interesting indeed. Since I leave for Honduras tommorrow I must soon unsubscribe until the 23rd so that I don't usurp all available disk space on our system with cpunks mail while I'm gone. All the organized mayhem on the list will be missed (but I'm not giving up diving in Roaton for it!) see you guys later. Vaccinia(a)uncvx1.oit.unc.edu -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLkkMAz2paOMjHHAhAQFMFQP/er5g6MCw74epniILFOLR2U8TkzDtRDJB KeZU4ghq+FxZVLjOrFUS6ofDAddwnLE4fPG6cFX3L5vRFowh8p+UzbjVNL/uS2Zv Ac5BtIEylRC0kPMwFxc+SiiijJq1qfmdz/RiCE7yD4Vp6pv4Kqps40JmSy1HDC3B 3HvgSqCKu90= =SKvc -----END PGP SIGNATURE-----

3 2

RE: RemailNet
by John Young 17 Dec '03

17 Dec '03

Responding to msg by nobody(a)kaiwan.com (Anonymous) on Sat, 13 Aug 8:2 AM >There might be at least one good reason for NOT going >overseas on that first leg. The NSA's charter >restricts it to international operations. According to published reports, such as Bamford's "Puzzle Palace", NSA does not have a "charter", in part because the originators intent to avoid limitations on operations. The CIA has a charter like you suggest. If you have a public reference on *any* limitation of NSA's operations please post here or send by email. Thanks. John

2 1

Re: Bug in PgP2.6???
by Ben.Goren＠asu.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 4:06 PM 8/12/94, Derek Atkins wrote: >Gee, Claude, where have _you_ been hiding? Look at the date >on that message. > >As for using 2.6 -- I do. It's _only_ a factor in key generation, >and it doesn't weaken key generation enough to be a concern. > >Also, there is a planned bugfix release for sometime soon that >will have the one character patch that fixes that problem. Except that the fix has been a *long* time coming. Hasn't it been about a month since I complained about this? And there's still not even a simple readme on the distribution site. As I said before, if it's serious enough to shout to the world, "we goofed," then it's serious enough to take the ten seconds necessary to make the fix or make the instructions on how to do so obviously available. The EFF has sold us out, and this is making MIT look rather unprofessional. >-derek b& -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: My key is not 'escrowed' with any government agency. iQCVAgUBLkxYmkNl71nP8jvVAQFh4QP/dKmW/OV4nLHknfFVKgJJqgwV9mwjsZ9n myekwvvI8liZmcjSwAJDxTjk4V7xMMrRbE/2zC1fcl7bstgP+5SvbQ/c0jMlPJJ6 i81CXYcIY8WQ5stQmNN+9Qi0wU8E2KUiw96+LgH4P9kc6059aKQYOb26qF3bypQB g5G015QkOQo= =8ala -----END PGP SIGNATURE----- -- Ben.Goren(a)asu.edu, Arizona State University School of Music net.proselytizing (write for info): We won! Clipper is dead! BUT! Just say no to key escrow. And stamp out spamming, too. Finger ben(a)tux.music.asu.edu for PGP 2.6 public key CFF23BD5.

4 3

"finger remailer-list@kiwi.cs.berkeley.edu" now operational
by Raph Levien 17 Dec '03

17 Dec '03

Hi all, I have written and installed a remailer pinging script which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, at http://http.cs.berkeley.edu/~raph/remailer-list.html Please do not take the uptime figures too seriously, at least for another week or so. The script has only been running reliably for a few days. Please let me know about any other remailers which I missed. I've only included remailers which can mail to arbitrary addresses, so I already know chop and twwells are missing. If you've got a Web page, please feel free to include a link to this page. If you think your Web page is relevant to the subject of remailers, let me know and I'll link it in. Comments and suggestions welcome! Raph Levien

1 0

HOPE
by John Young 17 Dec '03

17 Dec '03

Responding to msg by adam(a)bwh.harvard.edu (Adam Shostack) on Mon, 15 Aug 5:41 PM > Anyway, thats my brain dump on clipper from HOPE. >There were a fair number of cypherpunks there; anyone >else want to offer additions or corrections? Thanks for the report Adam. If anyone wants the NY Times light-hearted article on HOPE today email me. John

1 0

Re: ecash-info
by Zipper 17 Dec '03

17 Dec '03

> I found the original message. Digicash has a great product, but their > marketing skills are rather weak. They need someone that knows how to put > their product out into the world. Since just about every store I go to > seems to be a Telecheck customer, you should definitely try to hook up with > them. I can see big $$ for both of you. Try to talk to the man (David > Chaum) himself. > Thanks. I send e-mail to the digicash.support.nl with no luck. After you responded, I was interested enough to web out to them until a core dump dropped me back to reality. I FTP'd some of their promotional stuff including Chaum's articles. For the most part I have been lurking and thought e$ would be nothing more than a pipe dream, until I saw the beta testing msgs. Now I am a little more interested and I am looking for any and all additional research I can find. I think it would be kinda nifty to come up with some kinda' experimental beta test here in the States. I'll do some headscratching and see with what I can find out. > It would be great if you could share any info you might obtain with the > list. Most of us are eager to become customers... > > --Lucky I will CC relevent messages to the list. Only, any system I develop would have to have a centralized database to prevent double-spending and fraud. I don't quite understand how they are going to work around such a problem, and I can probably surmize why the total lack of response from them. -- Joe N. Turner Telecheck International turner(a)telecheck.com 5251 Westheimer, PO BOX 4659, Houston, TX 77210-4659 compu$erv: 73301,1654 (800) 888-4922 * (713) 439-6597 Key fingerprint = EF E3 D5 8A EE F6 EB BB FA C6 BF 3E 12 70 FF 8E

2 1

Nym server?
by nobody＠kaiwan.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- So now do we need a Cypherpunks Nym Server? I notice that somebody else is using my alias... ah, well. For the record, the Diogenes who just got active on Cypherpunks isn't me, and, as you can tell by checking corresponding signatures, I'm the one who called attention to the 6-digit PGP ID clashes, related them to the birthday paradox, and recommended increasing the ID length back in April (Raise your hand if your PGP key ID is F3AF75). It shouldn't come as a surprise: as with everything else in cyberspace, Vernor Vinge predicted it in True Names a decade or so ago, when he noted in passing that the protagonist Mr. Slippery downloaded a massive chunk of bulletin board to his home machine and scanned through it for messages to him, tossing (manually, I think) messages to the several other Mr. Slipperys. Diogenes I -----BEGIN PGP SIGNATURE----- Version: 2.6 iQB3AgUBLk/w7/DWSFsVTVI5AQGa6AMLB4oFNC0k36qqimd6ci3hE1GTLLsfQO23 5vBQanWfmWZ5mSLJiI6ufnwIsXMqMGYhfKgGA+V+K+qb8nHDXrQU+W8ITPnxBSsG KFaPdD7D4Qe1A+x4LCM+nfB4eLJQpX4wxwQ= =FPdH -----END PGP SIGNATURE-----

2 1

Complaints against RSA & PKP
by Anonymous User 17 Dec '03

17 Dec '03

I've taken the liberty of sending the text of the two recently-filed RSA lawsuits to this list, assuming that most of you would be interested. The text was obtained by scanning and then OCR'ing my paper copies, so you shouldn't be surprised to see an error from time to time. Also please note that I've reorganized the footnotes in the interest of readability, as the page & section boundaries are not obvious in the OCR'ed copy. You should be receiving the following three documents. (Note that I have not included the Schedules attached to the complaints, which are quite voluminous, and are not really required in order to understand what's going on here.) First, the Cylink complaint against RSA, filed June 30th. This suit is very brief. Second, RSA's relatively swift motion to dismiss the Cylink complaint, filed July 25th, and desire a hearing on or soon after September 9th on this motion. This document and its enclosed memorandum of supporting points, written by RSA, is substantially longer than the complaint itself and is quite interesting reading. Finally, I've enclosed an immensely interesting and in-depth complaint filed on July 26th by Roger Schlafley, which is probably the best of the bunch. Enjoy...

1 0