December 2003 - cypherpunks-legacy

Congressional Committee takes to the Net (long) (fwd)
by Robert A. Hayden 17 Dec '03

17 Dec '03

This was emailed to me and thought I'd pass it on. ----------------- This is the initial posting from the Committee on Science, Space, and Technology of the U.S. House of Representatives, chaired by the Honorable George Brown of California. We have agreed to serve as the "beta" testers for House Committees trying to learn how to use the Internet. We posted this message to some of the USENET newsgroups that discuss topics relevant to our jurisdiction over Federal civilian research and development activities to: (1) Increase the number of people who know we do have Internet access; (2) Indicate how we can be reached on the net; and (3) Start learning how to take advantage of this information system in our daily activities. Getting the Congress to use Internet has been discussed in a few threads on various USENET newsgroups of late. Some of you may be familiar with the E-Mail Pilot Project established by the Committee on House Administration, chaired by the Honorable Charlie Rose of North Carolina. Those Members of the House currently maintaining an electronic mailbox for constituent communications may be found by e-mailing "congress(a)hr.house.gov" with the text "HELP" or "INFO" in the message body. You will receive an automated response with the necessary instructions. Also, the text of legislation introduced in the U.S. House of Representatives during the current Congress is now available on a W.A.I.S server located at the House Information Systems data center. The server may be accessed from the directory at quake.think.com or using the following information: Server: diamond Port: 210 Database Name: USHOUSE_house_bill_text_103rd It can also be found on gopher.house.gov in: Congressional Information/Legislative Resources The database contains the text of House bills beginning with October 1993 and is updated daily. What follows now is the message you will automatically receive in response to messages sent to housesst(a)hr.house.gov, the Committee's Internet address. It describes items like the Committee's gopher server, which you can also find at gopher.house.gov. ----------- begin ----------- Welcome to the electronic mailbox system for the Committee on Science, Space, and Technology of the U.S. House of Representatives. This Internet service is provided for ease of communication with the Members and staff of the Committee. If your message is addressed to a specific Member, it will be printed out in hard copy and forwarded to the Member's office for response by U.S. Mail. If your message is addressed to a staff member of the Committee, it will be forwarded electronically to that staff member for response. Depending on the nature of the response, it might reach you in either electronic or postal form. Messages for the Committee press office will be acknowledged electronically and then followed up on, if necessary, with material by post or fax. You can reach the press office directly via Internet at "sstpress(a)hr.house.gov". The Committee also maintains a bulletin board on the House of Representatives Internet gopher server at "gopher(a)hr.house.gov". Much of the public information material provided by the Committee is available on this gopher system. Much of this information also is available on the Committee's "Straight Talk" voice-response system. Dial 202/225-3018 and follow the menu instructions for a touch-tone telephone. Thank you for contacting the House Science Committee. Please be patient as we experiment with this new way of better serving your communications needs. If you wish to write to the Committee, please direct your correspondence to: Committee on Science, Space, and Technology 2320 Rayburn House Office Building U.S. House of Representatives Washington, DC 20515 ----------- end ----------- At this time, we suggest you supply both your e-mail and postal addresses in any communication to the Committee. Each office in Congress has its own policy for responding to public inquiries. So, if we forward your e-mail to a particular Member's office, they may choose to respond with a regular letter. Our Committee hopes to increase our use of e-mail in responding to public inquiries. We have chosen the following subset of USENET groups for our initial foray into the net.world: alt.california alt.cyberspace alt.dcom.telecom alt.politics.datahighway comp.dcom.telecom comp.org.cpsr.talk comp.org.eff.talk misc.education misc.education.science misc.legal sci.agriculture sci.astro sci.bio.ecology sci.chem sci.energy sci.engr sci.environment sci.geo.geology sci.math sci.med sci.misc sci.physics sci.research sci.space.policy talk.environment talk.politics.crypto Please feel free to repost this message to other groups that might find the information of value. Your comments on what should be carried by this channel of communications would also be welcomed. --------------- Committee on Science, Space, and Technology U.S. House of Representatives Washington, D.C. 20515 HOUSESST(a)HR.HOUSE.GOV DISCLAIMER: Opinions expressed in this posting are those of the sender and do not necessarily reflect those of the Committee, the Chairman or any Member of Congress. -- ____ Robert A. Hayden <=> hayden(a)vorlon.mankato.msus.edu \ /__ -=-=-=-=- <=> -=-=-=-=- \/ / Finger for Geek Code Info <=> I do not necessarily speak for the \/ Finger for PGP Public Key <=> City of Mankato or anyone else, dammit -=-=-=-=-=-=-=- (GEEK CODE 2.1) GJ/CM d- H-- s-:++>s-:+ g+ p? au+ a- w++ v* C++(++++) UL++++$ P+>++ L++$ 3- E---- N+++ K+++ W M+ V-- -po+(---)>$ Y++ t+ 5+++ j R+++$ G- tv+ b+ D+ B--- e+>++(*) u** h* f r-->+++ !n y++**

1 0

Re: IDEA vs DES
by norm＠netcom.com 17 Dec '03

17 Dec '03

This morning I said: >would expect that it can be done in under 100 microseconds. Modular >>exponentiation of 1000 bit numbers should take about 2*(1000/24)^3 >>(1/30,000,000MHz) = 2.5 ms without outer loop overhead. Sorry, I goofed! Thanks to Phil Karn for catching me on this. I omitted a factor of 12 which is half of the number of bits in one of my "words". With 24 bits per word the 601 could do a 1000 bit by 1000 bit multiply in (1000/24)^2 fmadd instructions, plus several times (1000/24) fixed point instructions. The fmadd takes 2 clocks. Doing the modular multiply requires about twice as much. Exponentiating by an n bit number requires about n/2 modular multiplies worst case. Doing mod(n^k, m) for 1000 bit numbers thus requires about 2*2*(1000/24)^2*1000/2 clocks. For the slowest (60MHz) 601 this is 58ms.

1 0

MAIL: commercial remailers
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I wrote: >>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 ;) Scott wrote: > 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 But this assumes that commercial remailers will not take in enough money to keep themselves afloat. Which could very well be true! What you describe is a serious problem indeed: in which only a "deep pockets/government front/whatever" can run a pay remailer and most free remailers exist on unsecure systems. > This speaks highly for the "every man a remailer" concept. If you know > people who run remailers and trust that they are not compromised But this is the problem, if the remailer operator is just an ordinary user, he/she may not even know their remailer is compromised, since there is only so much an ordinary user can do. You're trustworthy friends may be victim of a sysadmin who does sendmail logging, etc. Karl Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLkxBbsSF/V8IjI8hAQF4rQP+NOtdzvtGUSK6sZzR1BL6fVAuehZGMM1A bjlGmPFOjN3G+44AsL8+l2BF4RvujGZ7YCRwvhggjpQC2yqI02m7xqlgIukqQlQR zUec88zzGi+XC0CrBovOXZVzlbkl8UxdQXa/FNTjczf4QLd1+8hv7h2D1wb0J0yD BknFwcAibZw= =QhUQ -----END PGP SIGNATURE----- -- Karl L. Barrus: klbarrus(a)owlnet.rice.edu 2.3: 5AD633; D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 2.6: 088C8F21; 97 73 9E 8B 98 3E DD B5 E8 97 64 7E 20 95 60 D9 "One man's mnemonic is another man's cryptography" - K. Cooper

1 0

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