- cypherpunks-legacy - lists.cpunks.org

More mail-to-usenet gateways
by Matthew J Ghio 17 Dec '03

17 Dec '03

group.name(a)paris.ics.uci.edu group.name(a)cs.dal.ca group.name(a)ug.cs.dal.ca I'm sure there must be many, many more such gateways out there, if you know of any, send them my way so I can put them in the listing. If you think you have one, but aren't sure, try this: post a message to alt.test via your mail software (configured to your local machine) and CC: it to me, so I can see the name to the mail-to-news gate. Thanks!

1 0

Science fraud
by Gary Jeffers 17 Dec '03

17 Dec '03

Phil Fraering writes >Uh, Gary, the reason noone's started more research into getting >oil from coal is that it's cheaper to get oil from oil. While we >are too dependent on foreign sources right now, the price of oil >has never been cheaper than now and could go up probably a lot and >not raise the price of gas much compared to how much taxes and >inflation have raised it since 1972. Phil, currently a barrel of oil is a little under $17. That would make a gallon of gas less than 40 cents if it could be refined, distributed, & retailed at no cost. I realize that is just about "dirt cheap". Still, the Fischer-Tropsch reaction is over 90 years old & Germany fueled its part in World War II with it. By now, you would think that we could squeeze oil out of coal "dirt cheap". Its been more that 50 years ago that Germany ran its war effort on this process. I agree with you that it would be very hard to beat the price of oil. Still, the world handles its war machine as though oil were quite precious. You should cure the world of this illusion! Ok - admittedly, an oil embargo that was differentially placed on some nations & not on others would raise the manufacturing & shipping costs of the embargoed nations & put them in a bad trade position. >Look, I'm tired Phil, if I had known my article would just tire & annoy you, I never would have writ it! > and this is cypherpunks. Agreed. My article is not well coupled with the official topic of cypherpunks & it would not be a good thing to tie up too much of cypherpunks bandwith with it. I had hoped to do a quick hit & run with it with cypherpunks & post it on other lists as well. I must give you credit, Phil. It was a damd cagey move on your part to do a bad review on a part of my post & say nothing good about my post at all. As we all know, nothing kills a thread faster than that! And then to give me shit about wasting Cypherpunk bandwith - the ICING ON THE CAKE! Phil is on top of things. I am admonished! Unless someone says something to provoke or encourage this thread, I'm dropping it from Cypherpunks. > I'm willing to discuss >energy policy, etc., over on extropians(a)extropy.org anytime you're >willing to fork over the money to access it (if I have time; I >often don't). I've dropped out of the Extropian's list. Its all I can do to keep up with just this list. Also, I don't want to pay the money & I don't approve of the way the fools hounded Tim May. Phil, I must also disagree with the way you handled your criticism of my post. You panned part of it & then seemed imply that you had fully reviewed it with that. >But anyway, you might want to check out that recent NOVA episode, >"The World Is Full Of Oil." Thanks for the tip. You & NOVA are probably right. The world is probably up to its ass in oil. There is some speculation that oil was not derived from fossilized plant life. On a more serious note, I value the time & bandwith of the Cypher- punks. I posted the post here because I believe that it has rare & valuable information that Cypherpunks would be interested in. Hopefully, I have not wasted much of many Cypherpunks time. Yours Truly, Gary Jeffers

1 0

NARA e-mail standards (fwd)
by Jeff Davis 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Sudaplatov book, McNeil-Lehrer TONIGHT (Monday)
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

It may be too late for the East Coasters, but tonight's McNeil-Lehrer Newshour devotes 30 minutes to the just-released book, "Special Tasks," by Sudaplatov. Sudaplatov was effectively head of SMERSH, which many people think was Ian Fleming's fabrication...it was real, meaining "Death to Spies." Soviet MVD Counterintelligence. His actual title was head of Special Tasks, responsible for spy rings in the U.S. and Germany, assassination of people, etc. Important stuff! Revelations about Oppeheimer, Fermi, Bohr, and Gamov giving assistance to the Soviets, about the death of Trotsky, and about the sabotage of U.S. military bases. I happened to be reading the book today in a local bookshop, and when I got hope Harry Bartholomew, of our list, had left a message alerting me to the McNeil-Lehrer report. Check it out tonight, if you can. Consult your local listings. Many stations air it at 10, others at 11 (the late airings, that is). --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

2 1

No Subject
by anonymous＠extropia.wimsey.com 17 Dec '03

17 Dec '03

Subject: Any cypherpunks building encrypted phone? >I am working on that exact problem. It is not really that trivial. The >encryption has to handle a lot of data real time. I have a license >agreement for IDEA and am working on RSA. I am thinking of using triple >DES rather than IDEA because of the cost of the IDEA license. That seems reasonable to me. While there is some controversy in the community, I haven't heard anyone I respect say that 3DES is not reasonably secure (i.e, comparable to IDEA). But perhaps I've missed those comments! I think that even a straight DES phone would provide Pretty Good security, provided that it generated a new DES key for every call and swapped that key with the other phone via some type of public key encryption. Whether you use DES or 3DES, I suggest putting a button on the phone that force immediate generation and exchange of a new key. The truly paranoid can then press the button as often as they like. >How much would you pay for a good encrypted phone? At $100, I would probably buy one for myself and several more as gifts for friends I'd like to talk to who would be unlikely to buy them themselves. Above $100, I'd still be willing to buy my own, but there would have to be a significant user community for me to talk to. I suspect it will be difficult to persuade the average non-cypherpunk to pay >>$100 for an encrypted phone that hardly anyone has compatible equipment for. You know, we should really spend some time deciding what kind of exchange protocols would be appropriate here on the list. Wouldn't it be nice if all the various groups out there building hardware and software phones could talk to each other? If we can agree on a spec, this can happen. One other thought--the *TRULY* paranoid will want to build their own phones from a schematic, and they may not want to use custom chips that **might** have a backdoor in them. The ideal phone might be based on CPU's, RAM, and DSP's, with no DES chips or anything like that. Lady Ada

1 0

Secure HTTP, Mosaic
by VACCINIA＠UNCVX1.OIT.UNC.EDU 17 Dec '03

17 Dec '03

Below is the information NCSA/EIT sent me about S-HTTP, you can skip the press release at the end if you have already read it. It was posted to the list a short while ago. Vaccinia(a)UNCVX1.oit.unc.edu Thank you for your inquiry regarding Secure HTTP. This message provides some details on the protocol and the status of its implementation. The April 12th joint EIT/NCSA/RSA press release regarding Secure Mosaic is included at the end of the message. OVERVIEW OF S-HTTP We have developed a new protocol for dealing with a wide range of cryptographic modes and algorithms in the context of the World-Wide Web, based on the Web's existing HyperText Transfer Protocol (HTTP). We call this protocol "Secure HTTP" or "S-HTTP". This protocol has been designed to enable incorporation of various cryptographic message format standards into Web clients and servers, including, but not limited to PKCS-7, PEM, and PGP. S-HTTP supports interoperation among a variety of implementations, and is backwards compatible with HTTP. S-HTTP aware clients can talk to S-HTTP oblivious servers and vice-versa, although such transactions obviously would not use S-HTTP security features. IMPLEMENTATIONS AND LICENSING EIT will make available freely usable source code for implementing S-HTTP in both clients and servers. These reference implementations of "Secure NCSA Mosaic" and "Secure NCSA HTTPD" will support two crypto engine implementations: via an integrated TIPEM library (offering PKCS-7 support) and via an "outboard" RIPEM application. RSA has agreed to permit the distribution of their TIPEM library, in binary form, without charge in conjunction with the non-commercial distribution of NCSA Mosaic. Implementors of non-commercial clients or servers may wish to use the already available RIPEM system (which is itself based on RSA's RSAREF library). Commercial implementors or distributors of WWW clients and servers are encouraged to pursue licencing arrangements with RSA or their licencees. FEATURES OF S-HTTP S-HTTP does not require client-side public key certificates (or public keys), supporting a symmetric session key operation mode. This is significant because it means that secure, spontaneous transactions can occur without requiring individual users to have an established public key. While S-HTTP will be able to take advantage of a ubiquitious certification infrastructure, its deployment does not require it. S-HTTP supports end-to-end secure transactions, in contrast with current usage of the existing HTTP authorization protocol which requires the client to attempt access and be denied before the security mechanism is employed. Clients may be "primed" to initiate a secure transaction (typically using information supplied in an HTML anchor); this is used to support encryption of fill-out forms, for example. In S-HTTP, no sensitive data need ever be sent over the network in the clear. S-HTTP provides full flexibility of cryptographic algorithms, modes and parameters. Option negotiation is used to allow clients and servers to agree on transaction modes (should the the request be signed? encrypted? both? what about the reply?); cryptographic algorithms (RSA vs. DSA for signing, DES vs. RC4 for encrypting, etc.); and certificate selection (please sign with your "Mastercard certificate"). ABOUT PKCS-7 PKCS-7 is a cryptographic message syntax standard developed by a consortium of companies lead by RSA. PKCS-7 is compatible with the Internet standards for Privacy Enhanced Mail (PEM) in that signed-data and signed-and-enveloped-data content, constructed in a PEM-compatible mode, can be converted into PEM messages without any cryptographic operations. PEM messages can similarly be converted into the PKCS-7 signed-data and signed-and-enveloped-data content types. In other words, PKCS-7 and PEM implementations can interoperate. PKCS-7 has the following advantages: a) PKCS-7 permits transport of 8-bit data (contrast with PEM, which requires Base-64 encoding). b) PKCS-7 can have a signature-less mode of operation. This permits secure messages to be sent from senders who do not have RSA key pairs. Signature is mandatory under PEM. c) PKCS-7 permits more flexibility in certificate format and trust models. d) PKCS-7 is explicitly designed for algorithmic flexibility. New cryptosystems, message digest algorithms and signature schemes can be added just by defining new types. SCHEDULE An "alpha quality" implementation of Secure Mosaic and HTTPD was demonstrated in public on April 12th. The protocol document is to be sent for external review (to RSA, NCSA and TIS) at the end of April. After revision, we plan to submit it as an "experimental protocol" RFC -- by late May, we expect. The reference implementation will be supplied to beta testers (to the protocol reviewers, and selected CommerceNet sponsors). Public release (to CommerceNet participants) is scheduled for September. CommerceNet will operate a certification authority, suitable for operators of S-HTTP servers (open to CommerceNet participants), beginning at that time. We expect that NCSA will make the reference implementation available to the Internet community soon after. Periodic progress reports will be reported to Internet mailing lists (such as PEM-DEV), and available on the EIT and CommerceNet Web servers (URL's http://www.commerce.net/ and http://www.eit.com/) ORIGINAL PRESS RELEASE Secure NCSA Mosaic Establishes Necessary Framework for Electronic Commerce on the Internet PALO ALTO, Calif., April 12, 1994 -- Enterprise Integration Technologies (EIT), the National Center for Supercomputing Applications (NCSA) at the University of Illinois and RSA Data Security today announced agreements to jointly develop and distribute a secure version of NCSA Mosaic, the popular point-and-click interface that enables easy access to thousands of multimedia information services on the Internet. The announcement was made in conjunction with the launch of CommerceNet, a large-scale market trial of electronic commerce on the Internet. Under the agreements, EIT will integrate its Secure-HTTP software with public key cryptography from RSA into NCSA Mosaic Clients and World Wide Web (WWW) servers. WWW is a general-purpose architecture for information retrieval comprised of thousands of computers and servers that is available to anyone on Internet. The enhancements will then be made available to NCSA for widespread public distribution and commercial licensing. Jay M. Tenenbaum, chief executive officer of EIT, believes secure NCSA Mosaic will help unleash the commercial potential of the Internet by enabling buyers and sellers to meet spontaneously and transact business. "While NCSA Mosaic makes it possible to browse multimedia catalogs, view product videos, and fill out order forms, there is currently no commercially safe way to consummate a sale," said Tenenbaum. "With public key cryptography, however, one can authenticate the identity of trading partners so that access to sensitive information can be properly accounted for." This secure version of NCSA Mosaic allows users to affix digital signatures which cannot be repudiated and time stamps to contracts so that they become legally binding and auditable. In addition, sensitive information such as credit card numbers and bid amounts can be securely exchanged under encryption. Together, these capabilities provide the foundation for a broad range of financial services, including the network equivalents of credit and debit cards, letters of credit and checks. In short, such secure WWW software enables all users to safely transact day-to-day business involving even their most valuable information on the Internet. According to Joseph Hardin, director of the NCSA group that developed NCSA Mosaic, over 50,000 copies of the interface software are being downloaded monthly from NCSA's public server -- with over 300,000 copies to date. Moreover, five companies have signed license agreements with NCSA and announced plans to release commercial products based on NCSA Mosaic. "This large and rapidly growing installed base represents a vast, untapped marketplace," says Hardin. The availability of a secure version of NCSA Mosaic establishes a valid framework for companies to immediately begin large-scale commerce on the Internet." Jim Bidzos, president of RSA, sees the agreement as the beginning of a new era in electronic commerce, where companies routinely transact business over public networks. "RSA is proud to provide the enabling public key software technology and will make it available on a royalty-free basis for inclusion in NCSA's public distribution of NCSA Mosaic," said Bidzos. RSA and EIT will work together to develop attractive licensing programs for commercial use of public key technology in WWW servers." At the CommerceNet launch, Allan M. Schiffman, chief technical officer of EIT, demonstrated a working prototype of secure NCSA Mosaic, along with a companion product that provides for a secure WWW server. The prototype was implemented using RSA's TIPEM toolkit. "In integrating public key cryptography into NCSA Mosaic, we took great pains to hide the intricacies and preserve the simplicity and intuitive nature of NCSA Mosaic," explained Schiffman. Any user that is familiar with NCSA Mosaic should be able to understand and use the software's new security features. Immediately to the left of NCSA's familiar spinning globe icon, a second icon has been inserted that is designed to resemble a piece of yellow paper. When a document is signed, a red seal appears at the bottom of the paper, which the user can click on to see the public key certificates of the signer and issuing agencies. When an arriving document is encrypted, the paper folds into a closed envelope, signifying that its information is hidden from prying eyes. When the user fills out a form containing sensitive information, there is a 'secure send' button that will encrypt it prior to transmission. Distribution of Public Keys To effectively employ public-key cryptography, an infrastructure must be created to certify and standardize the usage of public key certificates. CommerceNet will certify public keys on behalf of member companies, and will also authorize third parties such as banks, public agencies, industry consortia to issue keys. Such keys will often serve as credentials, for example, identifying someone as a customer of a bank, with a guaranteed credit line. Significantly, all of the transactions involved in doing routine purchases from a catalog can be accomplished without requiring buyers to obtain public keys. Using only the server's public key, the buyer can authenticate the identity of the seller, and transmit credit card information securely by encrypting it under the seller's public key. Because there are far fewer servers than clients, public key administration issues are greatly simplified. Easy Access to Strong Security To successfully combine simplicity of operation and key administration functions with a high level of security that can be accessible to even non-sophisticated users, significant changes were necessary for existing WWW security protocols. EIT developed a new protocol called Secure-HTTP for dealing with a full range of modern cryptographic algorithms and systems in the Web. Secure-HTTP enables incorporation of a variety of cryptographic standards, including, but not limited to, RSA's PKCS-7, and Internet Privacy Enhanced Mail (PEM), and supports maximal interoperation between clients and servers using different cryptographic algorithms. Cryptosystem and signature system interoperation is particularly useful between U.S. residents and non-U.S. residents, where the non-U.S. residents may have to use weaker 40-bit keys in conjunction with RSA's RC2 (TM) and RC4 (TM) variable keysize ciphers. EIT intends to publish Secure-HTTP as an Internet standard, and work with others in the WWW community to create a standard that will encourage using the Web for a wide variety of commercial transactions. Availability EIT will make Secure NCSA Mosaic software available at no charge to CommerceNet members in September and NCSA will incorporate these secure features in future NCSA Mosaic releases. Enterprise Integration Technologies Corp., of Palo Alto, Calif., (EIT) is an R&D and consulting organization, developing software and services that help companies do business on the Internet. EIT is also project manager of CommerceNet. The National Center for Supercomputer Applications (NCSA), developer of the Mosaic hypermedia browser based at the University of Illinois in Champaign, Ill., is pursuing a wide variety of software projects aimed at making the Internet more useful and easier to use. RSA Data Security, Inc., Redwood City, Calif., invented Public Key Cryptography and performs basic research and development in the cryptographic sciences. RSA markets software that facilitates the integration of their technology into applications. Information on Secure NCSA Mosaic can be obtained by sending e-mail to shttp-info(a)eit.com. Press Contact: Nancy Teater Hamilton Communications Phone: (415) 321-0252 Fax: (415) 327-4660 Internet: nrt(a)hamilton.com

1 0

Re: 15 out of 16 times (math, not laundry)
by collins＠newton.apple.com 17 Dec '03

17 Dec '03

>Actually, the casinos win in Las Vegas because the odds of almost >every bet are in their favor. In most cases the odds favor the house---I never claimed otherwise---and that certainly speeds up the inevitable process of cash extraction. >Larger capital allows you to affect the distribution of winnings, but >not whether or not the underlying bet is a good one. If the difference in bankrolls exceeds a tolerance related to the `odds', the quality of the bet is immaterial. The direct implication of the weak law of large numbers is: a) the longer you play, the more certain you will experience a `run of bad luck'; b) the party with less money goes broke waiting for their `run of bad luck' to end. When one part goes broke, the game is over, even if the distribution of winnings does not match the theoretical expectations (and in the case of going broke, it can't ... or you wouldn't have played). >Every casino, in effect, takes on the whole world. As all the bets >are independent, it doesn't matter if they are played by one player or >by a new player every time. The world has much more capital. Yet the >casinos consistently win. No. The whole world doesn't go broke as a unit. Individuals stop playing, leaving their money in an unexpected distribution, when they _personally_ go broke. In fact, most gambling decisions are related in some way to cash resources of the participants. For example, I propose a hypothetical game where you (the player) flip a fair coin. If it comes up heads on the first toss, I pay you $2; game over. If it comes up heads on the second, I pay you $4; game over. $8, $16... How much would you pay me (the house) to play this game? The theoretical value is infinite; you could win any amount of money at this game -- 1/2 the time $2 dollars, 1/4 of the time $4, 1/8 of the time $8... expectations = Sum_{n \goesto \infty}{n \over n}. Let's say I'm an actual casino, and could reasonably pay out winnings up to but not beyond $4.3 billion. You should pay no more $33 for a chance at that money. Derivation as an exercise for the reader. Consider this from the perspective of the house. The house is using the Martingale system against you, doubling its bet every time it loses until it gets that $33. That means that to launder $33, one party could conceivably lose $4.3billion. Obviously no mathematicians work at my casino. They all left to persue jobs that ensure a paycheck. These are _not_ my personal conclusions. This is sound, if disturbing, probability theory---known for at least 250 years. This particular effect goes by many names including "Gambler's Ruin". Given the odds, and the respective bankrolls, you can calculate the probability that any given party will go broke in extended play. The problem of "Duration of Play" was solved by Bernoulli and published posthumously in 1713. Scott Collins | "That's not fair!" -- Sarah | "You say that so often. I wonder what your basis 408.862.0540 | for comparison is." -- Goblin King ................|.................................................... BUSINESS. fax:974.6094 R254(IL5-2N) collins(a)newton.apple.com Apple Computer, Inc. 5 Infinite Loop, MS 305-2D Cupertino, CA 95014 ..................................................................... PERSONAL. 408.257.1746 1024:669687 catalyst(a)netcom.com

2 1

Re: my remailer taking some (mild) heat [LONG]
by Halvor Kise jr. 17 Dec '03

17 Dec '03

This is disturbing news! I'm sorry for any spelling errors here. Please read on! > ##### I responded:: ##### > > Brad, > > # I included his initial message here > > This is distressing to me. I don't run a remailer to abet infringers of > copy (or other) rights. I certainly do not condone this action. > Unfortunately, there is little I can do after the fact. My remailer is not > the sort that requires a priori relationships. If a message has the right > sort of header, the remailer sends it on its way ... no questions asked. I > never see any mail that passes through my remailer. I keep no logs, the > efficacy of which would be compromised in any case by remailer chaining or > encryption. I can block remailing to or from any particular address, but > my remailer is incapable of taking action based on content. I am sorry > that I can neither tell you who it was, nor contact them ... not because I > don't wish to, but because I am unable to. Would this guy told Brad if he could? I'll newer use that remailer again! > I will happily assist you in any way that I am able. What follows is my > public policy with respect to the remailer. It details my capabilities and > attitude. [....] > ##### Brad Templeton wrote:: ##### > > I understand your policy, and I suspect that down the road that while > anon remailers will continue to exist and serve a purpose, those that allow > people to break laws behind them (defamation and copyright, and possibly > kiddie-porn in particular) will have to shut down. I think appinions change from here you live. I live kind of close up to Russia (Live in Norway). Norway is a sosialistic(?) country and we actually had the World War II here, so we have felt, and can see what the freedom of speach is. So Imagine that I am an Albanian citisen(?) and have some disturbing news about the Albanian goverment. I post this news to the world through this remailer. Wouldn't I be breaking a law by doing this? Yes, I would! Use your brains! Wouldn't this news be of importance for the world? And to you trigger-happy americans: What if the news about the invasion of Quwait came from Iraq trough an anon remailer? Wasn't that of "importance for the world"?? Or did you americans loose so many lives for nothing? The world is at war! And I would allow nearly any action to distribute information! Eaven if this means that sombody is using my remailer to break the law by distributing copyrighted information. [....] > > I think the right answer is a remailer that logs, allows replies (like > the finet one) and which opens up in the case of illegal postings, or > any other postings that don't follow its rules. It might say that > it demands a warrant, for example. Ok, if the police come and wake my up an morning with an warrant, they might still need me to get the information they are looking for. (I like encryption!) If the warrant was about kiddy-porn I might give the police what they wanted, but not before I saw the warrant! If they wanted some politicaly mail from Russia/Albania I would rather low-level formated my harddisk! This Brad-person didn't bring a warrant! So I would have told him to put his nose somhere else! Sorry but my world is black an white (At least a norwegian saying!) Look at the Subject again. "my remailer taking some (mild) heat" If you dont know how to handle the mild heat, how would you handle the glowing heat? I'm sorry if this was a little to hard on some of you, but this is my appinion. Regards, Halvor Kise jr. (which is putting an remailer up soon) -- * MEMENTO MORI * _____________________________________________________ | Halvor Kise jr. * halvork(a)sofus.dhhalden.no | | * halvork(a)gyda.dhhalden.no | | Ostfold * halvork(a)frodo.dhhalden.no | | Regional College * Student at | | N-1757 Halden * Computer Science | | * | | | | Finger halvork@sofus for PGP-key | -----------------------------------------------------

2 1

Money Laundering thru roulette
by rees＠cs.bu.edu 17 Dec '03

17 Dec '03

In the book I mentioned earlier, "Th Eudamonic Pie", it mentions a scheme by which a person can always break even while playing roulette. Seems to me that this is exactly what is asked for. If anyone wants it, I'll type in the appropriate portion and send it to the list. --Dave

1 0

how do i do this with pgp?
by Erich von Hollander 17 Dec '03

17 Dec '03

i'm writing a lot of perl scripts that need to interact with pgp. however, i have not found an easy way of getting a passphrase to pgp from a script. i realize of course that this is for security; pgp only wants things typed in from a keyboard. however, there are plenty of times when automated processing is desired, and security of the key does not need to be perfect. in these cases, the only way (it seems to me) to get pgp to work is to setenv PGPPASS, which is really terrible security. is there a better way to do this? will there be some easier way in future versions of pgp, like being able to read the passphrase from stdin? e

2 1