December 2003 - cypherpunks-legacy

Re: toolkits?
by droelke＠spirit.aud.alcatel.com 17 Dec '03

17 Dec '03

Timothy C. May wrote: > > At 12:41 AM 11/7/95, Stephen Whitaker wrote: > > >just might have a prayer of doing it right, whatever that is. What would it > >look like if secure communications and anonomynity were designed in from the > >start? Is this what Sameer is doing in Bezerkeley? > > > >What machines are considered minimum requirements to use these tools? What > >are the essential reference works? > > "Security and anonymity" are not matters for government to ensure. > [...] > I urge you, Stephen, to read up on encryption and the benefits contained > therein. Looking to your state capital to secure your communications is a > lose. > Tim - I think your libertarian side is showing here.... Not that this is a bad thing, but I think there are some things that state governments can and/or should do. First off - avoid trying to legislate minute details of any encryption or signature scheme. Bureaucrats trying to understand, much less control technical things is doomed to fail. (take GOSIP as a prime example) Second - push for legal acceptance of digital signatures and acceptance of privacy through encryption. I believe Utah has taken a strong step in this direction. Most people, businesses, and courts won't accept digital contracts and the like until there is more of a sound set of laws behind them. Strong laws against government snooping or against anti-encryption or anti-anonymous laws are a good thing IMO. Besides - laws like that will let the bureaucrats drown themselves in their own paperwork making sure then follow their own rules - and keep them out of our hair. ;-) Third - provide services to the citizenry. For example - provide a public key server. Or how about a digital time-stamping service. If the crap was kept out of these services, and they were free for anyone to use, then it would advance the idea of encouraging people to use crypto in their daily lives. Warning - Although I think there are some good things that governments can do, it is also very important to watch out for "sabotage" by the government. Governments tend to like control too much and by trying to maintain control, reverse a useful service to one that is a dis-service to the people. In general, if governments get out of the way, people will take care of problems themselves. Dan ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

1 0

Re: idle CPU markets
by srao＠ISI.EDU 17 Dec '03

17 Dec '03

> Date: Fri, 27 Oct 1995 06:25:34 -0700 > To: cypherpunks(a)toad.com > From: Jay Campbell <edge(a)got.net> > Subject: Re: idle CPU markets > Sender: owner-cypherpunks(a)toad.com > A graphic-arts chum of mine is really hyper about cycle sales - it will > allow him to produce broadcast-quality commercials on a project-by-project > basis without a huge initial hardware upgrade investment. Is anyone working > on a Java libarary/demo/whatnot that allows plug-in algorithms, work > completion 'fetch next batch' code, and some rudimentary authentication > scheme? If not, I may tinker with this - if so, I'd like to chat :) At USC/Information Sciences Institute, we are developing a system that will enable computer owners to sell or barter processor-cycles on the Internet. This is in some ways similar to what you talk about, in that it allows the execution of plug-in applications, and the policies for allocation and deallocation of remote resources are decided by the owners and are transparent to the end user. However, unlike Java, our applications are compiled C programs that execute on *compute servers* rather than on client machines. The application could in turn be an interpreter for some other language (e.g. Java). We also support parallel applications that use the Parallel Virtual Machine (PVM) libraries for interprocess communication. We have implemented a prototype known as the Prospero Resource Manager (PRM); a parallel version of POVRAY raytracing program is one of the applications we've run using PRM. We are currently working on integrating PRM with authentication and payment products (including kerberos, netcheque and netcash) developed as part of our other projects on security and electronic commerce. If you are interested in further information about any of these products, or are interested in participating in any aspect PRM's development we'd be happy to talk to you. More information is also available on our web pages: http://nii-server.isi.edu/info/prm and http://nii-server.isi.edu/gost-group. We also believe that one of the parallel applications for which PRM is useful is showing the weakness of certain encryption methods with limited key size. If anyone has suggestions for algorithms or software that might be included as a demo application in the next release of PRM, please contact me. Santosh Rao.

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

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: Java insecurity - long - argumentative - you are warned.
by goedel＠tezcat.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >> > 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. This "checking," as any comp-sci undergrad will tell you, amounts to solving the halting problem for the java interpreter. While this is possible for a finite state automata like the java interpreter (made more difficult by the fact that it can use the "net" for additional state), it is not even remotely feasable. If you can write a checker that works in a reasonable amount of time, I'll write a turing machine simulator that'll do something nasty if the input machine halts. Then we'll split the fame and fortune for solving the 5 state Busy Beaver problem. Deal? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBgAwUBMJ8gtXIf3YegbdiBAQGqMQJXWzwuPYM2bNb96Fgfb1wGeDC83fNFOW5H 8PQHbnt8bDFsHxKv2L8kcBhtO/TWA0cugVYR9YFf2BOaGoA2UIoCBdwfABM1HAKU hd0H =TA2E -----END PGP SIGNATURE----- Dietrich Kappe | Red Planet http://www.redweb.com Red Planet, LLC| "Chess Space" | "MS Access Products" | PGP Public Key 1-800-RED 0 WEB| /chess | /cobre | /goedel/key.txt Web Publishing | Key fingerprint: 8C2983E66AB723F9 A014A0417D268B84

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