December 2003 - cypherpunks-legacy

Re: DON'T Nuke Singapore Back into the Stone Age
by Duncan Frissell 17 Dec '03

17 Dec '03

At 07:06 AM 9/2/96 +0800, James Seng wrote: >that). I have a long argument with this person, telling him that despite >what they have done, i could still access to those stuff which they ban. >his reasoning is "how many people can do it? 10%? 5%? That's fine with us. >If the people really wans it, they can get it". The flaw with this view is that it is no harder to deploy software that defeats Singapore's proxy than it is to establish a tcp/ip connection in the first place. For civilians (such as myself) establishing a tcp/ip connection is as hard or as easy as establishing an encrypted tcp/ip tunnel to defeat government control efforts. For both these tasks, I am dependent on software writers who know more than I do. Since the software of the Net is written by people not governments, the governments will find it hard to hold "free users" down to a 5% or 10% figure. The Net is nothing more than the software that it runs on and we (not governments) write the software. In addition, we are not imposing our ideology on Singapore. If Singapore changes, it will be because an encounter with the realities of the free flow of information changes it. DCF

3 2

"Always make new mistakes"
by liberty＠gate.net 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Esther Dyson sigfiled: ... > Esther Dyson Always make new mistakes! OK, but must we always be trying to make the same *old* ones, only in a new medium? <sigh> At least there's still EPIC (for now, I'm wondering when _they_ decide to cave?). I'm feeling pessimistic. JMR Regards, Jim Ray -- DNRC Minister of Encryption Advocacy & Weekend Winsock Wemailer Opewator. "Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech." -- Benjamin Franklin Defeat the Duopoly! Stop the Browne-out! Harry Browne for President. Jo Jorgensen for Vice-president. http://www.HarryBrowne96.org/ http://www.twr.com/stbo ___________________________________________________________________ PGP id.E9BD6D35 51 5D A2 C3 92 2C 56 BE 53 2D 9C A1 B3 50 C9 C8 <mailto:liberty@gate.net> http://www.shopmiami.com/prs/jimray ___________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMirUhG1lp8bpvW01AQHR3QQAl9EvaUOCHnTZ0eyIa+kv41fXDJMsOC0v BUGKvnz3rfVxRTS3JiHALB93Kc1F+kSjoOd7ftM42Pod4bsreSAHJ0CInJ2Q8iYS r7Y2/opiY139YonF4WsD6IPTMA2Hfip9t8EACu0v2jIvxSCBqwa84WVrAxCijS9t qfKK8d3Xw9g= =6tBV -----END PGP SIGNATURE-----

1 0

The AI-who???
by Robert Hettinga 17 Dec '03

17 Dec '03

An admittedly leftist interpretation of recent Alaskan electorial events, for those fans of the Alaskan Independance Party... Cheers, Bob Hettinga --- begin forwarded text From: sxaeg(a)aurora.alaska.edu (GREENWALT ART E) (by way of rah(a)shipwright.com (Robert A. Hettinga)) To: rah(a)shipwright.com Subject: The AI-who??? Organization: University of Alaska Fairbanks Path: news-central.tiac.net!news-in.tiac.net!uunet!in3.uu.net!brighton.openmarket.com!decwrl!news.alaska.edu!aurora.alaska.edu!sxaeg Newsgroups: alt.culture.alaska Date: 29 Aug 1996 01:07:38 GMT Lines: 35 NNTP-Posting-Host: aurora.alaska.edu X-Newsreader: TIN [version 1.2 PL2] X-Newsreader: Yet Another NewsWatcher 2.1.2 Okay, okay...I know everyone has been sitting on the edge of their privy seats wondering how the Rent-A-Party (aka "The Sub-Arctic Titanic of Politics") fared in the recent primaries here in the Interior, so here goes. Now, keep something in mind as you read these results: the Interior is the heart of the Rent-A-Party. Der Fuhrer Vogel "graced" us with his presence and as the infirmities of advancing age took their toll, he devised the party back in the mid-70's here in the Interior. So...you should think the bastion, the stronghold, Yea, Brethren and Sistren!, the very for-r-r-r-rtress of AIP-ity would be...the INTERIOR! Amen! The AIP fielded 1 candidate here on the Fairbanks ballots: Paul Chizmar. He finished last. Indeed, surpassing even the last performance of the party when they dropped from their 1990 high of 39% of the vote to their 1994 basement 13% of the vote, we now see them seeking subterranean levels as their sole candidate on the entire ballot received *barely* 11% of the vote! Right here! In the Interior! Just about 15 miles from Lynette and Dexter Clarke, the penultimate-Grand Poobahs of Das Partie! Tsk.... I tell ya, folks...I love to watch "Rocky and Bullwinkle", "Monty Python", "The 3 Stooges", the "Little Rascals", etc. But when the AIP finally dwindles/splinters/transmogrifies into its final bit of light and then that little glimmer goes out....I will have lost one of my greatest sources of amusement Alaska has ever offered me. Sigh.... .....Art, who will just have to watch more 3 Stooges and see if he can tell which one is Joe... --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "'Bart Bucks' are not legal tender." -- Punishment, 100 times on a chalkboard, for Bart Simpson The e$ Home Page: http://www.vmeng.com/rah/

1 0

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post reord"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"ecafe"} = "<cpunk(a)remail.ecafe.org> cpunk mix"; $remailer{"amnesia"} = "<amnesia(a)chardos.connix.com> cpunk mix pgp hash latent cut ksub"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{'nymrod'} = '<nymrod(a)nym.jpunix.com> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk pgp hash latent cut ek"; $remailer{"nemesis"} = "<remailer(a)meaning.com> cpunk pgp hash latent cut"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"vegas"} = "<remailer(a)vegas.gateway.com> cpunk pgp hash latent cut"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk mix pgp hash latent cut ek"; $remailer{"ncognito"} = "<ncognito(a)rigel.cyberpass.net> mix cpunk pgp hash latent"; $remailer{"lucifer"} = "<lucifer(a)dhp.com> cpunk mix pgp hash latent cut ek"; $remailer{"jam"} = "<remailer(a)cypherpunks.ca> cpunk mix pgp hash latent cut ek"; $remailer{"winsock"} = "<winsock(a)c2.org> cpunk pgp hash cut ksub reord"; $remailer{'nym'} = '<config(a)nym.alias.net> newnym pgp'; $remailer{"balls"} = "<remailer(a)huge.cajones.com> cpunk pgp hash latent cut ek"; $remailer{"squirrel"} = "<mix(a)squirrel.owl.de> cpunk mix pgp hash latent cut ek"; $remailer{"middle"} = "<middleman(a)jpunix.com> cpunk mix pgp hash middle latent cut ek reord"; $remailer{'cyber'} = '<alias(a)alias.cyberpass.net> alpha pgp'; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. Groups of remailers sharing a machine or operator: (cyber mix) The alpha and nymrod nymservers are down due to abuse. However, you can use the cyber nymserver. The nym.alias.net server will be listed soon. See http://www.cs.berkeley.edu/~raph/n.a.n.html for details. 403 Permission denied errors have been caused by a flaky disk on the Berkeley WWW server. Hopefully, this is fixed by now. The penet remailer is closed. Last update: Mon 2 Sep 96 6:45:14 PDT remailer email address history latency uptime ----------------------------------------------------------------------- mix mixmaster(a)remail.obscura.com -+++++-+++++ 1:38:18 99.98% jam remailer(a)cypherpunks.ca .*****-+**+* 28:42 99.98% exon remailer(a)remailer.nl.com ***--**+**** 3:33 99.98% squirrel mix(a)squirrel.owl.de +-+------.+ 2:37:06 99.96% cyber alias(a)alias.cyberpass.net +-+*+** 38:49 99.96% middle middleman(a)jpunix.com ---- --+++ 55:25 99.69% replay remailer(a)replay.com +* *-**+*** 6:15 99.36% amnesia amnesia(a)chardos.connix.com - -----+--- 3:24:36 99.35% lead mix(a)zifi.genetics.utah.edu +++--+-+++++ 48:39 99.23% winsock winsock(a)c2.org - -----+-- 5:46:31 98.94% balls remailer(a)huge.cajones.com # **-**+**** 5:32 98.70% nemesis remailer(a)meaning.com ****- ++**** 23:48 98.46% extropia remail(a)miron.vip.best.com -..------ 4:55:14 94.02% haystack haystack(a)holy.cow.net *#* ##+### 10:59 90.11% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

Re: PLEASE Nuke Singapore Back into the Stone Age
by Duncan Frissell 17 Dec '03

17 Dec '03

At 05:51 PM 9/1/96 -0700, Timothy C. May wrote: >Who says this has anything to do with "American ideology"? The Usenet is >propagated around the world. All we are saying is that honest commentary on >the corruption of Lee Kwan Yew (and his billion dollars in Australian and >European banks) will be reported on the Usenet. > >This is not "imposing American ideology" on anyone. Didn't you know that TCP/IP was an attempt by American Intelligence Agencies in concert with Britain to impose Anglo-American values (free trade in goods and bits) on the poor Mittel Europeans and the followers of Confucius in the East. These sinister British-American conspirators had done so well with their earlier releases of blue jeans, Rock and Roll, and Coca Cola. TCP/IP was designed to be the final blow to Central Europe and Asia in a culture ware that has dominated this century. Pretty sneaky those Anglo Saxons. DCF "Course if Mittel Europeans and Confucians hadn't murdered 100 million people or so in the 20th century, perhaps we could feel sorry for them." (The US-UK alliance only murdered a few million mostly via mass bombing of civilians during WWII.)

1 0

Re: Los Angeles Times article on Helsingius and anon.penet.fi
by edyson＠edventure.com 17 Dec '03

17 Dec '03

At least you don't accuse me of being a Communist. For the record, I am not a tool of the CIA nor have they pressured me, but there's no reason for you to believe me. Esther Dyson At 08:23 PM 9/2/96 +1000, Julian Assange wrote: SNIP --- > >Examining in detail Dyson's interests it appears she maintains a >sizeable and long-standing interest in Eastern European technology >companies. She is also clearly very far to the right of the political >spectrum (rampant capitalist would be putting it mildly). She also speaks >Russian. I'm not saying she has been working for the CIA for the past >decade, but I would be very surprised if the CIA has not exerted quite >significant pressure (which they are easily able to do given the >location of many of Dyson's assets) in order to bring her into their >folds during that time period. > >-- >"Of all tyrannies a tyranny sincerely exercised for the good of its victims > may be the most oppressive. It may be better to live under robber barons > than under omnipotent moral busybodies, The robber baron's cruelty may > sometimes sleep, his cupidity may at some point be satiated; but those who > torment us for own good will torment us without end, for they do so with > the approval of their own conscience." - C.S. Lewis, _God in the Dock_ >+---------------------+--------------------+----------------------------------+ >|Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | >|proff(a)suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | >|proff(a)gnu.ai.mit.edu | FAX +61-3-98199066 | 0619737CCC143F6DEA73E27378933690 | >+---------------------+--------------------+----------------------------------+ > Esther Dyson Always make new mistakes! EDventure Holdings <edyson(a)edventure.com> 1 (212) 924-8800 1 (212) 924-0240 fax 104 Fifth Avenue New York, NY 10011 USA www.edventure.com High-Tech Forum in Lisbon, October 27-29, 1996 PC Forum in Tucson, Arizona, March 23-26, 1997

3 2

Terrible story on crypto in InfoWorld
by C Matthew Curtin 17 Dec '03

17 Dec '03

There's a story covering crypto in this weeks' InfoWorld Electric. Since it's a members-only thing, I'll include the text here, as well as my response to it. I'm hoping that they'll take the article down and take up my offer to provide a better replacement. I suspect that the problem here is that someone was given a subject and a deadline, and told to "go for it." The requisite background for getting clued on crypto is probably significantly longer than the amount of time allowed by the deadline. I suspect that the issue was further clouded by the crypto-clued people she talked to during the research speaking directly about what they're doing, without giving any sort of analogies to make the ideas click and make sense. I hope that my illustration of the bicycle lock serves to clear up the confusion... In any event, we've all got a lot of work to do. I think we should take it upon ourselves to not only talk about crypto and why it's such a Good Thing(tm), but also to *educate* people to help them understand what in the world we're talking about. -matt ------------------------ begin silly article ------------------------- [Image] [PageOne] [Search] [Reader Service] [Ads Services] [Overview Map] [Todays News Logo] [Opinions] [Forums] [Test Center] [Calendar] [This Week In Print[Week In Review] Encryption technology can help secure private data over public carriers, but tackling its own issues is another story By Julie Bort InfoWorld Electric Think about this: Every time one of your end-users sends an electronic communication from your network, it opens the door to an attack. It is unbelievably easy for a knowledgeable hacker to exploit the failings of SMTP and other communications protocols to eavesdrop on Internet e-mail, send phony messages, or even gain access to other networked systems, security consultants say. A domain name or single IP address is the only information needed, and from there the door is wide open for other mischief. One increasingly popular way to plug this gaping hole is to encrypt e-mail and other electronic communications. Encryption is a way to encode text using complex mathematical algorithms. "When explaining encryption, I like to use the analogy of the Cap'n Crunch Super Secret Decoder Rings. These rings [distributed in Cap'n Crunch cereal boxes in the 1960s] contained a very simple algorithm. It was something like `take a letter then add 5.' So an A became an F. Simply speaking, that's all these algorithms are, mathematical formulas," explains Gary Fresen, a member of the American Bar Association's committee on digital signatures and an attorney and partner at Baker McKenzie LLP, in Chicago, one of the world's largest law firms. Although no encryption algorithm is in and of itself crack-proof, several of them are so complex that they are virtually unbreakable. Coupled with proper implementation, authentication, and secure connections, encryption solutions can add a high level of security to any company's arsenal. However, it is an area that requires a knowledgeable person to make the purchasing decision because the technology is very complex, the best product selected will add a level of administration overhead, and numerous industry consortiums are developing competing APIs. NUMEROUS USES. Is encryption security overkill? Absolutely not, say users who have already adopted it or are in the processing of adopting it. One reason is to gain some security control over public telecommunications lines used in wide area networks. "We have a good idea of our internal security, but we also use the public carriers for our worldwide WAN, such as CompuServe [Inc.'s] frame relay and British Telecom [Plc.'s] frame relay, and we [don't control] their level of security," says Richard Perlotto, corporate network security manager for VLSI Technology Inc., in Tempe, Ariz. "Even if you own most of your own equipment, with frame relay you don't own the router, the carrier does. Frequently [the carrier has] modems attached to those routers to manage the equipment remotely," Perlotto adds. Those modems can allow hackers to tap in and grab data as it is being transmitted, without ever being detected by the company's security systems. Consequently, VLSI is currently evaluating encryption boxes and other products that sit on either end of a connection, such as NetFortress from Digital Secured Networks Technology Inc. (DSN), in Englewood Cliffs, N.J. One box encodes all traffic on the fly when it's being transmitted, and the other decodes the information upon receipt. Router vendors offer similar add-ons. Besides simply letting employees sleep better at night with the knowledge that their corporate secrets are safe, encryption technology can mean that a company can operate more efficiently and cost-effectively, users say. "Right now, we drop letters into the post office, which isn't very secure when you think about it," Fresen says. "After all, anyone could look at them. Or we send a courier. But if we can secure our [Lotus Development Corp.] cc:Mail system, there's a tremendous cost savings to us compared to sending a courier to Hong Kong three times a day. And we'll be able to do things in a day that used to take a week." Fresen is currently testing Entrust 2.0 from Northern Telecom Ltd. (NorTel), in Research Triangle Park, N.C., as an encryption add-on to e-mail. GETTING KEYED IN. But before you can go out and purchase an encryption system, you need to do some serious homework. Encryption involves multiple technologies, competing protocols, and complex mathematics. You can start the learning process by understanding the two components that make up most encryption systems: the key and the certificate. The key is the algorithm or mathematical formula that encodes the message itself. It must be sent to the message recipient so the message can be decoded, hence the term key. The size of the key, measured in bits, determines how complex the algorithm is and how tough the code is to crack. The state of the art for encryption technology used exclusively within the United States is 1,024 bits. However, the maximum size key that is allowed to be exported is 40 bits. Keys come in two flavors: symmetrical, or public key model; and asymmetrical, or public key/private key model. A symmetrical key uses the same algorithm to encode and decode a message. This is the technique used by the public key encryption program Pretty Good Privacy (PGP). PGP assumes what security experts call the peer trust model. That is, the sender knows and trusts the receiver and is therefore perfectly comfortable in sending the key on its way. Herein lies the "pretty good" part of the privacy. Although the algorithm itself makes the message difficult to crack, the key exchange is only pretty good when compared with other methods. On the other hand, the great advantage to PGP is that it creates no key management overhead, which is the biggest drawback of asymmetrical keys. In the asymmetrical model, users have a public key stored somewhere that is available. Should someone want to send an encrypted message, the sender locates the public key of the recipient, encodes the message, and sends it off. The receiver then uses a private key to decode the message. The private key is different from the public key, but they are mathematically linked so that the private key is capable of decoding the message. Asymmetrical systems require no trust between the sender and the recipient. That's good. But they do create administration overhead in the form of storing and maintaining public and private keys. Public/private key exchange is the technique used by RSA Data Security Inc., which was recently sold to Security Dynamics Inc., in Bedford, Mass. RSA uses a technology that is actually an adaptation of the decade-old National Institute of Standards and Technology's peer-trust Data Encryption Standard (DES), still used in many products. DES is a method of grabbing random keys for each encryption task, rather than using the same key repeatedly. Cryptographers say that RSA solves some problems, such as the trust issue but generates others. "Say I want to send a secure message. The first thing I do is take a random key and encrypt the message with it," says Paul Kocher, an independent cryptography consultant in Menlo Park, Calif., and one of the people responsible for discovering the flaw in the security of Netscape Communication Corp.'s Netscape Navigator. "But without that key, I won't know how to decode [the message], so I take an RSA public key and encrypt the random DES key with my recipient's public key. The recipient uses a private RSA key to decrypt the DES key. If it sounds convoluted, it is. RSA is very slow and cumbersome. DES is fast and efficient, but it doesn't give you the security of the public/private key system," Kocher explains. RSA remains one of the most well-known encryption technologies, but it is not, by far, the only public/private key exchange method currently in use. For example, other vendors use a competing version called Diffie-Hellman. It is a mathematically different implementation of the asymmetrical model, and it is the method employed by DSN's NetFortress. THE REAL YOU. Using public or public and private keys is the foundation of encryption, but keys can't verify a recipient's identity. "When you're talking about sending secured messages, there are two goals you've got. One is to make sure that the information stays confidential, and the other is that it does not get tampered with," Kocher says. Enter the certificate, also called the digital signature. Certificates act like an electronic driver's license. They authenticate that the receivers and senders are who they say they are. "The issue is trust. When we owned our own 3270 cabling, we trusted it, we worried less. Now I have someone at Daytona Co. that needs access to Chrysler Corp. across multiple networks. What sort of trust do I have?" asks Bob Maskowitz, technical support specialist for Chrysler, in Detroit, and a member of the Internet Architecture Board of the Internet Engineering Task Force (IETF). "I need to authenticate that this person is allowed to update [a document]." Certificates can be created and managed by a third party, such as VeriSign Inc., in Mountain View, Calif., or they can be created and managed internally, with products such as NorTel's Entrust, which also performs encryption. Once a certificate is obtained, it becomes the user's digital signature. When digitally signing something, the recipient of the signature gets all of the information contained on the certificate, such as who the person is, the person's address, or other items chosen to be included on the certificate. The digital signature also says who granted the certificate, when it expires, and what level of verification was done. "There are three classes of certificates," explains Gina Jorasch, director of product marketing for VeriSign. "In Class 1, we check for a unique name, that the e-mail address is correct, and that the person receiving it has authority to access that e-mail account. In Class 2, we check the name, address, driver's license, social security number, and date of birth. For a Class 3 we check all of those things, plus we check against the Equifax [credit reporting bureau] database." Although certificates provide the invaluable service of authenticating users, organizations that care enough about their security to use encryption and certificates may not want to trust an outsider to handle them, according to users. "Do you think Ford [Motor Co.] or Chrysler is going to let someone else control their certificates? Then there is this issue of where did you get your certificate from? Am I going to let you query my database to get a key? No way," Maskowitz says. From a network management perspective, certificates are also an issue. Unless they are outsourced, they will add a significant amount of system management overhead to an encryption system, even with systems such as Entrust that include management features. Most certificates are set to expire in a set amount of time, such as a year. Someone will have to see that they get reissued. Someone will also have to make sure that certificates for employees who leave a company are revoked and that new employee certificates are issued. SMIME'S THE WORD. The final area of concern IS managers face is the new wave of protocols being spewed out by various industry consortiums. Numerous APIs are being created that cover all the aspects of using encryption. Although these APIs are posing as standards, in truth the two most popular APIs for the commercial sector are merely vehicles for the mass adoption of a particular company's key technology. Nevertheless, vendors of products such as e-mail packages are lining up behind them. The four big protocols being worked on are Secure Multipurpose Internet Mail Extensions (SMIME), Multipart Object Security Standard (MOSS), the next-generation version of PGP that allows asymmetrical key exchange, and Message Security Protocol, says Rik Drummond, chairman of the IETF's electronic data interchange over the Internet committee and president of The Drummond Group, a consultancy in Fort Worth, Texas, that helps corporations choose and implement networking and security systems. MOSS is the API for the Department of Defense, and it will be mandatory for anyone in the government or anyone who does business with it. But commercially, SMIME and PGP, Version 3.0, are more robust choices, Drummond says, and they offer features best-suited for the commercial sector, such as backward compatibility, and better key and certificate management capabilities. By far the biggest names in the Internet world have lined up behind SMIME, including Microsoft Corp., which intends to make Microsoft Exchange SMIME-compliant; Netscape; and Qualcomm Inc., maker of the Eudora e-mail package. That makes it a comforting set of protocols to choose because corporations that buy products with SMIME or that purchase SMIME toolkits for customer applications will know that they will be able to communicate with the vast majority of others through a de facto standard. Those using other protocols will be left talking to themselves. Still, SMIME, as it stands now, isn't a panacea. Among its problems is that "the signature is exposed outside the encryption envelope," Maskowitz says. Also, once a message is encrypted with someone else's public key, the sender of the message can't open the message to make changes, Maskowitz adds. The architects of SMIME haven't completed the APIs yet, so there is some possibility that these problems will be fixed but in all likelihood not in time to be included in the first crop of SMIME-compliant applications, due to start rolling out this fall. Even with such serious issues still up in the air, today's encryption and certification products can offer a great deal of protection, especially if the Internet or a wide area intranet is becoming a serious business tool for a particular organization, and it can't wait for a de facto standard to emerge. For those with the time to wait, the learning curve should be ascended now. Mass adoption of encryption technology is a virtual certainty. Those that ignore it will find their secrets being blabbed to the world. -------------------------------- Uses for encryption technology: * Sending sensitive data over publicly owned wide area links; * Sending sensitive data over Internet e-mail; * Electronic commerce; * Electronic data interchange over the Internet; * Order entry/order status over an intranet or the Internet; * Automated access to personnel files; * Storing sensitive data online; * Distribution, newsgroup style, of sensitive data. -------------------------------- Will the export of strong encryption be allowed? One of the problems with adopting encryption worldwide is that the federal government severely restricts its export. In fact, encryption technology is classified as munitions. Therefore, U.S. encryption vendors and corporations are forbidden from exporting and deploying versions that use more than a 40-bit key. However, companies in other countries, such as Japan, can freely sell encryption technology that uses the tougher 1,024-bit standard. The U.S. government isn't completely closing its eyes to the matter. In July, Vice President Al Gore unveiled a proposal that would create a key-escrow system allowing keys greater than 40 bits to be exported but requiring a third party to keep a copy of a key that could be used by law enforcement officials. (See U.S. considers easing encryption export laws.) And this past June, the Senate Subcommittee on Technology, Science, and Space heard a slew of testimony from encryption vendors and other experts on the problem. In fact, there are several bills pending in both houses of Congress that would relax the current export restrictions. The Security and Freedom Through Encryption Act was introduced in the House by Rep. Robert Goodlatte, R-Va. Meanwhile, The Encrypted Communications Privacy Act of 1996 was introduced in the Senate by Sen. Patrick Leahy, D-Vt., and the Promotion of Commerce On-Line in the Digital Era Act of 1996 also sits before the Senate. All three laws would relax the 40-bit restriction on keys as well as eliminate other restrictions on international use and development of encryption. Officials of U.S. corporations look forward to these changes and believe that such changes would improve their ability to compete in the international marketplace. "We're an international company, so we can't use the domestic version of Netscape [Communications Corp.'s Netscape Navigator]. And we can't trust the data using the international versions," says Richard Perlotto, corporate network security manager at VLSI Technology Inc., in Tempe, Ariz. Julie Bort is a free-lance writer based in Dillon, Colo. Please direct your comments to InfoWorld Electric News Editor Dana Gardner. [Image] To respond to this review, go to the forum. [Image] [Image] Copyright © 1996 InfoWorld Publishing Company ------------------------- end silly article -------------------------- --------------------------- begin response --------------------------- -----BEGIN PGP SIGNED MESSAGE----- This references http://www.infoworld.com/cgi-bin/displayStory.pl?960830.crypt.htm Hi, First of all, I'd like to commend InfoWorld for covering a very important topic: cryptography. There are, however, some very significant flaws in the story, which I hope will be corrected soon. As the article exists now, the information is sufficiently incorrect to be more harm than if the article didn't exist at all. Anyone using it as a guide will be only further confused. The quotes are indented two spaces, with my comments below... Although no encryption algorithm is in and of itself crack-proof, several of them are so complex that they are virtually unbreakable. Coupled with proper implementation, authentication, and secure connections, encryption solutions can add a high level of security to any company's arsenal. However, it is an area that requires a knowledgeable person to make the purchasing decision because the technology is very complex, the best product selected will add a level of administration overhead, and numerous industry consortiums are developing competing APIs. Also, there are a lot of people who simply don't know what they're doing when it comes to cryptography and security. Many products claim high degrees of security, but are hardly strong enough to keep someone's kid sister from deciphering the message. The key is the algorithm or mathematical formula that encodes the message itself. It must be sent to the message recipient so the message can be decoded, hence the term key. Bzzzt. The formula is the algorithm. The key is a piece of data (often times, a passphrase, or a relatively small file) that is fed to the algorithm along with the data to be encrypted or decrypted to produce the desired result. The idea being that if an attacker knows what algorithm someone is using, and they have the encrypted message, they'll not be able to break the message unless they can also get their hands on the key. Hence, the key needs to be sufficiently large such that it can't be easily guessed by an attacker trying keys at random (or by effectively starting at "1" and working his way up.) The size of the key, measured in bits, determines how complex the algorithm is and how tough the code is to crack. The state of the art for encryption technology used exclusively within the United States is 1,024 bits. However, the maximum size key that is allowed to be exported is 40 bits. Bzzzt. The complexity of the algorithm and key size are two different matters entirely. The level of complexity, by the way, typically increases the chance for error (in both algorithm design and implementation) more than adding any levels of security. A secure algorithm doesn't have to be complex. However, its key must be of sufficient length to be "computationally infeasable to break." Let's take the example of a bicycle combination lock. It has a chain which will secure the bicycle to a rack; we'll assume that it's some newfangled sort of chain which is resistant to bolt cutters and all of those sorts of things. The security of this lock now rests in the actual locking mechanism. It's a very simple tumbler lock, perhaps having three or four digits between 0 and 9 that collectively make up the combination. The "key" is the combination in this case. The lock is simple, but it can be difficult to break, if the length of the key is long enough. If there is only one digit, there are 10 possible (10**1) keys. An attacker can quickly guess this and have a new bicycle. However, each time a digit is added to the key, it increases the number of combinations an order of magnitude. Two digits will have 100 possible (10**2) keys, three digits will have 1000 (10**3), four will have 10,000 (10**4) possible, etc. The key size necessary to prevent breaking the solution will depend on your attacker. I mentioned the term "computationally infeasable" earlier. The term simply means that more time and money would need to be spent in breaking the key than the value of that which it locks. If a bike combination has 10**8 (100,000,000) possible combinations, and a thief can try 60 combinations per minute, it would take 165 weeks of continuous attempts to try every combination. By that time, enough lawns could be cut to buy two such bikes. Because computers are binary, we work in bases of two, instead of base 10, which the bicycle combination lock uses, but the principle is the same. Each time you add a digit, you increase the number of keys by an order of magnitude (in a binary system, that means you double it, in a base 10 system, you increase it 10 times.) The key size of your algorithm, therefore, must be large enough to prevent an attacker from having any benefit to recovering that which is encrypted. Keys come in two flavors: symmetrical, or public key model; and asymmetrical, or public key/private key model. Symmetric cryptosystems are sometimes known as "conventional." Asymmetric cryptosystems are known as "public key" ciphers. (Public key/private key *is* the public key model, and an asymmetric cipher!) Symmetric ciphers require the same key to encrypt and decrypt. If you imagine the encryption formula on the left side, and decryption on the right, you apply the same key to both sides in order to encrypt or retrieve the plaintext. Hence, the name "symmetric." Systems which use a different key to encrypt from the key to decrypt, therefore, are asymmetrical. The note about key sizes is also misleading: conventional cryptosystems require a much, much smaller key for security than do public key cryptosystems. Because the math is different, a 128 bit key on a conventional algorithm is roughly the same security as a 2304 bit asymmetric cipher key. The "state of the art" in symmetric cryptosystems is about 128 bits. In this type of system, the government does not allow export of keys greater than 40 bits. Using a 1024 bit key in a symmetric cipher would provide an insane level of security, but would also be very, very slow to use. A symmetrical key uses the same algorithm to encode and decode a message. This is the technique used by the public key encryption program Pretty Good Privacy (PGP). This is wrong, I will explain later. PGP assumes what security experts call the peer trust model. That is, the sender knows and trusts the receiver and is therefore perfectly comfortable in sending the key on its way. Herein lies the "pretty good" part of the privacy. Although the algorithm itself makes the message difficult to crack, the key exchange is only pretty good when compared with other methods. VERY WRONG! I'll explain this also later. On the other hand, the great advantage to PGP is that it creates no key management overhead, which is the biggest drawback of asymmetrical keys. Key management is the biggest problem for the keys of symmetric ciphers, not asymetric ciphers. In the asymmetrical model, users have a public key stored somewhere that is available. Should someone want to send an encrypted message, the sender locates the public key of the recipient, encodes the message, and sends it off. The receiver then uses a private key to decode the message. The private key is different from the public key, but they are mathematically linked so that the private key is capable of decoding the message. Entirely correct. Public/private key exchange is the technique used by RSA Data Security Inc., which was recently sold to Security Dynamics Inc., in Bedford, Mass. RSA uses a technology that is actually an adaptation of the decade-old National Institute of Standards and Technology's peer-trust Data Encryption Standard (DES), still used in many products. DES is a method of grabbing random keys for each encryption task, rather than using the same key repeatedly. Cryptographers say that RSA solves some problems, such as the trust issue but generates others. ACK! NO! RSA is an asymmetric cipher. DES is a symmetric cipher. That's the only difference. How keys are managed is entirely dependant on how the system is implemented. Anything can be assigned a key "at random," by allowing a user's passphrase to be the key. Now it seems like a good time to explain the way that PGP (and Netscape's encryption system) works. Asymmetric ciphers, such as RSA, are very slow. Their key management, however, is very nice and flexible, which is why we like to use them. In a system that requires flexible key management, a high level of security, as well as decent performance, both symmetric and asymmetric ciphers are used. If Alice wants to send Bob a message in such a system (like PGP), she simply composes her message, and tells her mailer to PGP-encrypt the message. PGP will find Bob's public key (either from her key ring, or from a database, perhaps, but it doesn't matter.) The message will then be encrypted with a random SYMMETRIC key (in the case of PGP, it will use the 128-bit-key IDEA cipher). That session key, then, will be encrypted using Bob's public key, and both the session key and message will be sent off (in one PGP encrypted message). Bob will see his mail from Alice, and then his PGP will decrypt the session key, and apply it to the encrypted message, yielding the plaintext: Alice's message. So, in PGP, the MESSAGE is encrypted using a random session key (which is symmetric.) The SESSION KEY, then, is encrypted using the recipient's public key. The rest of the article seems to be generally on track, but certificates and signatures have been confused. A certificate is a cryptographically secure message that states the identify of the presenter. In that way, the analogy to a driver's license is correct. A trusted third party issues the certificate. A digital signature, however, is the cryptographic equivalent of signing your name to something. For example, with PGP, I can digitally sign an email message. PGP does this by taking the message, encrypting it with my PRIVATE key, running the result of that through a secure one-way function ("hash"), and attaching the result to the bottom of the message. A user can then verify that the signature is legitimate by applying my PUBLIC key to the message, and running the result back through the hash, and comparing the two. If they match, the signature is good, if not, something is amiss. (PGP, naturally, handles all of this automatically.) Therefore, U.S. encryption vendors and corporations are forbidden from exporting and deploying versions that use more than a 40-bit key. However, companies in other countries, such as Japan, can freely sell encryption technology that uses the tougher 1,024-bit standard. The two are being confused again. See my earlier note about comparable keys. If you have further questions, please feel free to contact me. If there is interest, I would also be willing to write a series on how to choose a cryptosystem. I am very concerned about the state of cryptographic knowledge in the industry. The area is vital for successful companies' IS departments to understand, and understand well. Yet, the general level of knowledge is abysmally low. I applaud efforts by InfoWorld to increase coverage of this important topic, but I emphasize that the material presented must be correct. Many vendors are currently offering solutions they call secure. Without an understanding of how cryptography works, an IS organization is completely unable to choose between that which is good security and that which is snake oil. A "snake oil FAQ" is being drafted, but is not yet available. In the mean time, there are cryptography FAQs available from ftp://rtfm.mit.edu/pub/usenet-by-group/sci.crypt/ - -- C Matthew Curtin MEGASOFT, INC Chief Scientist I speak only for myself. Don't whine to anyone but me about anything I say. Hacker Security Firewall Crypto PGP Privacy Unix Perl Java Internet Intranet cmcurtin(a)research.megasoft.com http://research.megasoft.com/people/cmcurtin/ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Have you encrypted your data today? iQEVAwUBMireN36R34u/f3zNAQF+BQf/XD0fPYFuOQsd+u2k4zE1UpfZQKaP+SDw RUhx6R7LnD0ZK5dA+seStvsLl+cvg5tu2wMzf9bniS7taj2DHwmu8MDWYwJPnQST Iiti6XBAoFjCJYWaVghHQzVKw8vxlNC20LzyJ791PdabpUo5ztpf+AXVHGAfWaTg F3ZNYWbbyxg81uxAnKMM/Li6NOKJhcE6nNO+eHUMFLciFki+mz/mOT45fUPs0R9y 4UYLQDvcSVAt246xSufwqbrSY/4dUB3A7KjYvbqWUjYRF/40c1h3K6h69dDnOR/8 SY+AZNnZSzQZbMbHNpjlJ+E71Yz+9Ppvgl6Eeo7oqa+PNeYW0W9GMQ== =PS8M -----END PGP SIGNATURE----- ---------------------------- end response ---------------------------- -- C Matthew Curtin MEGASOFT, INC Chief Scientist I speak only for myself. Don't whine to anyone but me about anything I say. Hacker Security Firewall Crypto PGP Privacy Unix Perl Java Internet Intranet cmcurtin(a)research.megasoft.com http://research.megasoft.com/people/cmcurtin/

1 0

Re: free speech online
by Blake Wehlage 17 Dec '03

17 Dec '03

At 02:47 AM 9/2/96 EDT, patrick b cummings wrote: >I agree that their should be free speech on the net. Someone should >start a petition and get as many people to sign it as possible. > Patrick.... i have a deal for ya.... you don't write this list for a week? or at least keep the spams to a minimum. Post the hacker requests to a hacker-mailing list (what a concept). Have a nice day! ========================================== Blake Wehlage <jwilk(a)iglou.com> World's Youngest Cypherpunk 2400bps is the net's old people drivers

1 0

Cypherpunk Mailboxes?
by William H. Geiger III 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hi, I have a thought for addressing the anon. problem. We could create a network of anonymous remailers with mailboxes. All messages in the mailboxes are stored encrypted. No information about the users are keep. Users would be be given x K of mailbox space. We could use PGP keys for encrypting the messages. Each user would have his own key pair for his anonymous mailbox. Any plain text messages received to the server would be encrypted on recept. Let the government's subpoena away. :) "Sorry we don't have user addresses, no I can't decrypt those messages Senator." <BEG> What do you think? - -- - ----------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting WebExplorer & Java Enhanced!!! Merlin Beta Test Site - WarpServer SMP Test Site Author of PGPMR2 - PGP Front End for MR/2 Ice Look for MR/2 Tips & Rexx Scripts Get Work Place Shell for Windows!! PGP & MR/2 the only way for secure e-mail. Finger whgiii(a)amaranth.com for PGP Key and other info - ----------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMisGh49Co1n+aLhhAQHvAgP/aLktPSyoj3Ps7OnJ2LXlSIJJQq+B3GiA TlGFJ/DZVF9Ai9rKMzjgmTiukLY/+Hf58vrw7QjJA7wp/fcGOZoYNnMt0mW09wsp biUtXnMkX86sW2abtazy6U3f+DR15lGi9S2F0dvZERmFCdUX5Yi5geoa31Zezght Sj/0sFT+AUk= =7tw/ -----END PGP SIGNATURE-----

3 3

Re: Moscowchannel.com hack
by pjb＠23kgroup.com 17 Dec '03

17 Dec '03

FWIW, not even root can unmount a file system that is busy. -paul > From cypherpunks-errors(a)toad.com Sun Sep 1 18:17:12 1996 > Subject: Re: Moscowchannel.com hack > To: snow(a)smoke.suba.com (snow) > Date: Sun, 1 Sep 1996 10:09:32 -0500 (CDT) > Cc: joelm(a)eskimo.com, Cypherpunks(a)toad.com > Reply-To: ichudov(a)algebra.com (Igor Chudov) > From: ichudov(a)algebra.com (Igor Chudov @ home) > X-No-Archive: yes > Organization: Bool Sheet Software > X-Mailer: ELM [version 2.4 PL24 ME7] > Content-Type> : > text> > Sender: owner-cypherpunks(a)toad.com > Content-Length: 689 > > snow wrote: > > > > On Sat, 31 Aug 1996, Joel McNamara wrote: > > > > > Not really crypto, but related to the DOJ hack in a way. > > > > > > Moscow Channel is a pretty slick, Russian news/commentary page. Their Web > > > site was hacked and altered by someone who didn't seem to like Russians all > > > Just a matter of time before some builds a dedicated Satan type tool that > > > scans for HTTP server holes or messed up file permissions to make locating > > > potential victims easy. > > Write your web site to a CD-ROM and hard-code the base directory into the > > webserver. > > A hacker who has root can forcibly unmount the cdrom and mount another > directory on that node. Not a good solution. > > - Igor. >

2 1