December 2003 - cypherpunks-legacy

Venona NSA web page
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

------- Forwarded Message Date: Wed, 13 Mar 1996 06:59:32 -0500 (EST) From: merkaba(a)styx.ios.com Subject: VENONA PROJECT (fwd) - - ---------- Forwarded message ---------- Date: Tue, 12 Mar 1996 22:07:24 -0500 From: Ronald Pearce <ronald(a)cybercomm.net> To: merkaba(a)styx.ios.com Subject: VENONA PROJECT http://www.nsa.gov:8080/docs/venona/venona.html The VENONA Project In July 1995 the Intelligence Community ended a 50-year silence regarding one of cryptology's most splendid successes - the VENONA Project. VENONA was the codename used for the U.S. Signals Intelligence effort to collect and decrypt the text of Soviet KGB and GRU messages from the 1940's. These messages provided extraordinary insight into Soviet attempts to infiltrate the highest levels of the United States Goverment. Today, we are proud to offer these exceptional documents on the NSA home page and we invite you to study and interpret them in the context of history. NSA will declassify over 2200 messages related to VENONA. We believe they will not only provide a window into Soviet espionage during the 1940's, but will also give you a glimpse of the important contributions signals intelligence and cryptographic expertise make to our nation's security. - - -Ron ==================================================== "We're all pawns, my dear... your move?" No. 66, - - --The Prisoner "Arrival" ====================================================

1 0

Re: recent ( 3 months ) software developements?
by Kent Briggs 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- gjeffers(a)ns.htc.net (Gary Lee Jeffers) wrote: >Dear Cypherpunks, > > Due to really lousey circumstances, I have been unable to monitor my >mail for the last 3 months. Also, last 3 months mail currently unavailble >to me. I am interested in finding out if there have been any new soft- >ware offerings or software upgrades in that time. My particular interest >is Dos/Windows. Also, locations where software can be downloaded. Note >that a brief description of recent software developements maybe helpful >to other Cypherpunks with little time to monitor Cypherpunks list. > > Beat State, > Gary Jeffers > I released version 2.0 of Puffer, my symmetric encryption program for Windows last month. The exportable shareware version (40-bit RC4, uh, I mean PC1) is available from my web site (http://execpc.com/~kbriggs) The registered version uses 160-bit Blowfish. Both versions have a secure wipe feature and a built-in editor for on-the-fly e-mail encryption. Kent - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMUh4QioZzwIn1bdtAQGUDQF+OlQQTGvyfuzAJahBAXIc09V82QDc4IGj 3TUEyrU8Y9n0GAEWwZw+mDRaSSEXbqlc =7HdD -----END PGP SIGNATURE-----

1 0

Re: e$ and markets and meta-markets. quote with little comment
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 12:42 3/14/96, bryce(a)digicash.com wrote: >I just thought I would re-print this extract from the recent >press release regarding the EUNet/Merita ecash roll-out. > > >Favorite phrase: "interesting new possibilities." > > >Follow-ups directed toward e$. If you post to cpunks without >Cc'ing me I probably won't see it. > > > >Bryce > > >******* begin quote from the "companies that accept ecash" section > >SOM -- SOM, the Finnish Securities and Derivatives Exchange >and Clearing House, established in 1987, serves as a >neutral integrated securities and derivatives exchange and >clearing house. SOM offers real-time financial market >information on stocks, options and futures via the >Internet, with invoices payable in ecash. Somtel for >Windows -the application that offers real-time feed, as >well as simulation and position-analysis functions-, is >already available via leased line. > "The use of money makes stock trading less complicated, >with money acting as a practical intermediary between the >transactions." states Asko Schrey, President of SOM. >"However, since stock trades, as well as the shares >themselves, are electronic nowadays, this conventional >transmission of money has actually become a bottleneck and >a threat to the development of the financial world. >Therefore, SOM actively participates in projects to promote >and improve the efficiency of payment traffic. We believe >that electronic money will offer interesting new >possibilities." As mentioned before, one Ecash "currency" per ticker symbol would be a Very Interesting Possibility. No, I am not aware of any plans by DigiCash to implement this. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

1 0

[NOISE] The all.net controversy continues
by Mark Aldrich 17 Dec '03

17 Dec '03

Here's some info from all.net and a host of players IRT the "telnet" fiasco and assorted activities related to it. Crypto relevance is oblique, but some people on this list have implied "knob twidling" intentions. It would appear any number of sites are trying more than twidling. One interesting notion that surfaces in this is what's a "normal" automated inquiry for information versus an "attack." Do I commit computer trespass when I finger someone? Or do I have to try to telnet? Is attempting a telnet into a "guest" account OK if I just want to see if the machine's policy is to welcome visitors? Do they have to post "do not trespass" signs? If all.net's policy is really "nobody's allowed to telnet in," they why don't they just shutdown the damn telnetd, and be done with it? Or, if they want only "authorized" personnel, why not add sufficient crypto to secure the channel? Anyway, it makes for an interesting read.... **BEGIN FORWARDED MATERIAL** --------------------------------------------- Date: Wed, 13 Mar 1996 21:25:03 -0500 (EST) >From: Sick Puppy <sikpuppy(a)maestro.com> Subject: Re: IW Mailing List iw/960313 > [Moderator's Note: I believe that the federal computer abuse statutes > don't require a warning banner. If they did, than any denial of service > attack that ignored responses would be legal.] In our discussions with the FBI about how we could meet the legal requirements for a successful prosecution that would not be thrown out on technicalities, the need for a warning statement or warning banner was stressed by the FBI. I don't remember the specifics but the need to have a warning banner is related to the freedoms guaranteed by the US Constitution and its Amendments. The FBI mentioned a couple of prosecutions by the Secret Service where part of the case was thrown out and the whole case was significantly weakened, because there was no warning banner. I believe that CERT also covers this point in its annual conference/seminar for incident response teams. They usually get a FBI agent with experience in the rules of evidence to speak during the lunch breaks. Maybe there is someone on the list whose recollection on this point is more precise than mine. --------------------------------------------- Date: Wed, 13 Mar 1996 18:46:52 -0600 >From: Walt Auch <waltauch(a)hiwaay.net> Subject: Re: IW Mailing List iw/960313 Quote: [Moderator's Note: I believe that the federal computer abuse statutes don't require a warning banner. If they did, than any denial of service attack that ignored responses would be legal.] Unquote Banners are not REQUIRED, but DOJ has indicated in many conversations that they are "looked upon favorably" by the Court. You do NOT have to prove that they were read - much like you don't have to prove a speed limit sign was read in order to prove speeding - you should just be able to show it was posted. (Scott Charney is the DOJ person - not sure that should be posted.) --------------------------------------------- >From: fc (Fred Cohen) Subject: More progress Date: Wed, 13 Mar 1996 23:59:56 -0500 (EST) So far, we have traced down: A breakin at a community college in Pennsylnavia where the attacker rigged the University computer to automatically telnet to our site every 5 minutes. A port scan followed by a series of scores of attempts to telnet into our site for over an hour from a University site in Arizona. The attacker has been caught. Several IP spoofing attempts that we are tracing down to the specific dial-in accounts used to launch the attack. An intentional insider corruption of a Web page designed to turn innocent browsers into launchpads for their attack. This one was tracked down yesterday and has been stopped after recurrences by contacting this ISPs ISP and the FBI. A web site which is misleading people into telnetting into our site under the auspices of getting a letter from a self-proclaimed computer security expert. What appeared to be a systems administrator at a prominant university who did a port scan followed by numerous telnets. It now looks like this person may not have been authorized by the university to do any of this and it has been raised to another level in the University. Several other individuals have been tracked down as well. 19:52 > From: "Matthew G. Devost" <mdevost(a)chelsea.ios.com> ... > I am concerned over the all.net statement that it will pursue criminal > conspiracy charges against all those that telnet to their site. I asked > what sort of warning banner was in place and hadn't gotten a reply yet > so I checked to see. Well, there is NO warning banner. You simply get > a connection refused by foreign host (and I imagine, a email to root at > my ISP saying I am an evil hacker!). The message changed as incidents occured. Contrary to what previous postings indicated, we haven't historically claimed these events as attacks. We simply state that (current form): A user at your site has just attempted to telnet into our site. No users from your site are authorized to telnet into this site. We thought you would like to know so you could investigate further. If more telnets come from your site, this may indicate a more substantial attempted entry originating from your site, and should be followed up in more depth and more quickly. > Here is my point. It is obvious that someone (an individual) has a > gripe with you or just wants to target your machine, but I would not > call the other attempts a conspiracy. I could post the following > message to a cancer survivor newsgroup or list: At this point in time [see above] several different individuals have been identified as having intentionally attacked this site during the incident. About 5 individuals are responsible for over 90% of all of the attempted entries. > "Hello all! Just wanted you to know that I have set up a Cancer > Survivors network on my host machine. It requires telnet access > for now, but we are hoping to find an easier way to access the > computer in the near future. Please give it a try by telneting > to all.net." Excellent example. This would not be a criminal conspiracy unless some of the participants became accomplices after the fact by lying about the source of the message and actively creating their own similar messages. Then they would become co-conspirators. That's what appears to have happened here. ... > My point, and I realize I am taking a long time getting there, is that > at the very least you should provide a warning banner when folks telnet > to you site telling them that an unauthorized telnet attempt will be > considered an intrusion. We express this in our finger daemon: No users are allowed on this system In the case of telnet, we don't want people getting that far into our system because we believe that such mechanisms may be breakable by high volume attacks. We prefer to stop things at the earliest possible phase and to have layered defenses after that. --------------------------------------------- Subject: Re: IW Mailing List iw/960313 Date: Thu, 14 Mar 1996 10:02:56 -0500 >From: "Michael G. Reed" <reed(a)itd.nrl.navy.mil> |> Well congrats for sparking the list back to life! I think it is |> definitely an IW attack at the Class I level, but I would agree with |> most of the comments from the list that perhaps [all.net is] overreacting. Over reacting, no, inflaming the situation, yes. It is well within the rights of all.net to treat attempted telnets to their machine as attempted break-ins if the proper notification has been given; but personally, I think their handling of the situation is quite silly. One does not get up on a soap box and scream and shout to the world like this -- it just invites (no, begs) more attacks. Instead, you deal with it in the professional manner that system administrators have used for years -- contact other admins and deal with the problem directly. The big problem is *ARE YOU SURE* you have the right people? IP spoofing is trivial these days (a problem that won't be solved until IPv6, if even then) and it would be very easy to mount a concerted attack that *NO ONE* would be able to track down unless you start looking at backbone router logs (which I seriously doubt are being generated or kept) or placing sniffers all over the Internet. [Moderator's Note: Apparently all.net has this well covered because of their previous efforts in automated vulnerability testing.] ... Actually, there are both CERT and DoD bulletins on appropriate warning banners. These banners should (ideally) be displayed *PRIOR* to login (ie, before the login prompt), but most OS's today don't allow for this and as such the banners are normally displayed in the motd. For us (DoD/USN), the message is as follows (at least this is what is showing up on all of our machines): * * * WARNING! * * * This is a U.S. Government/Department of the Navy Automated Information System. This system may be used only for unclassified official business. Unauthorized use of this system is prohibited by Title 18, Section 1030, United States Code. Department of the Navy Automated Information Systems and related equipment are intended for the communication, processing and storage of U.S. Government information, and are subject to monitoring to ensure proper functioning, to protect against improper or unauthorized use or access, to verify the presence or performance of applicable security features or procedures, and for other like purposes. Such monitoring may result in the acquisition, recording, and analysis of all data being communicated, transmitted, processed or stored in this system by a user. If monitoring reveals evidence of possible criminal activity, such evidence may be provided to law enforcement personnel. * * * USE OF THIS SYSTEM CONSTITUTES CONSENT TO SUCH MONITORING. * * * Send questions and/or problem reports to root(a)foobar.mil |> Let me first start by saying that a telnet attempt is the first and most |> obvious step in any electronic intrusion. ... |> Telnet's only purpose is to establish access. I think this is stretching the law a bit. Let me give you an analogy: Suppose I walk up to a military installation. At the gate they will ask me for my pass, but I don't have one on me. Now, as long as I do not attempt to enter, and leave the grounds at that point, have I done anything wrong? Is my attempt to "break in" illegal? I would contend no. Now, if I had been trying to scale the fence at the time I was detected, that is a COMPLETELY different story, but by following normal protocol I am within my rights. This doesn't preclude handling denial-of-service attacks either. If I continually walk up to the military installation and ask for entry without the proper pass, then I am *POSSIBLY* breaking the law (disturbing the peace or harassment at the minimum) or if there are big signs (which I ignore) stating that unauthorized attempts to enter will result in prosecution, then I *AM* breaking the law. |> As for alerting an administrator, it is extremely likely that a person |> trying to get into one system also tries to get into dozens of others. ... Yes, this is what all system administrators should do. I am not saying that systems should hide the fact that they are (or have been) attacked, but that they should handle it professionally and not throw a tantrum (I'm sorry, but that's what all.net's message looks like to me -- a tantrum -- my personal take on reading it). Security on the Internet is a *MAJOR* problem today, the problem is that few people realize this (or to what extent it is a problem). The one good thing coming out of all of all.net's attention to this "attack" is the quality discussions about security, the handling of threats, and what should be done in the future. [Moderator's Note: The all.net banner is shown above.] --------------------------------------------- Date: Thu, 14 Mar 1996 10:24:03 -0800 (PST) >From: watson(a)tds.com Subject: Re: hackers and the law >[Moderator's Note: I believe that the federal computer abuse statutes >don't require a warning banner. If they did, than any denial of service >attack that ignored responses would be legal.] There was a CERT or CIAC about late 1992, and a sidebar in Cheswick and Bellovin that summarizes the fuzzy state of this assertion. Apparently, the attackee has some risk of prosecution under wiretap laws if actions are taken against an attacker without proper notice. The warning banner is considered necessary defense against the attacker's lawyers when he claims he was "just knocking on the door." I haven't heard of a clear precedent on this. Probably varies by jurisdiction, phase of the moon, etc. I would encourage those who post on this topic to state their legal credentials. [Moderator's Note: I'll bite - what are your legal credentials?] --------------------------------------------- **END FORWARDED MATERIAL** ------------------------------------------------------------------------- | Liberty is truly dead |Mark Aldrich | | when the slaves are willing |GRCI INFOSEC Engineering | | to forge their own chains. |maldrich(a)grci.com | | STOP THE CDA NOW! |MAldrich(a)dockmaster.ncsc.mil | |_______________________________________________________________________| |The author is PGP Empowered. Public key at: finger maldrich(a)grci.com | | The opinions expressed herein are strictly those of the author | | and my employer gets no credit for them whatsoever. | -------------------------------------------------------------------------

2 1

Re: FCC-type Regulation of Cyberspace
by jamesd＠echeque.com 17 Dec '03

17 Dec '03

Timothy C. May wrote: >>Mr. Frantz, unless you can prove your claims here, forthwith, I must inform >>you that they are in violation of the Truth in Speech Act of 1996. Please >>retract them, now. Bill Frantz wrote: >Political speech, not commercial speech. The act doesn't apply or is >unconstitutional. I see: The bill of rights reads: "Congress shall make no law [...] abridging the freedom of *political* speech". Never knew that until now. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

2 1

Re: Why escrow? (was Re: How would Leahy bill affect crypto
by Deranged Mutant 17 Dec '03

17 Dec '03

On 14 Mar 96 at 19:41, jim bell wrote: > >Of course that depends how you give your key to an escrow agent. If > >it's already escrowed when you buy a phone, for instance... > > That's the real danger with any such legislation. Individuals can generally > only get things that are manufactured for sale. (You can't buy a car with a > 7-cylinder engine, for instance...) If manufacturers are dissuaded from > building a good crypto telephone, then key-escrow can be as "voluntary" as > you want and you still won't be able to exercise your rights. You might sill be able to buy an unescrowed crypto-phone. If forgeign companies start selling them, then the gov't will have a hard time preventing domestic companies from manufacturing them and exporting them (in theory...) under the legislation. Rob. --- Send a blank message with the subject "send pgp-key" (not in quotes) to <WlkngOwl(a)unix.asb.com> for a copy of my PGP key.

1 0

Internet Security Worskhop Call for Papers
by Joseph M. Reagle Jr. 17 Dec '03

17 Dec '03

------- Forwarded Message From: papers(a)rpcp.mit.edu (Richard J. Solomon) Date: Fri, 15 Mar 1996 12:17:23 -0500 To: {Recipient List Suppressed} Cc: reagle(a)rpcp.mit.edu, execdir(a)fnc.gov Reply-To: papers(a)rpcp.mit.edu Subject: Internet Security Call for Papers CALL FOR PAPERS INTERNET PRIVACY AND SECURITY WORKSHOP Haystack Observatory, MA May 20-21, 1996 Privacy and Security Working Group Federal Networking Council Research Program on Communications Policy Center for Technology, Policy, and Industrial Development Massachusetts Institute of Technology INVITATION The Privacy and Security Working Group (PSWG) of the Federal Networking Council (FNC) and the Research Program on Communications Policy of the Center for Technology, Policy, and Industrial Development at the Massachusetts Institute of Technology will hold an invitational workshop at the Haystack Observatory outside of Boston, MA, on May 20-21, 1996. This workshop is intended to bring Federal, academic and private sector participants together in collaboration to develop strategies and potential solutions related to Internet privacy and security. Though a principal focus of the workshop will be on the Federal portion of the Internet, the FNC recognizes that the Federal Internet is tightly coupled with the Global Internet, whose security policies, practices, and goals are complementary to those of the Federal Government. To define those practices, procedures and goals, the PSWG has undertaken two major initiatives: - The Federal Internet Security Plan (FISP), which was developed as a scalable, continual improvement process, based on common principles and mechanisms compatible with Internet community values and needs; and - The Collaborations in Internet Security (CIS) project, an effort aimed at testing the strength of agency approaches to security and moving these technologies beyond individual agency networking environments and into both inter-agency and agency-commercial sector communications. The CIS will result in the development of a new and sustainable process for developing, integrating, and deploying security technologies that are interoperable at all levels of the Federal government and within the commercial and academic sectors. These initiatives are intended to highlight the critical interface between Federal and commercial users and developers of Internet services and technologies. OBJECTIVES This workshop will bring together principal players in the Federal and overall Internet community to discuss the problems and challenges of privacy and security on the Internet, and will: - Identify critical issues, requirements, and recommendations related to future Internet privacy and security research and development efforts; - Describe "best practice" approaches to Internet privacy and security; - Develop specific strategies for implementing Internet Security programs involving all sectors of the Internet community; - Extend the Federal Internet Security Plan (FISP) by defining specific implementations; and finally, - Develop specific strategies for the migration of technologies from the individual RFC unit test stage to the integration of a complete functional managed system in the CIS test/demonstration/pilot projects. SUBMISSIONS Abstracts or complete paper drafts related to the topics listed above are welcome. Accepted papers will be a part of the published record of the workshop. All points of view on Federal policies affecting Internet privacy and security are welcome. Please make all electronic submissions in ASCII format. For further information or to submit an abstract or paper contact: Internet Security and Privacy Workshop c/o Joseph Reagle Research Program on Communications Policy Massachusetts Institute of Technology One Amherst St. (E40-218) Cambridge, MA 02139 Voice: (617) 253-4138. Fax: (617) 253-7326 papers(a)rpcp.mit.edu SCHEDULE and DEADLINES Call for papers - March 14, 1996 Abstracts Due - April 14, 1996 Invitations to Participants - April 20, 1996 Revised/Completed papers due - May 19, 1996 Workshop - May 20-21, 1996 PARTICIPANTS Participation in the workshop is by invitation, based primarily on submitted papers and abstracts. Additional individuals may be invited to ensure that participation reflects a broad cross-section of the Internet community. PROGRAM COMMITTEE Dennis Branstad - Trusted Information Systems (TIS) Rich Pethia - Computer Emergency Response Team (CERT) Jeffrey Schiller - Massachusetts Institute of Technology (MIT) Richard Solomon - Massachusetts Institute of Technology (MIT) Rick Stevens - Department of Energy /Argonne National Labs (DOE) STEERING COMMITTEE Stephen Squires, Defense Advanced Research Projects Agency (FNC/PSWG Co-Chair) Dennis Steinauer, National Institute of Standards and Technology (FNC/PSWG Co-Chair) Tice DeYoung, National Aeronautics and Space Administration (NASA) Phillip Dykstra, Army Research Laboratory (ARL) Mike Green, National Security Agency (NSA) George Seweryniak, Department of Energy (DOE) Walter Wiebe, Federal Networking Council (FNC) ********************* BACKGROUND Federal Internet Security Plan: In September 1995, the PSWG published the draft Federal Internet Security Plan (FISP). The FISP is oriented toward a scalable, continual improvement process, based on common principles and mechanisms compatible with Internet community values and needs. See <http://www.fnc.gov/SWG.html>. The plan addresses Internet security requirements, including interoperability, from the perspective of the goals and objectives outlined in the National Performance Review (NPR), http://www.npr.gov/. The Federal Networking Council developed this framework in conjunction with its Advisory Committee which represents industry, academia, and non-profit sectors. Action Items, from the FISP, to be addressed during the Workshop: Internet Security Policy and Policy Support Activities * Establish overall Internet security policies * Address security in all Federally supported NII pilots * Coordinate Internet community involvement * Establish an ongoing Internet threat database and assessment capability * Identify legal and law enforcement issues Internet Security and Technology Development * Develop an Internet security maturity model * Develop Internet security architecture * Enhance Internet security services and protocols * Develop a "Secure-Out-of-the-Box" endorsement * Enhance application security Internet Security Infrastructure * Establish a set of Internet security interoperability testbeds * Support privacy, authentication, certificate, and security services pilots * Establish Internet security testing and evaluation capabilities * Improve security incident handling capabilities * Develop security self-assessment capabilities * Establish effective secure software and document distribution mechanisms Education and Awareness * Compile Internet user and site profiles * Encourage use of available security technologies * Establish an Internet security information server * Establish an Internet security symposium/workshop series * Establish an Internet security fellowship program Collaborations in Internet Security: With the Federal government's ever-increasing dependency on computers and distributed systems, there is great urgency for it to develop and employ enhanced information system security technologies and practices. At the same time, these Federal technologies must interoperate with those of the broader Internet community (encompassing the private and academic sectors, along with the Federal sector). In recognition of these needs, the Federal Networking Council's Privacy & Security Working Group (FNC/PSWG) has been awarded a National Performance Review (NPR) Innovation Fund grant to compare and validate agency approaches to security. This Collaborations in Internet Security (CIS) project aims to test the strength of these technologies beyond individual agency networking environments, emphasizing the inter-agency and agency-commercial sector communications. The CIS will result in the development of a new and sustainable process for developing, integrating, and deploying security technology that is interoperable at all levels of the Federal Government and within the commercial and academic sectors. The governing principles behind the Security Testbeds include: employment of an open process (with the activities and results open to participation and comment by both public and private sector participants); a focus on multivendor technologies; an emphasis on testing and experimentally deploying security technologies emerging from research and private sectors as well as security technologies currently in use in the commercial environment; and an underlying objective to ensure interoperability among the broad Internet community (federal, private, and academic). Initial tests will include demonstrations of Kerberos v.5, testing of single-use passwords, and digital signatures. For more information, please see (http://www.fnc.gov/cis_page.html)

1 0

RE: Tim's friend's mildly retarded son
by Blanc Weber 17 Dec '03

17 Dec '03

>From: Asgaard > >The reason FDA has not approved this drug is most probably because >it does not make mildly retarded boys less retarded. But of course, >it's not up to the state to protect people from wasting their money >on snake oil. It becomes more difficult to uphold a pure market >philosophy when it comes to poisonous snake oil or, as is often the >case with potent drugs, effective oil but which will kill you from >side effects after a delay. [. . . . . ] >................................................. > >In reference to the "pure" market: > >The point is not simply that the State should protect people from >snake-oil salesmen. > >There are many "private" agencies whom one can pay to do the work of >research on the actual benefits of a drug; companies which which can, >if one does not have the time or the expert knowledge, perform tests >and such to establish whether there is any danger involved in taking >it. This would be the same kind of work that anyone would need to do >in any case (information that they would need to have), whether as an >individual or a private group or a government agency. > >They, too, can do all the work of checking on the safety of the >product, ensuring that it is good, guaranteeing the reality of any >positive effects, then handing it over to the their client and saying, >"there - now, we are satisfied in our judgement that it is not >dangerous to use it." > >The point is that it is not right to prevent, stifle, suffocate, the >liberty to use one's own resources, to act at one's own discretion and >make one's own choices in regard of one's own particular circumstance, >to make independently the judgements necessary to determine the truth >or falsehood of a statement, or the efficacy of a drug - i.e., it is >not right to have to "give it up" to the State, allowing no one else to >engage in the mental exercise and follow-through. > > .. >Blanc >I hope I'm not the only one here who thinks so. > > > > >

1 0

Re: Interesting Egghead freebee
by Peter Trei 17 Dec '03

17 Dec '03

> From: Alan Olsen <alano(a)teleport.com> > Subject: Interesting Egghead freebee > While at Egghead today, I found out that they are giving away copies of Spry > Mosaic in a Box. (You have to buy something, but that was why I was there > anyways...) So far, it seems to be worth about what you pay for it. It is > designed to connect you to Compu$lave. > What has this to do with this list you ask? The product actually claims to > support S-HTTP! (No export warnings on the package and no real info as to > how it is implemented... I suspect brand-name snake oil here.) For those > of you who do web development and are interested in a client that actually > supports S-Http (I do not believe the d/lable version does), take a look. > (It does install alot of crap, like a new Winsock, so be warned.) Spry Mosaic really does support SHTTP - you can use it to connect to the SHTTP test pages at Terisa and Commercenet without difficulty, once you've doped out how to generate and get signed a low-assurance RSA persona certificate. I just performed an altavista search for references to "shttp://" (the SHTTP prefix) and "https://" (the SSL prefix). The results were 1,000 SHTTP hits, and 20,000 SSL hits. SHTTP may be technicly superior to SSL level 2.0, but as a commercial software developer, I know on which side my bread is buttered. Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

1 0

NOISE: Remailers
by Michael E. Carboy 17 Dec '03

17 Dec '03

Has anon.penet.fi recently died??? Seems to have not been responding for the past week or so... Michael E. Carboy carboy(a)hooked.net

1 0