December 2003 - cypherpunks-legacy

Re: Exporting software doesn't mean exporting (was: Re: lp ?)
by Rich Salz 17 Dec '03

17 Dec '03

> Strangely >enough this would seem to hurt, not help, the NSA in the most important >part of their current mission, which is to help protect US industry >against industrial espionage and virtual terrorism, which is a far more >pressing threat. Matt's NATO adventures, for example, are an interesting example of what happens when the two missions -- "protect our secrets" and "read theirs" -- come into conflict. (Not unlike the US Dept of Agriculture.) Their open involvement in places like W3C, where Agency staff talk about getting Fortezza cards in COTS products provide another datapoint. Budgets cuts may turn out to be strong crypto's best friend. /r$

1 0

Re: Java insecurity - long - argumentative - you are warned.
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Mon, 6 Nov 1995, Dr. Frederick B. Cohen wrote: > WARNING - THIS MESSAGE CONTAINS INFORMATION THAT MIGHT BE CONSIDERED AS > A FLAME BY SOME READERS - IT IS LONG AND TEDIOUS - YOU ARE WARNED! > > 4.2 Security in the Java Environment > > > > Security commands a high premium in the growing use of the Internet > > for products and services ranging from electronic distribution of > > software and multimedia content, to "digital cash". The area of > > security with which we're concerned here is how the Java compiler and > > run-time system restrict application programmers from creating > > subversive code. [long list of important questions deleted ...] Essentially, I think that all of this will distill to a single issue, vis-a-vis Java or any other paradigm which wishes to represent itself as *secure*. Where is the security review role placed within the project development life cycle?? Is it at Design Concept? Or during Application Development? Or is it done last, after design completion, after all of the programming is complete and the production people are involved in operational turnover. Or is it done at all? This concept is not new, and should not present any problems to anyone in the industry. Even John Q. Public will understand it, if we use a simple construction analogy. If you want to build a secure house, your security doesn't start AFTER the house is built. It has to start at a very early stage. It starts before the blueprints are made, when you specify that you want a concrete windowless box located on a quiet street at the end of a cul-de-sac. That is simple and obvious. You certainly don't have *security* if after building a glass house on Main Street, if after the design is finished, the footings have been poured, and the key is about to be turned over to the occupant; if then, as an afterthought you put a single strong deadbolt on the front door to "secure" it. Anyone who can't or won't quite grasp this idea is either willfully attempting to steer gullible individuals astray, or is congenitally stupid. It's time to call a spade a spade. > What exactly does this mean? > > > While all this checking appears excruciatingly detailed, by the time > > the byte code verifier has done its work, the Java interpreter can > > proceed knowing that the code will run securely. Knowing these > > properties makes the Java interpreter much faster, because it doesn't > > have to check anything. Yikes!! I'll leave this for someone else to address. This sounds to me like a variation on virus scanning. I think that there are far more reputable virus experts than I who can comment and expand on *flaws* with that approach. > No runtime checking whatsoever. Get past the supposed verifier, and you > have free run of the machine. A single verifier bug or inadequacy, and > the world is unsafe for electronic commerce. As someone who *vividly* remembers October, 1987 and the near economic meltdown which was BARELY averted by the Fed, a near meltdown which occurred because of the interactions of systems far less intelligent or complex than those we routinely utilize today, systems which directly interface not only to each other, but have undocumented, non-predictable interactions with "soft and wet" systems, I might have some serious concerns. Then again, it is _only_ the economy, isn't it? > ASBESTOS SUITS MAY NOW BE REMOVED - FLAME OFF. > > P.S. > > When: Tuesday, November 7, 8AM > Where: The Hilton, Washington D.C. (the CSI conference) > The talk: 50 Ways to Attack Your World Wide Web Systems > > If you want a chance to heckle - be there. Drat ... I don't think that I'll be able to attend. I've already got a local presentation that I've pencilled in for tomorrow morning at some god awfully early hour. Then again, D.C. isn't quite my circuit. I was hoping though for some clarification. Are you THE Dr. Frederick B. Cohen?? The one who originally coined the phrase "computer virus" and who maintains the computer virus FAQ? Are you THAT Dr. Frederick B. Cohen, and are you speaking publically in Washington, tommorow as one of the keynote speakers? If you are, I'd be interested as to whether you'll talk about the recent gaping security hole in the existing installed Navigator code base which I detailed to this list's subscribers. The one posted this last Friday the Thirteenth, that questioned Netscape's wisdom in creating an experimental MIME object which does not follow the usual HTTP request/response paradigm, but instead allows a server to open and maintain a bi-directional communications channel from server to client. Effectively a non-password protected telnet into the heart of any system, a open exploitable connection which penetrates proxy servers and firewalls, and acts as an enhanced bi-directional delivery/recovery mechanism? I'd be very interested in the comments around that, especially since both Netscape and AT&T (who distributes the softwre under its own brand name) have made an explicit "no comment". I'd especially be interested in any post-session transcript. I also think that Elaine Garzarelli might be interested. Especially since she'll be addressing the nation and the public via the public television airwaves this Friday evening. Or at least ... uhmmm ... I _think_ that's when her electronic daytimer has her pencilled in ... Alice de 'nonymous ... ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

1 0

Re: forging headers (with more header information)
by Bill Stewart 17 Dec '03

17 Dec '03

>Without having any access to anything but the headers, it looks like >you are an employee for SGI and sent the message from there. > >Look at the last Received: header. It went from sgi.com to mit.edu to >well.com and then to you. Obviously was forwarded from a remailer inside SGI .... #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

Re: censored? corrected [Steve Pizzo cited in The Spotlight]
by Rich Salz 17 Dec '03

17 Dec '03

>Originally DNS was just a handy user-friendly thing, but then >it because the primary way to name a host. This allowed the IP address >to become irrelevant, which allows entire sites to be renumbered when the >network topology changes. This is important to keep the routing tables >small (by minimizing the backwards-compatibility exceptions), which is >a critical problem today. Thus all recent architectural decisions have >been away from direct use of IP addresses anywhere. Hunh? The Arpanet always used hostnames. Just about the only time you needed to specify a raw network address was when you were dialed into a TAC and you did things like "@o 137" to connect to mit-mc. DNS was created because the hosts.txt file, a single network-wide file that listed the name, address, aliases, system type, etc., of every host in the Arpanet got to be unmaintainable. Routing is totally unrelated to DNS, based as it is in IP addresses. Routers know nothing about DNS. /r$

2 1

Electronic-reply issues
by Stephen Whitaker 17 Dec '03

17 Dec '03

[Key Words: public records; privacy; encryption; archives; Telecommunications Plan;] November 7, 1995 Mr. Geoffrey Commons Esq. Special Counsel Vermont Department of Public Service State Street Montpelier, Vermont 05602 Dear Mr. Commons: Thank you for your prompt reply to my document request. Yes, I will accept your electronic correspondence as your 'written' reply. However, this brings up several good points which I would ask that you follow up on: The receipt of an e-mail message does not, in and of itself, assure the recipient of the messages' authenticity, privacy or preservation. On the authentication issue, it is well known that the message headers are absolutely insufficient to authenticate the sender of a message. Digital technologies, using encryption, are required here. Other issues are the privacy of the message along it's long path between your desk and my office, and the records later availability, _in electronic format_, if requested. Regardless of the fact that we work only a thousand feet apart here in Montpelier, this message has probably traversed, _in clear text_, through Hartford CT., Albany NY., or Boston MA. prior to being exchanged between the so called 'gov-net' and sover.net. Your reply has also probably been backed up to a tape at the DPS, combined with other exempt public records dealing with current regulatory litigation or consumer complaints. These storage procedures, or lack thereof, could serve to impede future access to these and other records by the public. The original voice mail request and it's written reply take on some form of public records status where, by statute, records must be cataloged so as to be locatable if requested, and archived for a certain period of time pursuant to an approved records retention schedule. Those schedules are approved by the director of public records, John Yacavoni. It occurs to me that the DPS is required under the Vermont statutes governing the preparation of a Ten Year Telecommunications Plan, to analyze telecommunications technologies and the implication of their use in both the public and private arenas. The pertinent parts of the statute are included here for your convenience. *******************begin_included_document**************************** 30 VSA 202d * * * >(b) The department, through the director, shall prepare a telecommunications plan for the state. The plan shall be for a 10 year period and shall serve as a basis for state telecommunications policy. The plan shall include at a minimum: > (1) an overview, looking ten years ahead, of statewide growth and development as they relate to future requirements for telecommunications services, including patterns of urban expansion, statewide and service area economic growth, shifts in transportation modes, economic development, technological advances and other trends and factors which, as determined by the director, will significantly affect state telecommunications policy and programs; > (2) a survey of Vermont residents and businesses, conducted in cooperation with the agency of development and community affairs, to determine what telecommunications services are needed now and in the succeeding ten years; > (3) a study and evaluation of conversion to measured service as ordered by the board; > (4) an assessment of the current state telecommunications system and evaluation of alternative proposals for upgrading the system to provide the best available and affordable technology for use by government. > (c) In developing the plan, the department shall take into account the policies and goals of section 202c of this title, and the need for basic service at affordable rates, improved competition among providers, the needs of the state as user of telecommunications services, and future development of the state. *******************end_included_document*************************** It would then logically follow that a thorough analysis of these issues, which are not created by, but are certainly complicated by telecommunications technologies, should be included in the forthcoming Draft of that plan. The department would then offer the citizens and the business community an opportunity to recommend changes or elaboration on those draft recommendations. These should include, but are not limited to the use of digital signatures, authentication and encryption technologies, and last but not least EDI or Electronic Document Interchange. These technologies are relevant to the state as a whole as far as positioning our citizens and businesses to participate in the rapidly emerging era of electronic commerce (where absolute privacy protections are essential), but are also immediately relevant to the gov-net/ school-net implementation, and even to the workings of your Department of Public Service and the quasi-judicial Public Service Board in order to enable electronic filings, to expedite the backlog of dockets and to answer official document requests. As far as I know there is no other working group addressing these issues at present. Possibly your 'written' reply to my public records request, delivered via e-mail, will serve to catalyze such an effort in the context of a PSB-DPS working group (open to the public, of course) or in one of the amazingly effective forums in which your commissioner participates dealing with telecommunications. One more question: was the voice mail message which I delivered to you, which certainly constitutes a record "created or acquired in the course of agency business", retained, cataloged and archived? Or, if it was destroyed, was it pursuant to an approved records retention schedule? I recall the voice mail message to your Commissioner relating the Clyde River Dam negotiations which prompted a headline story and wish to emphasize the relevance of these new technologies and the management of public records. I look forward to your thoughtful reply, or that of your Commissioner, Richard Sedano. Now aren't you glad you use e-mail? Sincerely, Stephen Whitaker Design Access Network P.O.Box 1331 Montpelier, Vermont 05601-1331 whitaker(a)sover.net At 06:22 PM 11/7/95 EDT, you wrote: >November 7, 1995 > >Dear Mr. Whitaker: > > I have today received your request (left on my voice mail >yesterday, 11/6) to inspect certain documents. I understand your >request to be for access to all staff analyses and internal or >external correspondence regarding 9-1-1 costing or implementation, >prepared or received by the Department of Public Service during >calendar year 1995. Please let me know if I have misunderstood your >message. > > I have relayed your request to all DPS staff, and we are in the >process of collecting and reviewing responsive documents. Due to the >length of time covered by your request, as well as its breadth, it will be >a few days before I can be sure that I have collected and reviewed all >responsive documents. Therefore, pursuant to 1 V.S.A. sec. >318(a)(5)(B), I am advising you that I expect to make the requested >documents available no later than Tuesday, November 14. If I can >make them available earlier, or if unexpected delays are encountered, >I will let you know. Otherwise, you may inspect the documents at the >DPS, 112 State Street, Montpelier on November 14 as provided by >statute. > > Since you requested my reply by e-mail, I am assuming that this >message will suffice as "written notice" under the Access to Public >Records law. Please let me know if you would prefer a response by >ordinary mail. > > Thank you for your inquiry and continuing interest in these >matters. > Sincerely, > > Geoffrey Commons, Special Counsel > Stephen Whitaker /////////////////////////////////////////////////////////////////////// _/_/_/ _/_/ _/ _/ _/ _/ _/ _/ _/_/ _/ _/ _/ _/_/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/ _/_/_/ ESIGN _/ _/ CCESS _/ _/ ETWORK /////////////////////////////////////////////////////////////////////// Design Access Network 802.479.6118 Post Office Box 1331 whitaker(a)sover.net Montpelier, Vermont 05601-1331 PGP public key available

1 0

(fwd) CIS TALK THIS THURSDAY, Nov 9th 4 p.m. in 518
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Sorry about the forward, but you'll see why in a sec... Cheers, Bob --- begin forwarded text Date: Tue, 7 Nov 1995 15:22:34 -0500 To: bsdc(a)ai.mit.edu Subject: [joanne(a)theory.lcs.mit.edu: CIS TALK THIS THURSDAY, Nov 9th 4 p.m. in 518] Sender: bounce-bsdc(a)ai.mit.edu Precedence: bulk From: joanne(a)theory.lcs.mit.edu (Joanne Talbot) Date: Tue, 07 Nov 95 11:57:15 EST To: theory-seminars(a)theory.lcs.mit.edu Reply-To: theory-seminars-request(a)theory.lcs.mit.edu Subject: CIS TALK THIS THURSDAY, Nov 9th 4 p.m. in 518 **Seminar of interest!! CIS Seminar: Thursday, Nov. 9th Place: NE43-518 Refreshments: 4:00 p.m. Talk: 4:15 p.m. Title: Electronic Cash Author: Stefan Brands from CWI Abstract: Two approaches for electronic payments prevail; one focusses on the secure transmission of creditcard numbers and is account-based, while the other is token-based and tries to mimic the way coins or cheques are traded. The first approach can be realized using elementary cryptographic techniques, but offers at best anonymity of payments against merchants and requires on-line payment verification. On-line payment verification can be expensive and become the bottleneck of a large-scale implementation. The second approach, electronic cash, can offer full anonimity of payments, but requires fairly complex cryptographic techniques in order to guarantee security. Pioneering work in this area has been done by David Chaum. Unfortunately, his techniques are practical only for on-line electronic payments and hence less appropriate for large-scale implementation. In my presentation I will discuss the design of practical electronic cash systems that have off-line payment ability. Further information can be found on: http://www.cwi.nl/~brands/ Host: Ronald Rivest --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Re: using pgp to make an otp
by Paul Koning 1695 17 Dec '03

17 Dec '03

Will it ever sink in that NO algorithm produces a "random" bitstring, and therefore NO algorithm can be the driver of a one time pad? The output of an algorithm is (at best) PSEUDOrandom. While a stream cypher constructed that way may be strong, it is NOT a one time pad and does NOT share with one time pad the unique property of being absolutely unbreakable from first principles. (It may very well have the property that it is too hard to break in practice -- if so it makes a useful cryptosystem. But to call such a thing "OTP" indicates a fundamental misunderstanding.) See the sci.crypt FAQ for more details. paul ---------- From: owner-cypherpunks To: Adam Shostack Cc: Alan.Pugh; cypherpunks Subject: Re: using pgp to make an otp Date: Monday, November 06, 1995 11:31PM > PGP output is not random enough to be used for a one time pad. > The security of a OTP is *entirely* based on the quality of the random > numbers; they should come from some strong generator. Building good > one time pads is tough, and usually not worth the effort. No, however the output of "pgp +makerandom=XXX filename.dat" _IS_ random enough for an OTP. The problem then becomes distributing this data. -derek

1 0

Request for URL'S
by carolann＠censored.org 17 Dec '03

17 Dec '03

I have trebled my WWW site size. It is now a comfortable 15 megs big. I'd love to make a Cypherpunk URL page, so if you will send your five favorite URL's I'll put them all on a page like The Dreams Page, (http:www.primenet.com/~carolab/dreams.html) and turn it loose on the net. Nov. 15th is when I will edit up the page. Love Always, Carol Anne -- Member Internet Society - Certified BETSI Programmer - Webmistress *********************************************************************** Carol Anne Braddock (cab8) carolann(a)censored.org 206.42.112.96 My Homepage The Cyberdoc *********************************************************************** ------------------ PGP.ZIP Part [017/713] ------------------- M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M MF=O0H+*%(-S%&>S%+FS&<LS%3(Q&#W1"<]2%`H^;,]^1C$'HBN8PX$4SYAU^ MPGD<Q0ZLA0D+,`MCT!LA**4M[-JPAK9F?40!AJ,CW"'%DR#:'9?Q)3[%<DQ` ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/

1 0

Re: [NOISE] DejaNews all over again--a URL for Usenet Searching
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:49 PM 11/6/95, Peter Trei wrote: >> I usually avoid passing on URLs of interesting sites, in the name of >> conserving bandwidth (*), but this one really has me jazzed: >> http://dejanews.com/ >> It allows searching of Usenet archives (a few months' worth, from what I >> can see). > >Unfortunately, it does not archive alt, soc, talk, or *.binaries (the >latter is >probably a blessing). Specialized news grepping is still useful - see >http://www.iii.net/users/trei/usenet.html for an example. excite Netsearch (http://www.excite.com/) indexes all or part of alt, soc, and talk groups. (I say "all or part" because I obviously cannot verify that it indexes all posts to these groups just by verifying that it indexes at least _some_ posts in these groups.) It even indexes the *.binaries.* groups, as I just learned. (Paul Robichaux told me about the http://www.excite.com/ URL.) --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

forging headers
by tien＠well.sf.ca.us 17 Dec '03

17 Dec '03

So I got this message. How would someone identify the sender of this message? I'm writing an article on anonymity, with some discussion of remailers, and want to argue that forging already permits people to raise the costs of tracing significantly, anonymous remailers or no. Lee >From: freeh(a)fbi.gov >Date: Tue, 24 Oct 95 16:07:08 -0400 >Apparently-To: tien(a)well.sf.ca.us >X-UIDL: 814570964.056 > >> How difficult is it to forge headers? How difficult is it to trace a >> message to the actual sender if the header is forged? > >Not very difficult at all (to forge, that is). This is a quick and dirty >example that should be somewhat traceable. If you want pointers on how to >trace it, post the whole thing, including headers, to cypherpunks. > >Louis > >

4 3