- cypherpunks-legacy - lists.cpunks.org

Re: EFF on why they did it.
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

> This spending cap is...a way to guarantee that carriers' > expenses for electronic surveillance are truly paid for > by the government, not by the customers. > Paid for "by the government"?!! And just where does the EFF think the government gets its money? Are there any taxpayers out there who don't use the phone systems? Looks like they're are going to get a big bill from the government in the next few years. I can't belive the EFF is actually using this as a pro argument. I can't believe the EFF is supporting the Wiretap bill. The EFF is not getting any more money from me. Jim_Miller(a)suite.com

3 2

Re: EFF on why they did it.
by Ben.Goren＠asu.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 7:37 AM 8/12/94, Brian D Williams wrote: >Leahy and Edwards introduce a narrow Digital Telephony bill >with major new privacy protections >============================================================ > >Today Senator Patrick Leahy (D-VT) and Representative Don Edwards >(D-CA) introduced their version of Digital Telephony legislation. >[. . . .] The prisoner was served a meal of fresh lobster and fine wine. All were moved by the priest's blessing, and touched by the prisoner's speech. The doctor signed the death certificate shortly after midnight. b& -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: My key is not 'escrowed' with any government agency. iQCVAgUBLkxYOkNl71nP8jvVAQHrMQP+Pd8l8tCN0oMEhuc77VZIoAnK6Z/KGGJ3 7wSSANYo/lSP6qkt+lmYIuf4FoelCHe6GZNS9yt92H3d2opcs0TTPjkXfkQu8scj XE0/ggwhg8IwvRkB5mj0JzsUH6p0cOr6HSLPXmkzDGP5OYpjPOK+TGp9mO8oa08b oxTDn81SQwg= =nRqo -----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.

1 0

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

Will pay nexusbucks for reliability testing of remailers
by sameer 17 Dec '03

17 Dec '03

I will pay nexusbucks for reports on remailer reliability in terms of lossage. (I.e. 15 messages sent through remailer X on this day, 14 messages returned withint 3 days) Umm.. 16 NexusBucks per two weeks, for a remailer report every week, listing every remailer using the :: and Anon-To commands which support pgp. The listing should be in an easily-parseable format. Mail me if you are interested. -- sameer Voice: 510-841-2014 Network Administrator Pager: 510-321-1014 Community ConneXion: The NEXUS-Berkeley Dialin: 510-841-0909 http://www.c2.org (or login as "guest") sameer(a)c2.org

1 0

Re: Secret sharing made short
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 14:06 1994/08/13 -0700, Hal wrote: .... Obvious only in retorspect. Elegant in any case. Solving that problem had been at the back of my mind for several weeks.

1 0

Re: Tommy Tag Lines
by Ben Goren 17 Dec '03

17 Dec '03

On Sun, 14 Aug 1994, Tommy the Tourist wrote: > On Sun, 14 Aug 1994, Tommy the Tourist wrote: > > Soda's remailer has the IRRITATING feature of putting shit like > > bombing buildings, drugs, et al at the bottom of anon posts/mail. > > That is to intentionaly trip NSA programs what look for particular words > and weed out the amount of work actual agents have to sort through for > Internet intelegence work. > [. . .] > ----- > end transmission > FBI Iran Iraq Nuclear North Korea NSA Pakistan PGP PLO TNT Remember that note that Bruce Schneier sent some time ago about the software the NSA was willing to make available for a price? The NSA is more than capable enough to ignore NSA fodder, I would think. If you want to write something that'll get looked at by a human, you'll have to write the kind of thing that's likely to make you the target of an investigation: "Tim, the supplier screwed up--the .5 Kg Pu shipment ain't gonna happen. Though I guess you know that from reading the papers. I think I can find some from Sergei's friend, but he's getting worried that Mossad might be onto him. Found a sweed deal on 50 mg of *very* high grade U235. Too bad we can't use it with our detonator." Don't expect people to do that in numbers. Besides, what terrorist savvy enough to use the 'net is going to be ignorant of PGP? Or not be paranoid enough to find out about it? b& -- Ben.Goren(a)asu.edu, Arizona State University School of Music net.proselytizing (write for info): The battle is over; Clipper is dead. But the war against Government Access to Keys (GAK) goes on. Finger ben(a)tux.music.asu.edu for PGP 2.6 public key ID 0xCFF23BD5.

2 1