December 2003 - cypherpunks-legacy

Public key Steganography?
by Ray Arachelian 17 Dec '03

17 Dec '03

The following are bits and pieces of a message I've sent to someone inquiring about stego... It brought back the old idea I had about expanding WNS to do public key.... Would something like this be feasable? the beginning of this is a description of what WNS does, followed by the public key idea... ---------- Forwarded message ---------- <<I am researching Steganography and related topics of a security course at George Mason University. As part of my research, I am reviewing PC products that provide such services. White Noise Storm (tm) which you developed in one such product. I am interested in the kind of research you did to develop it (publications, readings, inspiration). If you could point me to any documents I would be grateful.>> Hi there, Anyway to answer your questions, the idea of WNS came to me from the idea of spread spectrum technology and frequency hopping, however, I added several twists to it in order to improve security. Instead of just having X channels of communication which are multiplexed or changed with a fixed formula and passkey, I have eight channels which are spread within a number of 8 bits*W bytes channels. W here represents a random sized window of W bytes. Each of these eight channels represents one single bit out of a whole byte, so each Window holds one byte plus a bunch of unused bits. These channels rotate amongs themselves, for instance bit 1 might be swapped with bit 7, or all the bits may rotate positions at once. Further, these bits change location within the window on the byte level. The rules for these swaps (similar to the substitution boxes in other cyphers) are dictated not only by your passphrase - which is unlimited in length, but also by the previous window's random data. This means that if you encrypt message M with key K two times, you get two different cyphertexts, C. C1 and C2 may be different, however, decrypted with key K, both will yield the original message M. This makes cryptanalysis very hard because the same message will give you different cyphertexts each time, thus making known cyphertext atacks useless. (Of course if you don't use random numbers, but rather the LSB's in an image, the same passphrase and the same window size, you'll get the same cyphertext each time you run it - which is one of the reasons you should destroy the original picture after injecting it. More about this later.) Since the window size changes with each window, the bits both rotate among themselves, and within the data window, it is close to impossible for an attacker to guess where there is cyphertext data versus where there is random data, which bit in that cyphertext represents what bit value, and in which byte it is located in. The unused bits are actually random data when WNS is used by itself generated by either a hardware random number generator, or by your compiler's random functions which addmitedly aren't all that great. However, if you are using WNS for steganography, that random data is actually the least significant bits of your original file, be it sound, or a picture or whatever. An injector is included for the PCX format because that is a format I am most familiar with, however you may write your own for other media. The reason I'm using live data out of the file you want to hide a message in is so that the cyphertext produced by WNS closely matches the natural, native LSB's of that file. Also, WNS, when used with a large enough maximum window size will give you a very secure stego channel since it will be very hard to dected that 1 in say, 500 bits has been altered. That's a bit extreme and will waste a lot of data, but for small messages stored in very large complex, noisy files, will look very much like the original image. Another thing to throw off the attacker is that statistical fixing. If WNS writes a 1 bit over a 0 bit of an LSB file, it will look for an unused 1 bit to write a zero over. This balances the distribution of 0 and 1 bits to match that of the original file as closely as possible, so that you cannot use statistical analysis to even detect the presence of steganography, much less break it. Additionally, WNS's schema of steganography does give you a very strong advantage: your recipient does not need to have the original picture or sound in order to extract the hidden message. There is a huge concern about this since if, as some other algorithms require, your recipient needed to have the original picture, you can bet that the bad guys would also have it and compare the two and also be able to extract the message. It is a good idea for nobody to have the original image, not even you. That is, scan something in, inject your message in it, and destroy the original. If the bad guys search your hard drive and find the original picture, they can compare it to the one you've sent which contains the data, thus they are able to find out which bits WNS has changed, and possibly analyze the algorithm to see which passphrases would generate such bits, extract the passphrase and then the message. With the original pre-WNS210 version, it was possible to break an encrypted message by decoding it repeatedly with the same password while changing one bit at a time in a window so as to find out which bits WNS wrote and which were random, however this brute force method is a lot worse than most brute force methods because given a stream of bits, and an unlimited password size you have numbits^numpasswords combinations to work with - a very huge space size for bruting, even for small messages. However, this version uses not only the previous window's plain-text, but the current window's unused random data bits to form the next window, that is in a sense the algorithm is recursive. (Not that the encryption function calls itself, but rather it uses the previous window to form the next.) Keep in mind that no-one, to my knowledge has done a differential cryptanalysis or any other formal attempt to break this code. It is possible that the boys at the NSA would attempt this if they thought it was a threat to them, but I haven't seen anyone report any weaknesses in this algorithm. This is why I suggest that whatever you send with WNS be compressed and then encrypted with something like PGP first. That extra bit of entropy generated by first compressing, and then by encrypting with RSA and IDEA will increase the entropy in your cyphertext even if the LSB's from the host picture aren't all that random. Related subjects from which I was inspired to write WNS: random numbers, the sliding window protocols such as Zmodem which change their window size depending on how noisy the channel is - WNS changes the window size to improve security, not to help against noise - in fact, if you change a single byte in a WNS cyphertext, the rest of the message gets garbled completly. Spread spectrum and channel hopping radio communications, finite state machine automatons, steganography and stealth in general, etc. At the time I wrote this, I did not have any papers I used to write this code, only my own knowledge of the above topics, things I learned in school about automatons and spread spectrum, the Zmodem protocol description of DSZ, etc. I would like to sometime in the future expand WNS to use a public key system instead of a symmetric key, but I haven't yet found a feasable way to do this. As is, you'd have to know your recipient's private key in order to encrypt something to send them. If you do, it beats the whole point of public key encryption. If you use their public key, everyone has access to it, so it's a kind of a catch 22 here. Using their public key as the inital WNS key, then using an RSA encrypted block to send the session key for WNS will produce the RSA encrypted block - while this is fairly strong, RSA might have some tell-tale signs that would give away the presence of steganography in the message? I'm not sure how insecure or secure this would be, but so far it is the only idea I have. This would basically work like this: 1. pick a randomly generated session key for the IDEA cypher, call this K1 2. pick a randomly generated session key for the 2nd part of the WNS session, call this K2. 3. Use the recipient's public key Pub for an RSA or Diffie-Hillman session key exchange. 4. Encrypt Sessionkey=RSA(K1+K2,Pub) 5. Encrypt Sessionblock=WNS(Sessionkey,randomnumbers,Pub) and merge with random numbers generating a random sized block. 6. First encrypt blocks of your plaintext with idea using cyphertext1=IDEA(plaintextblock,K1) 7. Then encrypt and write cyphertext2=WNS(cyphertext1,randomnumbers,K2) to the output file. 8. Go to 6 until no more data to write. To decrypt ( you are the recipient): 1. Set the session key to your public key Pub. 2. Decrypt the start of the stegoed picture using WNS and your public key to get K1 and K2: K1+K2=WNSDecrypt(cyphertext2,Pub) -> here cyphertext2 comes from the file 3. Decrypt next block of code using cyphertext1=WNSDecrypt(cyphertext2,K2) 4. Decrypt the cyphertext1 with IDEA plaintext=IDEADecrypt(cyphertext1,K1) 5. Goto 3 until no more data. Problem is, how much does it weaken WNS to use your recipient's RSA's public key as the initial WNS key not only in terms of security, but also in terms of allowing the attacker to detect the presence of stego'ed data in your host image?

1 0

Re: Privacy Marketing
by todd＠lgt.com 17 Dec '03

17 Dec '03

> Reply to: RE>Privacy Marketing > >Nick - > >I read your well-reasoned and articulate post just after sending my own (much >less complete) one which largely contradicts your view. > >Either future is plausible. I think the key issue here is risk. The >commercial market for transaction detail exists today. Call it a mature >industry. The market for individual digital privacy has been identified at a >general level, but, as you point out, has not exactly crystallized. Call it >an embryonic industry. > >Does the former need to die in order for the latter to gain ground? Probably >not. There's a lot of mutual dependence here. Each needs the other to be >relevant - kind of a Yin/Yang thing. Depending upon how the regulatory >environment shapes up, it may be quite possible that both are thriving >businesses in the future, with transaction service providers enjoying revenue >streams from both selling data and selling anti-data (privacy). Look at >Caller ID and Caller ID Blocking services for an historical precedent. > >- Art > > >Art Hutchinson E-mail: >hutchinson(a)ncri.com >Senior Consultant Phone: (617) 654-0635 >Northeast Consulting Resources, Inc. FAX: (617) 654-0654 >One Liberty Square WWW: http://www.ncri.com >Boston, MA 02160 This dovetails into a conversation currently going on in inside the cypherpunks alias, here is a reply I posted to a query about Transaction Models, and security or anomymous status of the transaction initiator or closer. --- Snip --- >I must disagre here and side with *gasp* FC. Ughhh, Me too..., Dr. Fred scores 2 Points! >If your so called *secure* server happens to get broken into by grace of >god, you want to know at least where the attack came from. If Netscape >wants to hide internet hostnames they would to well setting up to DNS >servers, one for internal resolutions where IPs resolve to their real >hostname, and one in front of the firewall that resolves all IP's to >unkown.netscape.com. I think there are reallty two bigger conceptual issues up for bashing about here, and they are different. It is unlikely that they can be by the same protocol... They both are valid transaction models and must be met. The one - Authentication Based transactions, i.e. I am doing *stuff* from a "known" system or "authenticated channel". These transactions are based upon a level of trust that I say I am who I am and that my "tresources" are as they are protrayed to be. Clearly there is an electronic trail generated here. This is the "credit card" model. and The other, - What I now call "Unauthenicated transactions" are based upon the actual resource's being authenticated rather than myself being authenticated. ----- Hence if you follow this model to extrapolate that these two types of "environments" exist, that of "known and trusted users" and that of "unknown users, but trusted cash". They are inb and of itself what will drive the need to both collect and enforce privacy for both types of transactions. IMHO - Anything less just wont fly long term. This concept of collecting client data has to be a part of the "Known Entity" Transaction Models and relegated to stay within that context. "Unknown Entity" transaction processing will have to be made avalaiable as well with anonimity being insured as part of the process model. Todd Regards, T. S. Glassey Chief Technologist Looking Glass Technologies todd(a)lgt.com (415) 324-4318 -----BEGIN PGP SIGNATURE----- Version: 2.6 iQB1AwUBMFu5E6gNRnWhagU5AQHI+gL+Mwpcd3lAWd8FF06qcG6rnLhIYveHW71a XC7xh1T0uu8qnYX31yMp17OG28jWpKUbWec1IM9/eXOi+gInA7rKICWczV8zo9Z0 0puxjRRN7yO4KfRb3cPpk+r0p6pDg01Y =bTYb -----END PGP SIGNATURE-----

1 0

Payments FAQ
by hallam＠w3.org 17 Dec '03

17 Dec '03

Hi, Im'm getting overloaded by requests as to where various payments info happens to be. Here is the URL of an overview I produced. http://www.w3.org/hypertext/WWW/Payments/roadmap.html You can find SEPP from here and most other schemes, even Magic Money for cypherpunks afficianados. Phill

1 0

Privacy Marketing
by szabo＠netcom.com 17 Dec '03

17 Dec '03

Most Internet businesses, especially the Web software and payment systems providers, are severely underestimating the market for privacy features that is out there. Consider: * A recent general survey showed that 83% of Americans are very concerned about their privacy on the "Information Superhighway". One can expect even stronger figures from European customers, which have more first-hand experience with private data, much of it originally compiled for innocuous reasons, being used for political repression. The vast majority of our customers are concerned about privacy. * Marketing surveys on privacy that are both detailed and accurate are hard to come by, because customers who care more about their privacy tend to dislike filling out detailed forms (even if they claim to be anonymous). * Over half the BBS, and potentially the Internet, online service market is in controversial services, where customers are even more concerned about privacy than average. * Privacy, once considered merely a political issue, is now being recognized for its more important aspect, as a market differentiator and value-add. Marketers correctly recognize that government "privacy regulations" mean much less privacy for businesses if it is to be enforced, and the voters no longer expect such laws to have any teeth in the face of modern technology. That hardly means that customers are not concerned about it, as the numbers show. The alternative to regulation is market solutions. Recognize that many customers do want privacy, give them what they want, and contrast yourself to your competitor. Making visible the ways your competitor is violating their customers' privacy will become a powerful marketing strategy. This strategy was used rather timidly, and inaccurately, by AT&T against MCI, where it nevertheless had great success. (Inaccurate because all major phone companies compile lists of who calls whom, and use them for marketing as well as billing -- MCI was simply being more honest about it). Used boldly and accurately, privacy marketing has vast potential to upset competitors who rely too much on marketing data and not enough on empathy with the human customer. For an idea of what such a marketing campaign might be like, imagine combining Apple "1984" Mac ads, one of the most effective campaigns in history, with the AT&T vs. MCI campaign, to sell products and services that in fact do protect customer privacy where the competition does not. * Most Americans do _not_ participate in frequent flier and similar customer tracking programs. Many who do participate don't realize the extent to which their lifestyle is tracked, since these actions are performed on remote databases, well hidden from the customer. If customers aren't concerned about their privacy, then why the need for all the distracting gimmicks and giveaways? Why not just promote these programs straightforwardly to the customer as "Customer Tracking Programs"? A competitor who can provide a privacy protecting solution can do just that, damaging these tracking programs severely. * It is ludicrous to argue that cash transactions, which leave no identified paper trail, provide no practical privacy. In fact they prevent detailed compilation of lifestyle habits, by (a) not depending on identity to settle the transaction, (b) making identity tracking, where it occurs, a visible, separate process, and (c) making it too expensive to track identity via the payment system itself, except in extreme, very rare cases. In practice, this means that cash customers don't get their lifestyles described in detail in remote databases, while non-confidential electronic payers increasingly do. Eventually this sharp difference in outcome will feed back to the customer, greatly increasing the demand for cash over non-confidential electronic payment. * A big challenge for vendors value-adding privacy is to accurately communicate these privacy features, through both the user interface and their marketing, while debunking fraudulent claims (such as calling non-confidential payment systems "cash") and exposing the privacy violating actions of their competitors. I conclude that privacy marketing will be an important value-add for Internet commerce. It will be a terrific way to gain market share at the expense of the competition -- or to lose much of your market share, if you find yourself on the wrong end of a privacy campaign. Nick Szabo szabo(a)netcom.com

1 0

Digital Cash, Privacy, Anonymity, Double spending protection and Cheating protection
by ali＠eit.COM 17 Dec '03

17 Dec '03

Let's think out loud here for a minute... I am sending this to Cypherpunks to see if someone out there has already thought of a solution to this. Alice wants to get a file from Bob and wants to pay him $1 using some Digital Cash scheme. - Do we want Alice's identity to remain Anonymous (and Bob's too)? (Note that this means that neither party knows who the other really is. They could be using aliases to conceal their real identity.) - Do we want both Alice's & Bob's Privacy maintained in the interactions. (Note the seperation of Privacy and Anonymity with the former referring to the fact that the transaction detail is only known between the parties involved. The transaction detail includes, knowledge of what was purchased, how many, and in the ideal case between which parties! Those parties could have used an alias and therefore have remained Anonymous independent of whether their Privacy was maintained. Privacy also means more than simple confidentiality because it may involve having a merchant, for example, not maintain a database of purchasing habbits, or if it does maintain such a database, keep it to itself.) - Do we want to prevent Alice from double spending (and Bob too)? - Do we want to protect either party from cheating each other? - Do we want a self-enforcing protocol? (e.g. No need for Bob to verify the e-coins with a Bank every time.) - Do we want minimum book-keeping by each party for practical implementations? - Have I missed more? Tax, Export, etc (beyond the scope of this email ;-) The question is can all of the above requirements be achieved? AND Are they all required/desired? I know cryptography does wonders, but I ponder upon 1) the need to satisfy all the above requirements, as well as 2) the feasability of such a solution. At first glance, it appears that Anonymity and Double spending prevention are contradictory. You want to punish a double spender and you need to know their identity to do that. Also, Privacy covers a broader scope than cryptographic protocols can address (e.g. the merchant database.) Finally, to prevent/punish cheating using a third party requires the loss of both Privacy and Anonymity as the third party/judge is presented with the transaction details and asked to arbitrate. Nevermind the other requirements for now... :-) Please include me in all responses. Thanks. Ali

1 0

Re: Mark Twain Bank [good news]
by cman＠communities.com 17 Dec '03

17 Dec '03

Also note that, per a conversation w/Frank Trotter, there are no minimum balances for those wanting to just establish ECash accounts. There is also no significant operational difference between merchant and customer accounts (it's mostly a matter of fees.) Individuals can set up shops w/personal accounts. Frank seems to think that he posted an announcement to this effect to cypherpunks in the middle of the night last night. I suspect he was tired. (I'm apparently account number 10; the software should be put up for download by Marcel either tonight or tomorrow. He's apparently playing squash.)

1 0

E-mail Spy
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

The Wall Street Journal, October 25, 1995. A '90s Espionage Tale Stars Software Rivals, E-Mail Spy By Glenn Simpson Technothriller novelist Tom Clancy might have a hard time dreaming this one up. In a computer-age case of spy vs. spy, a small software firm is claiming to have uncovered an industrial espionage attempt by a much larger competitor by using a controversial e-mail program. Court documents and interviews tell a tale of intrigue, deception and twist upon twist. Not to mention the alleged involvement of a mysterious "classified government agency." The protagonist is Performix Inc., a closely held eight-year-old firm in McLean, Va., that has carved out a significant niche for itself producing Empower, a software program used for "load testing," which measures the ability of a software program to serve many users simultaneously. Every major computer manufacturer now uses Empower. Enter Mercury Interactive Corp., a $300 million publicly traded California firm that also is in the business of selling software-testing products and produces competing software called Load Runner. In June 1995, a senior Mercury Interactive official, Graham Burnette, allegedly wrote to Performix inquiring about a possible corporate alliance to develop load-testing software. Performix spurned the offer. Around the same time, a Virginia businessman named Joel Dietrich, president of an obscure company called Styx Systems, approached Performix asking to try out a version of Empower known as Empower/CS on behalf of an anonymous client. According to Performix, Mr. Dietrich said he couldn't identify the client because it was a federal government intelligence agency. On June 16 Performix granted Mr. Dietrich and Styx a short-term license to use Empower/CS. At 1:55 a.m. on Saturday, July 29, Performix received a most curious e-mail message over the Internet. The message indicated that someone who wasn't authorized to do so was trying to install Empower/CS on a large computer and examine its "source codes" -- the software's secret programming language. A feature Performix had embedded in Empower/CS automatically causes an e-mail alert to be sent to Performix whenever there are indications the software is being used improperly. The e-mail indicated the address from which it had been sent: "merc-int.com." This is the registered Internet address of Mercury Interactive. The e-mail also gave the name of the network on which someone was installing the copy of Empower/CS: "testrun.mercury." The license number of the software apparently now in Mercury Interactive's hands, the e-mail further indicated, was the license number of the copy that had been leased to Styx. While Mercury Interactive and Mr. Dietrich have disavowed any knowledge of a possible software transfer, Mercury Interactive's Mr. Burnette acknowledged in an interview that Mr. Dietrich's daughter and son-in-law work for Mercury Interactive. In mid-August, in U.S. District Court in Alexandria, Va., Performix sued Mercury Interactive, Styx and Dietrich, alleging copyright infringement, fraud, conversion, unfair competition, breach of contract and unjust enrichment. Performix alleges Mercury Interactive "acquired Empower/CS so that it could unlawfully, willfully and maliciously copy, use and/or reverse engineer Empower/CS for the purpose of improving the performance and features of existing Mercury Interactive products in an attempt to gain significant economic advantage." Mercury Interactive hasn't yet formally responded to the allegations, but Mr. Burnette denied any wrongdoing by the company. "Mercury Interactive has a very strong policy against industrial espionage," he said. "We don't do it." Mr. Dietrich's response filed with the court has raised some eyebrows. While claiming no knowledge of any transfer to Mercury, he hasn't backed away from his claim to be working for the federal government. Indeed, Mr. Dietrich is asserting that he is immune from the suit because he was acting as an agent of the U.S. government. He claims in court papers that he obtained the software on behalf of "a classified government agency." None of the parties to the case who were willing to be interviewed said they knew the identity of the agency, and Mr. Dietrich didn't respond to interview requests. However, Mr. Burnette of Mercury Interactive said: "I know that Mr. Dietrich works as a contractor for a government agency. I know it's a secret government agency, but I don't know what it is." Officials of both Mercury Interactive and Performix said the two firms have reached a tentative settlement, although they disagree on what it contains. "Everything Performix needed from a business perspective they received, including the ability to review Mercury Interactive product releases," said Performix attorney Nelson Blitz. In addition, "money will be paid to Performix under this agreement in principle." But Mr. Burnette asserted that no money would change hands. The penultimate turn: Mr. Burnette claims that Performix is eager to settle the case because it has a problem of its own. He contends that it is illegal to secretly embed in commercial software code a program that causes the customer's computer to send out e-mail. Mr. Blitz of Performix denied there was anything legally questionable about the practice and said Mercury Interactive never raised that issue in settlement negotiations. He also said the feature isn't intended to be a spycatcher. Rather, he said, it is meant solely to help clients who are improperly installing the product by alerting Performix that they need help. Empower's documentation informs customers of the feature, he added. James Haggard, president of Vasco Data Security Inc., said the purpose of such programs is ambiguous, and it would be hard to rebut Performix's claim that the feature is merely meant to serve the customer. He noted that Microsoft Corp.'s new Windows 95 software contains a program that can send Microsoft a report on the software products being used by those who sign up for its on-line service albeit only with the users' permission. While critics label it a means of economic snooping, the company says the program simply helps it assist customers. "The concept of a program calling home of its own accord" is controversial in the computer industry, said computer security expert Samuel Bellovin of Bell Labs. "People tend to get very upset when it happens," he said, because it can look as if the software maker is spying on them. The final twist: Performix last week agreed to be acquired by Pure Software Inc., a publicly held firm as large as Mercury Interactive-which now will be up against someone its own size. ----- [How many CompSecExp S. Bellovins o'BellLabs?]

2 1

Re: Welcome to cypherpunks
by sharborth＠hai-net.com 17 Dec '03

17 Dec '03

Why am I getting this when I am already subscribed to the list?????? Skip ______________________________ Reply Separator _________________________________ Subject: Welcome to cypherpunks Author: Majordomo(a)toad.com at internet Date: 25-10-95 12:17 -- Welcome to the cypherpunks mailing list! If you ever want to remove yourself from this mailing list, you can send mail to "Majordomo(a)toad.com" with the following command in the body of your email message: unsubscribe cypherpunks cypherpunks(a)toad.com Here's the general information for the list you've subscribed to, in case you don't already have it: About cypherpunks ----------------- I. Administrivia (please read, boring though it may be) The cypherpunks list is a forum for discussing personal defenses for privacy in the digital domain. It is a high volume mailing list. If you don't know how to do something, like unsubscribe, send mail to majordomo(a)toad.com and the software robot which answers that address will send you back instructions on how to do what you want. If you don't know the majordomo syntax, an empty message to this address will get you a help file, as will a command 'help' in the body. Even with all this automated help, you may still encounter problems. If you get really stuck, please feel free to contact me directly at the address I use for mailing list management: cypherpunks-owner(a)toad.com Please use this address for all mailing list management issues. Hint: if you try to unsubscribe yourself from a different account than you signed up for, it likely won't work. Log back into your old account and try again. If you no longer have access to that account, mail me at the list management address above. For other questions, my list management address is not the best place, since I don't read it every day. To reach me otherwise, send mail to eric(a)remailer.net This address is appropriate for emergencies (and wanting to get off the list is never an emergency), such as the list continuously spewing articles. Please don't send me mail to my regular mailbox asking to be removed; I'll just send you back a form letter. Do not mail to the whole list asking to be removed. It's rude. The -request address is made exactly for this purpose. To post to the whole list, send mail to cypherpunks(a)toad.com If your mail bounces repeatedly, you will be removed from the list. Nothing personal, but I have to look at all the bounce messages. There is no digest version available. There is an announcements list which is moderated and has low volume. Announcements for physical cypherpunks meetings, new software and important developments will be posted there. Mail to cypherpunks-announce-request(a)toad.com if you want to be added or removed to the announce list. All announcements also go out to the full cypherpunks list, so there is no need to subscribe to both. II. About cypherpunks The cypherpunks list is not designed for beginners, although they are welcome. If you are totally new to crypto, please get and read the crypto FAQ referenced below. This document is a good introduction, although not short. Crypto is a subtle field and a good understanding will not come without some study. Please, as a courtesy to all, do some reading to make sure that your question is not already frequently asked. There are other forums to use on the subject of cryptography. The Usenet group sci.crypt deals with technical cryptography; cypherpunks deals with technical details but slants the discussion toward their social implications. The Usenet group talk.politics.crypto, as is says, is for political theorizing, and cypherpunks gets its share of that, but cypherpunks is all pro-crypto; the debates on this list are about how to best get crypto out there. The Usenet group alt.security.pgp is a pgp-specific group, and questions about pgp as such are likely better asked there than here. Ditto for alt.security.ripem. The cypherpunks list has its very own net.loon, a fellow named L. Detweiler. The history is too long for here, but he thinks that cypherpunks are evil incarnate. If you see a densely worded rant featuring characteristic words such as "medusa", "pseudospoofing", "treachery", "poison", or "black lies", it's probably him, no matter what the From: line says. The policy is to ignore these postings. Replies have never, ever, not even once resulted in anything constructive and usually create huge flamewars on the list. Please, please, don't feed the animals. III. Resources. A. The sci.crypt FAQ anonymous ftp to rtfm.mit.edu:pub/usenet-by-group/sci.crypt The cryptography FAQ is good online intro to crypto. Very much worth reading. Last I looked, it was in ten parts. B. cypherpunks ftp site anonymous ftp to ftp.csua.berkeley.edu:pub/cypherpunks This site contains code, information, rants, and other miscellany. There is a glossary there that all new members should download and read. Also recommended for all users are Hal Finney's instructions on how to use the anonymous remailer system; the remailer sources are there for the perl-literate. C. Bruce Schneier's _Applied Cryptography_, published by Wiley This is required reading for any serious technical cypherpunk. An excellent overview of the field, it describes many of the basic algorithms and protocols with their mathematical descriptions. Some of the stuff at the edges of the scope of the book is a little incomplete, so short descriptions in here should lead to library research for the latest papers, or to the list for the current thinking. All in all, a solid and valuable book. It's even got the cypherpunks-request address. IV. Famous last words My preferred email address for list maintenance topics only is hughes(a)toad.com. All other mail, including emergency mail, should go to hughes(a)ah.com, where I read mail much more regularly. Enjoy and deploy. Eric ----------------------------------------------------------------------------- Cypherpunks assume privacy is a good thing and wish there were more of it. Cypherpunks acknowledge that those who want privacy must create it for themselves and not expect governments, corporations, or other large, faceless organizations to grant them privacy out of beneficence. Cypherpunks know that people have been creating their own privacy for centuries with whispers, envelopes, closed doors, and couriers. Cypherpunks do not seek to prevent other people from speaking about their experiences or their opinions. The most important means to the defense of privacy is encryption. To encrypt is to indicate the desire for privacy. But to encrypt with weak cryptography is to indicate not too much desire for privacy. Cypherpunks hope that all people desiring privacy will learn how best to defend it. Cypherpunks are therefore devoted to cryptography. Cypherpunks wish to learn about it, to teach it, to implement it, and to make more of it. Cypherpunks know that cryptographic protocols make social structures. Cypherpunks know how to attack a system and how to defend it. Cypherpunks know just how hard it is to make good cryptosystems. Cypherpunks love to practice. They love to play with public key cryptography. They love to play with anonymous and pseudonymous mail forwarding and delivery. They love to play with DC-nets. They love to play with secure communications of all kinds. Cypherpunks write code. They know that someone has to write code to defend privacy, and since it's their privacy, they're going to write it. Cypherpunks publish their code so that their fellow cypherpunks may practice and play with it. Cypherpunks realize that security is not built in a day and are patient with incremental progress. Cypherpunks don't care if you don't like the software they write. Cypherpunks know that software can't be destroyed. Cypherpunks know that a widely dispersed system can't be shut down. Cypherpunks will make the networks safe for privacy. [Last updated Mon Feb 21 13:18:25 1994]

1 0

ACLU Cyber-Liberties Update
by ACLUNATL＠aol.com 17 Dec '03

17 Dec '03

----------------------------------------------------------------- October 25, 1995 ACLU CYBER-LIBERTIES UPDATE A bi-weekly e-zine on cyber-liberties cases and controversies at the state and federal level. ----------------------------------------------------------------- IN THIS ISSUE: * Universities Censor Student Internet Use * Conferees Named for Federal Online Indecency Legislation * Search for Plaintiffs Continues in Suit to Challenge Online Indecency Legislation * Effect of Telco Bill on Universal Access * Conferences ----------------------------------------------------------------- STATE PAGE (Legislation/Agency/Court Cases/Issues) ----------------------------------------------------------------- * Universities Censor Student Internet Use In a knee-jerk reaction to the cyber-porn scare, many universities around the country have begun to enact policies to regulate student Internet use. The ACLU believes that university censorship of student Internet usage is inconsistent with the principles of academic freedom. In addition, state universities are required as state institutions to uphold the free speech guarantees of the First Amendment. The Internet flourished for years as primarily an academic -- and uncensored -- domain. Colleges should not now cave in to the Luddites by enacting restrictive computer usage policies. Here are a few examples of university computer usage policies that tread on cyber-liberties: * After a year-long battle that made national news, Carnegie Mellon University is expected this November to approve a policy to censor certain Usenet newsgroups on Andrew, their flagship computing system. Their decision to censor is based on fear that the university could be held criminally liable under state obscenity and harmful to minors laws for providing access to newsgroups that "might be" obscene. The administration refused to accept the suggestion of both the CMU Faculty Senate and the ACLU that the computer network be categorized as a library, which would entitle the network to an exemption from the Pennsylvania obscenity statute. * The University of Minnesota will not allow students to have "offensive" content on their web sites, or even to create links to "offensive" content elsewhere on the Internet. They have also adopted the double standard of commercial services like America Online and Prodigy -- despite U of Minn's explicit content control, student web pages must include a disclaimer that the university takes "no responsibility" for anything on the pages. * At George Mason University, the "Responsible Use of Computing" policy begins with the following statement: "The following rules are not complete; just because an action is not explicitly proscribed does not necessarily mean that it is acceptable." (One could hardly imagine a better example of ambiguity with the potential to chill protected speech.) The policy creates a Security Review Panel that investigates reports of "offensive" computer behavior. As could be predicted, the backlog of cases before this panel is already quite long. (The head of the Security Review Panel is none other than Dr. Peter Denning, husband of Dr. Dorothy Denning, infamous proponent of the Clipper Chip.) On the bright side, students and faculty groups continue to hotly oppose these policies when they arise, and have been instrumental in shaping Internet usage policies to be less inhibitive of free speech and privacy rights. The following online resources will be useful to students and faculty faced with a draconian Internet usage policy: * Report on Computers at Harvard, by the Civil Liberties Union of Harvard: _Very_ comprehensive and useful report on students' computer usage rights on Harvard's network. Included are five general principles for computer use, an application of the general principles to specific aspects of computer use, and a discussion of areas where Harvard should take immediate action to secure students' rights on the network. Available at gopher://fas-gopher.harvard.edu:70/00/.studorgs/.cluh/.computer_report * Web Site on CMU Censorship Proposal: Thorough history and database of documents on Carnegie Mellon University's battle over online censorship. Also includes information on CMU's Coalition for Academic Freedom of Expression (CAFE). See http://www.cs.cmu.edu/afs/cs/usr/kcf/www/censor/ * ACLU letter and legal analysis to CMU: send a message to infoaclu(a)aclu.org with "Letter to CMU" in the subject line. The ACLU will continue to monitor university polices that restrict online free speech and privacy rights. The ACLU urges all students and faculty to actively work for university computer usage policies that protect their rights. To inform the ACLU of a computer usage policy at your school that may violate cyber-liberties, contact Ann Beeson, ACLU, beeson(a)aclu.org. ----------------------------------------------------------------- FEDERAL PAGE (Congress/Agency/Court Cases) ----------------------------------------------------------------- * Conferees Named for Federal Online Indecency Legislation Congress recently named the official conferees to the telecommunications bill. The Senate version of the telco bill (S 652) contains the Exon Amendment, approved 84-16 by the Senate on 6/14/95. The House version of the telco bill (HR 1555) contains the Cox/Wyden Amendment (the Internet Freedom and Family Empowerment Act), approved 421-4 on 8/4/95. The House version also contains Exon-like amendments to the existing federal obscenity statute, which came out of the House Judiciary Committee and were adopted as last-minute additions through a larger Manager's Amendment on 8/4/95. The conference committee is in charge of reconciling the differences between the House and Senate versions of the telco bill, including the obviously incompatible provisions regarding online content. While more details are offered in the list below, the following facts should be highlighted: _Notable Conferees_ -Senator Exon: sponsored the Exon Amendment and launched the cyber-porn scare. -Senator Gorton: original co-sponsor of the CDA. -Representative Hyde: sponsored the inclusion of indecency amendments to the federal obscenity laws in the House telco bill. -Representatives White, Markey, Goodlatte, Fields, and Barr: spoke in favor of Cox/Wyden amendment on the House floor during the telco debate. _Some Absent Conferees_ -Members of the Senate Judiciary Committee. -Senator Leahy: sponsored the study alternative to the CDA in the Senate (Senator Leahy is a member of the Senate Judiciary Committee). -Representatives Cox & Wyden: sponsored the Cox/Wyden "Internet Freedom and Family Empowerment Act." -Senators who voted against the CDA. _Other Notable Facts_ -All the Senate conferees voted for the CDA. -All the House conferees voted for the Cox/Wyden amendment. -All the House conferees also voted for the Exon-like indecency amendments to federal obscenity laws. However, they may not have been aware of this vote because it was not a separate vote but rather a vote to approve the Manager's amendment, which contained many provisions unrelated to the censorship legislation. -Given the conferees named, it is highly likely that the House leadership, including House Speaker Newt Gingrich, will play a substantial role in the conference process. THE LIST OF CONFEREES: Conferees from the House were assigned to particular titles of the telco bill; Senate conferees have jurisdiction over all titles. The list that follows indicates the titles over which each conferee has jurisdiction, and the conferee's relevant committee status, party, and area of constituency. *Title I: Development of Competitive Telecommunications Markets (contains the Cox/Wyden amendment) Title II: Cable Communications Competitiveness Title III: Broadcast Communications Competitiveness *Title IV: Effect on Other Laws (contains the Exon Amendment and the Exon-like indecency amendments to the federal obscenity statute) Title V: Definitions Title VI: Small Business Complaint Procedure Representatives from the House: Jurisdiction over Titles I and IV (these conferees may participate in discussions to reconcile the conflicting online content provisions in the Cox/Wyden Amendment, the Exon Amendment, and the Exon-like indecency amendments to the federal obscenity statute): Representatives from the House Commerce Committee, in order of rank: Republicans: Bliley, Thomas J. (Richmond, Virginia) all titles Fields, Jack (Houston, Texas) all titles Oxley, Michael G. (northwest Ohio) all titles White, Rick (northwest Washington) all titles Barton, Joseph (Fort Worth, Texas) I, II, IV, V Hastert, J. Dennis (northeast Illinois) I, II, IV, V Klug, Scott (Madison, Wisconsin) I, III, IV, V, VI Democrats: Dingell, John D. (southeast Michigan) all titles Markey, Edward J. (northeast Massachusetts) all titles Boucher, Rick (southwest Virginia) all titles Eshoo, Anna G. (San Francisco Bay Area, California) all titles Rush, Bobby L. (Chicago, Illinois) all titles Representatives from the House Judiciary Committee, in order of rank: Republicans: Hyde, Henry J. (Chicago, Illinois) all titles Moorhead, Carlos J. (Los Angeles area, California) all titles Goodlatte, Robert W. (Western Virginia) all titles Buyer, Steve (northwest Indiana) all titles Flanagan, Michael P. (Chicago, Illinois) all titles Democrats: Conyers, John (Detroit, Michigan) all titles Schroeder, Patricia (Denver, Colorado) all titles Bryant, John (Dallas, Texas) all titles Title I only (these conferees may participate in discussions to revise the Cox/Wyden Amendment, but may not participate in discussions to reconcile the conflicting online content provisions in the Cox/Wyden Amendment, the Exon Amendment, and the Exon-like indecency amendments to the federal obscenity statute): Representatives from the House Commerce Committee, in order of rank: Republicans: Paxon, Bill (western New York) I, III Frisa, Dan (New York, New York) I, II Stearns, Cliff (northeast Florida) I, III Democrats: Brown, Sherrod (northeast Ohio) I Gordon, Bart (central Tennessee) I Lincoln, Blanche Lambert (northeast Arkansas) I Representatives from the House Judiciary Committee, in order of rank: Republicans: Gallegly, Elton (southern California) I Barr, Bob (western Georgia) I Hoke, Martin R. (northeast Ohio) I Democrats: Berman, Howard L. (Los Angeles area, California) I Scott, Robert C. (Richmond, Virginia) I Lee, Sheila Jackson (Houston, Texas) I Conferees from the Senate Commerce Committee, in order of rank (the Senate conferees have jurisdiction over all titles): Republicans: Pressler, Larry (South Dakota) Stevens, Ted (Alaska) McCain, John (Arizona) Burns, Conrad (Montana) Gorton, Slade (Washington) Lott, Trent (Mississippi) Democrats: Hollings, Ernest F. (South Carolina) Inouye, Daniel K. (Hawaii) Ford, Wendell H. (Kentucky) Exon, James J. (Nebraska) Rockefeller, John D. (West Virginia) For a copy of the online indecency amendments, send a message to infoaclu(a)aclu.org with "Online Indecency Amendments" in the subject line of the message. For more information on the legislation and what you can do to fight it, see: http://epic.org/free_speech http://www.panix.com/vtw/exon http://www.eff.org/ http://www.cdt.org/ ----------------------------------------------------------------- * Search for Plaintiffs Continues in Suit to Challenge Online Indecency Legislation As noted above, the online community should continue to urge the conference committee to remove the censorship provisions from the telco bill. At the same time, a coalition has formed to organize litigation to challenge these provisions if they are signed into law. The first step is the selection of plaintiffs. We need plaintiffs who use online networks to discuss or distribute works or art, literary classics, sex education, gay and lesbian literature, human rights reporting, abortion information, rape counseling, controversial political speech, or any other material that could be deemed "indecent" and therefore illegal under the proposed law. We received a tremendous response to our first call for plaintiffs, in the last issue of the ACLU Cyber-Liberties Update. Thanks to all the organizations who contacted us. We urge other groups to join the battle to save free speech in cyberspace. Please contact Ann Beeson at the ACLU if your organization is interested in being a plaintiff in this ground-breaking litigation that will define First Amendment rights in cyberspace. 212-944-9800 x788, beeson(a)aclu.org. ----------------------------------------------------------------- * Effect of Telco Bill on Universal Access In addition to the online censorship provisions in the telco bill, the ACLU is seriously concerned about the effect of other provisions in the bill on universal access. For more information about the effect of the telco bill on universal access and other public interest matters, see the Ad Hoc Site Against the Telecommunications Bill, co-sponsored by Center for Media Education, Computer Professionals for Social Responsibility, Consumer Federation of America, Electronic Privacy Information Center, Media Access Project, People for the American Way, and Taxpayer Assets Project, at http://www.access.digex.net:80/~cme/bill.html. ----------------------------------------------------------------- CONFERENCES ----------------------------------------------------------------- Oct 26, 5 pm: "Law in Cyberspace: Free Expression and Intellectual Property on the Internet," Georgetown University Law Center, 600 New Jersey NW, Gewirz Conference Room, Gewirz Hall. Co-sponsored by ACLU-GULC and Student Intellectual Property Law Association. Panelists include David Post (GULC Law professor and author of column on cyberspace law in American Lawyer); John Podesta (GULC professor and former senior policy advisor to President Clinton on govt information policy); and David Johnson (co-founder of the Cyberspace Law Institute, President of Lexis Counsel Connect). Nov 3, 8 pm: John Perry Barlow on "Creating Cyberculture," Kane Hall - University of Washington in Seattle. $12 ($10 students). The lecture is part of a series, co-sponsored by the ACLU of Washington, that explores the impact and implications of the technology revolution on art and culture. Other cosponsors include 911 Media Arts Center, the University of Washington's New Media Lab, and the University of Washington Technical Communications Department. Nov 16, 5 pm: Nadine Strossen (National President, ACLU) speaks on "Defending Pornography: A Feminist Perspective on New Technologies and Old-Fashioned Sex," GULC, 600 New Jersey NW, 12th Floor Ballroom, Gewirz Hall. Co-sponsored by ACLU-GULC and the Student Bar Association Speakers Fund. ----------------------------------------------------------------- ONLINE RESOURCES FROM THE ACLU ----------------------------------------------------------------- Stay tuned for news on the ACLU's world wide web site, under construction at http://www.aclu.org. In the meantime, you can retrieve ACLU documents via gopher at gopher://aclu.org:6601 (forgive the less-than-updated state of our gopher -- we've devoted all our resources to WWW construction!). If you're on America Online, check out the live chats, auditorium events, *very* active message boards, and complete news on civil liberties, at keyword ACLU. ----------------------------------------------------------------- ACLU Cyber-Liberties Update Editor: Ann Beeson (beeson(a)aclu.org) American Civil Liberties Union National Office 132 West 43rd Street New York, New York 10036 To subscribe to the ACLU Cyber-Liberties Update, send a message to infoaclu(a)aclu.org with "subscribe Cyber-Liberties Update" in the subject line of your message. To terminate your subscription, send a message to infoaclu(a)aclu.org with "unsubscribe Cyber-Liberties Update" in the subject line. For general information about the ACLU, write to infoaclu(a)aclu.org. ----------------------------------------------------------------- **PLEASE REPOST WITH HEADER INTACT**

1 0

Re: DigiCash
by szabo＠netcom.com 17 Dec '03

17 Dec '03

Darren New: > If I give you a dollar for an online newspaper and the > newspaper never gets to me, or I give you $50 for a textbook and the > textbook never shows up in the mail weeks later, who do I go to to get my > money back? This is a bad-case scenario, since it involves long delay and delivery of goods that, unlike information, have a nontrivial marginal cost to the merchant. These both give the merchant incentive to skip the delivery step. For this kind of business, there are several possibilities, none of which is mature enough to have actually been deployed yet (which is why ecash is currently aimed at small, immediately delivered goods and services). * Escrow services, which take responsibility for delivery each way (and develop a public reputation for reliably doing this). This has the value that it still allows the parties to be mutually anonymous (although additional tools are needed to actually have strongly anonymous connections, the payment/delivery protocol doesn't preclude it). * Ripped bill protocols might be able to substitute for escrows. (these are quite esoteric, but can again be hidden behind a nice metaphor). * Deal only with a jurisdictionally reachable merchant and hope the law is on your side (often not an available solution on the global Internet, but usually assumed by identified payment schemes, so it's a reasonable fallback from that point of view). For smaller transactions with rapid delivery times, complaining loudly and publicly on Usenet will soon put the business out of it. Receipts will give such complaints more credibility, and will also allow the clearing agent to credibly get involved. (Obviously in these cases anonymity is lost for a particular transaction, but unlinkability with one's unchallenged transactions remains). Finally, in a few markets the value add of confidentiality is enough to outweigh the risks for even large transactions. Nick Szabo szabo(a)netcom.com

2 1