December 2003 - cypherpunks-legacy

Re: Leahy bill, legalize crypto
by jamesd＠echeque.com 17 Dec '03

17 Dec '03

schlafly(a)bbs.cruzio.com wrote: > Obstruction of justice is already a crime. Why add penalties for > using encryption? Intimidate crypto users? Discourage use of > encryption? Give the feds jurisdiction over crypto matters? There are several different interpretations of the most controversial sections of the bill, it is vague and ambiguous. The only interpretation that I have seen that gives effect to the stated purposes of the bill is that if a cop is investigating a felony, he can demand your secret key, and if you refuse to give it to him, you get five years for obstruction. If the objectionable parts mean anything at all, they must *widen* the already alarmingly broad concept of "obstruction of justice". That is to say, of the many possible interpretations of this section, the only one that gives effect to the stated purposes of this legislation, delegates judicial powers to cops. > I see nothing good in this bill, except the export rule relaxation. This bill is a net loss: It gives the software companies considerably less than they thought they were getting, and violates the rights of individuals. The best bill we can hope to obtain is no bill at all. Crypto is profoundly harmful to the vested interest of Washington, and the more attention they pay to it the worse we will be: Any bill that Washington could pass is a bad bill. Any attempt to fix this bill is likely to make it worse. > >Roger --------------------------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we are. True law derives from this right, not from the arbitrary power of the omnipotent state. http://www.jim.com/jamesd/ James A. Donald jamesd(a)echeque.com

1 0

Stealth for Mac?
by Rev. Mark Grant, ULC 17 Dec '03

17 Dec '03

I've had a request from someone for a copy of Stealth that can run on a Mac (I have the README for the DOS/Unix version on my Web site). Has anyone ported it? Or if not, would anyone be able to? You should be able to just hack up a simple GUI around the main filter code to select input and output files. Mark

1 0

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

17 Dec '03

jim bell <jimbell(a)pacifier.com> > Well, okay, but we've really got to define whose key is being escrowed, > anyway. Most corporations will probably handle it themselves, OR they will > only give an ENCRYPTED escrowed key to the escrow agent. This would prevent [..] They may use secret sharing or splitting methods and handle parts by different organizations within themselves and hand other parts to an outside agent. Sometimes this makes sense when there are political rivalries within an organization. They want the ability to get into Dilbert's files if he drops dead, but they want an objective party to hold part of the key so his rivals don't try to steal his files. Rob. --- Send a blank message with the subject "send pgp-key" (not in quotes) to <WlkngOwl(a)unix.asb.com> for a copy of my PGP key.

1 0

Re: PGP reveals the key ID of the recipient of encrypted msg
by Bill Stewart 17 Dec '03

17 Dec '03

>On Mon, 11 Mar 1996 savron(a)world-net.sct.fr wrote: >> I began testing PGP a few days ago ( I'm a PGP newbie ) and I found >> that it gives out the key ID of an encrypted message . From this you >> can get the identification of the recipient of the message , if it's >> someone who has publicaly distributed his key (keyserver , homepage >> ...) . So even if you are unable to decode the message you can find >> who is the recipient of a given message . I think this is a big >> privacy problem . How much of a problem it is depends on the application you're using PGP for, but yes, it's a concern. There's a program called "stealth" by "Harry Hastur" which lets you remove or hide this information, as well as hiding most of the PGP headers. (There are some aspects of PGP file structure that are difficult to hide, at least without doing almost as much work as PGP was already doing, and I don't know if it adjusts for the mathematical properties of RSA-encrypted data which make it possible to identify the public key over some number of messages.) When the new PGP 3.0 comes out, there will be some support for shorter keyIDs (which isn't perfect, but for instance a 4-bit keyID would let you not try to decrypt 15/16ths of the messages, while not really fingering you as the recipient.) Also, if you have someone you frequently correspond with on some topic (perhaps a mailing list) and want to be able to send them messages that don't identify them, have them generate a public key they use just for that application. You can send your request by anonymous remailer, and they can send you a reply by anonymous remailer or post to alt.anonymous.messages. This still permits traffic analysis (nobody knows who keyid 0x12345678 is, but they know you sent him ten messages in the last month.) >> The problem is carried along when you encrypt a message for multiple >> recipients , you get the key IDs of all the recipients and same >> problem as above . I think something like 'blind email copy' should >> be used , because the recipients don't have to know the identity of >> each other . markm(a)voicenet.com replied: >You could just encrypt a message to different key ID's seperately, rather than >in one pass of PGP. The would have the effect of Bcc. Yep. That was the original PGP approach (i.e. "do nothing special"), and multiple-recipients were added as an efficiency measure. #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 pager 408-787-1281 # "At year's end, however, new government limits on Internet access threatened # to halt the growth of Internet use. [...] Government control of news media # generally continues to depend on self-censorship to regulate political and # social content, but the authorities also consistently penalize those who # exceed the permissable." - US government statement on China...

1 0

Re: Leahy bill, legalize crypto
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 3:18 PM 3/13/96, James A. Donald wrote: >Any crypto bill that we could realistically get out of Washington will >substantially reduce liberty. The best that we can hope for is for >Washington to forget about crypto until it is too late to stop. This is our best hope at this point: that Washington moves on to other things as the campaign heats up and forgets about crypto. One reason Washington pushed for the Wiretap Act (aka Digital Telephony) was because digital switches have made conventional methods of wiretapping and pen registers harder and harder to do. (I'm not a phone phreaker expert, as some of you no doubt are, so I don't know the details of how wiretaps were done prior to the advent of digital switches...I picture wires connected to the back of PBX systems, and I presume the ESS systems and their ilk changed this dramatically.) However--and here's the kicker!--they blew it. If you look at Louis Freeh's testimony before Congress a couple of years ago (which I did in detail, as I scanned and OCRed it for Whit Diffie, who may make it available soon) he was clearly worried about the phone system becoming so complex and "so digital" that FBI surveillance capabilities would fall behind the technology curve. So, he and his supporters (including the EFF) pushed for the Wiretap Act. (No money has yet been allocated, last I heard, so the $500 million supposedly to reimburse the telcos for providing wiretap capability, hasn't happened.) The main way they blew it is that the Wiretap Act ostensibly does not cover end-to-end encryption, especially as computers are used in place of telephones. And as Internet voice systems become widespread, especially with transparent, easy-to-use encryption (Nautilus, PGPhone, etc., in a couple of version iterations), even some goombah in Little Sicily will be able to communicate securely and essentially unbreakably. That they are realizing this, belatedly (although hints of this recognition can be found in Freeh's comments to Congress), may be why a couple of moves are occurring: - a fast-track review by the FCC to determine if "Internet voice" services are to be regulated, controlled, enacted, redacted, and impacted. (The traditional phonecos are the ones squealing most loudly, but others are expressing concern over the "anarchy" of unlicensed Internet applications.) - the Leahy Bill, which would as various analysts have noted make disclosure of keys mandatory, would protect the legitimate needs of law enforcement, blah blah blah. Speculatively, I can see something coming on the horizon. Suppose the FCC, under the Telecommuications Act, the Leahy Act (or whatever), and the Digital Telephony Act, extended to the Internet the same general restrictions on cryptography that currently apply to the airwaves? Suppose encryption is allowed, but only with key escrow? While I can think of various problems with enforcement--the very points many of us have raised over the past several years--I can also see this as having wide support. And it might pass constitutional muster (for the same reasons the FCC jurisdiction over airwaves and the ban on encryption by ham operators, got approval. Sure, I understand that Internet bandwidth is not the same as the "public airwaves," but this subtlety may not be enough to stop the parallel from being successfully drawn. Especially if the phone companies and other threatened players are pushing hard for the FCC to step in and regulate. Food for thought. --Tim May Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Commercial Key Escrow as Prerequisite to 64 bit Export
by koontz＠netapp.com 17 Dec '03

17 Dec '03

SIGNAL, March 1996, page 9: U.S Allows Firewall Export The U.S. government has approved a 56-bit data encryption standard (DES) encrypted firewall for export. The device could create a global virtual private network by encrypting the Internet protocol layer of the communications stream among firewalls. The system's manufacturer has obtained permission to exports its 56- bit, DES-encrypted firewall by incorporating a proprietary commercial key escrow recovery technology into the firewall. The U.S. govern- ment will allow the export of cryptographic products with key lengths of up to 64 bits, provided that a capability allows emergency access to encryption keys for law enforcement and national security reasons. Terms of the export license require the manufacturer, Trusted Information Systems, Incorporated, Glenwood, Maryland, to maintain a commercial key escrow data recovery center in the United STates. --- 1) Is there a market for products overseas that the U.S. government can peer through? 2) Will we ever hear what constitutes a demand for disclosure of keys for "national security reasons"? {please CC: koontz(a)netapp.com, currently not subscribed to cypherpunks}

1 0

Kid Gloves or Megaphones
by eric＠remailer.net 17 Dec '03

17 Dec '03

I've been engaged in a background discussion with some folks about how to treat a new protocol, when to speak, etc. Elements of that discussion have become relevant to the list widely. The situation is thus. Ian Goldberg et al. have developed a protocol for simultaneous payer and payee anonymity. It appears to be novel, albeit not entirely unanticipated. The protocol works with the existing bank signing oracle and could interoperate with Mark Twain's current system. The suggestion was made, paraphrasing -- couldn't we just not talk about this too loudly yet? ... NO! Perhaps the single most important lesson I've learned from cypherpunks is that code alone doesn't cut it. Not code alone, not code widely distributed, not even code widely used. Some measure of toleration in society for activities conducted in private is _necessary_ for long term success. Not convenient, not easier, but necessary. The whole Clipper situation testifies to this. Unless there is a public concensus that people generally should be able to use their own cryptography, then such use will become marginalized. Legislatures will outlaw, the public will disapprove, and vigilantes will hunt down improper use. That, in my book, means we've lost. Code is clearly still necessary. Code demonstrates what actually happens. To write code is to invoke and evoke the latent and insufficiently articulated desires for privacy in the world at large. Similarly with anonymous transactions. Unless a similar concensus exists, we will have another marginal activity. Again, I count this a loss. Backlash will result from later disclosure that the payment systems we generally as cypherpunks have undisclosed properties, that we as a loose group have dissimulated and even lied outright about the capabilities of the systems we advocate. This backlash will wipe away many gains we might have made and eliminate the possibility of future ones. The backlash will be justified, because it will be the natural result of a demonstration of bad faith. One such demonstration now, and who would know when the next was coming, or that we had not hoarded encrypted agendas all along in our hearts? And then, since we would not be believed, all the propaganda of our opponents will triumph. The Four Horsepersons will come trotting out in grand inquisitional spectacle, and there will be no counterpoint, because the devil's advocate will have been discovered to have been guilty himself. It is foolishness itself to deceive a public which is substantially in favor of the program of complete privacy. We must appeal to the public that finally will decide, not to some officials today who have power and tomorrow who will not. Clipper itself was not defeated by constructive engagement with the Clinton wiretap administration. Clipper was defeated by a general call to arms. Therefore, shout out to the world that payee anonymity is possible with ecash(TM)! Eric

1 0

The Path to Anonymity
by John Young 17 Dec '03

17 Dec '03

Thanks to anonymous and AJ the exemplary report: Privacy-enhancing Technolgies: The Path to Anonymity Registratiekamer, The Netherlands Information and Privacy Commissioner/Ontario, Canada August 1995 Volume I Volume II is available at: http://www.replay.com/mirror/privacy/ _________________________________________________________ Introduction [Excerpts] The Dutch Data Protection Authority (the Registratiekamer) and the Information and Privacy Commissioner for the Province of Ontario, Canada (IPC) are both privacy protection agencies that oversee compliance with their respective juridiction's privacy laws. The Registratiekamer and IPC decided to pool their resources and collaborate in the production of a report exploring privacy technologies that permit transactions to be conducted anonymously. The first international paper of this type includes a survey of companies that might be expected to offer such technologies, and organizations that might use them. In addition to anonymous transactions, the range of security features commercially available for use and the types of services actually being used by various organizations were also examined (see 2.1 Survey methodology). The Registratiekamer and IPC felt that a joint report outlining the practices followed in their respective jurisdictions would shed some light on this little-studied but extremely important area where the future of privacy-protection in an electronic world may lie. Consumer polls have repeatedly shown that individuals value their privacy and are concerned with its potential loss when so much of their personal information is routinely stored in computer databases, over which they have no control. Protecting one's identity goes hand in hand with preserving one's ability to remain *anonymous* -- a key component of privacy. While advances in information and communications technology have fuelled the ability of organizations to keep massive amounts of personal data, this has increasingly jeopardized the privacy of those whose information is being collected. Minimizing identifying data would restore privacy considerably, but would still permit the collection of needed information. When assessing the need for identifiable data during the course of a transaction, the key question one must start with is: how much personal information/data is truly required for the proper functioning of the information system involving this transaction? This question must also be asked at the outset -- prior to the design and development of any new system. But this is not the case today. This question is rarely asked at all since there is such a clear preference in favour of collection identifiable data, 'the more the better'. However, with the growth of networked communications and the ability to link a wide number of diverse databases electronically, people will become more and more reluctant to leave behind a trail of identifiable data. What is needed is a paradigm shift away from a 'more is better' mindset to a minimalist one. Is it possible to minimize the amount of identifiable data presently collected and stored in information systems, but still meet the needs of those collecting the information? We believe that it is. The technology needed to achieve this goal exists today. We will describe some of the privacy technologies that permit one to engage in transactions without revealing one's identity by introducing the concept of an *identity protector*. The notion of *pseudonymity* will also be introduced as an integral part of protecting one's identity. These technologies are available now and within our reach; what is needed is the will to implement privacy technologies over the tracking technologies that are in use today. When organizations are asked what measures they have in place to protect privacy, they usually point to their efforts at keeping information secure. While the use of security measures to prevent unauthorized access to personal data is a very important component of privacy, it does not equal privacy protection. The latter is a much broader concept which starts with the questioning of the initial collection of the information to ensure there is a good reason for doing so and that its uses will be restricted to legitimate ones that the data subject has been advised of. Once the data has been collected, security and confidentiality become paramount. Effective security and confidentiality will depend on the implementation of measures to create a secure environment. Alternatively, instead of restricting the focus to security alone, a more comprehensive approach would be to seek out ways in which technology may be used to enhance the protection of informational privacy or data protection. We use the term *privacy technologies* to refer to a variety of technologies that safeguard personal privacy by minimizing or eliminating the collection of identifiable data. Not only are measures that safeguard privacy becoming an important mark of quality, but increasingly, consumers are demanding that organizations pay attention to their privacy concerns. Social acceptance of demands for one's personal information, without adequate assurances of protection, appears to be on the decline. Not only do consumers wish to maintain control over their personal data and be informed of its uses, but insufficient protection will be reason enough for consumers to take their business elsewhere -- to companies that follow privacy-protective practices. -----

1 0

Re: entropy masking (was Re: Multiple spinners as sources of entropy?)
by JonWienke＠aol.com 17 Dec '03

17 Dec '03

In a message dated 96-03-13 18:35:51 EST, Matt Blaze writes: >I would go even further than this. I wouldn't trust ANY >environmentally-based random source (cycle spinner, keyboard >timer, disk noise, whatever) against adversaries on the >same system. In DOS, the keyboard, mouse, and disk drives run on interrupts, not timers. If you use a timer as a spinner, such as the Windows GetCurrentTime() function, (I MSec. resolution) and check its value each time a key is pressed and released, It would appear that the results should be quite random, because the keystroke is not processed in conjunction with the timer, but rather whenever the interrupt occurs. My tests in this area indicate that any 8 bit value can be achieved with this method, with a fairly uniform distribution. My tests are not thorough (I haven't sat down and typed for 2 hours to test the distribution of the output), but results look reasonably good so far. Jonathan Wienke

2 1

Anon email accounts available
by David K. Merriman 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Just letting folks know that shellback.com is offering anon email accounts. Price is $5/month, prepaid via cash or money order. Weekly notices starting 30 days before account expires. See our page at http://www.shellback.com/anonmail.htm (yes, we're really leaving the last 'l' off :-) Also want to let folks know that the remailer is not _yet_ functioning (saw a couple messages try to fly through while setting up the mail server). Real Soon Now. Honest. Dave Merriman -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMUbmAMVrTvyYOzAZAQEE0QP/Tg5wqn49bFVx8hwYbGP9UK3SsU7bgh+U yt6rZRrxTfIpJk01emWY6SXPL1XjCSSV8YXnukaScJdpmIJ9vRZkG1wpznNFWeER GtLP8YTdcyQxOzC7qY9UWwebweVTNjwH998x09jiUhp2wY1qkTjHqk2qMxSStZrZ 2U1IQc/BDt0= =uH+x -----END PGP SIGNATURE----- ------------------------------------------------------------- "Giving money and power to government is like giving whiskey and car keys to teenage boys." P. J. O'Rourke (b. 1947), U.S. journalist. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> http://www.shellback.com/personal/merriman/index.htm

1 0