December 2003 - cypherpunks-legacy

Misquoting and Vlad (LD?)
by Jean-Francois Avon 17 Dec '03

17 Dec '03

Here, I quote some text that is quoted frequently: > >> such is the total moral perversion of the thinking behind > >> "assassination politics". most of the adherents work from the > >> following argument, nicely summarized by JFA above: ^^^^^ > >>1. the government is corrupt > >>2. therefore, it is okay to kill people who further that > >> corruption. wow, what brilliant logic. I would appreciate if everybody would stop using that example. No threat or heinous tone here, but simply a reasonable request. I am getting tired of it. Of course, the collectivist who wrote that sentence is totally wrong because I never said such things in the context he meant them. But again, it is not everybody that followed the thread and I am fed-up of seing thoses words attributed to me. I have no problem in building my bad reputation myself. I don't like it when other do it... So, please, if ever you quote it again, put at the beginning of the paragraph: "Vlad Z. Nuri wrote:" or "Vlad Z. Nuri aka L. D(R)otweiller wrote:" Thanks and Regards. JFA DePompadour, Societe d'Importation Ltee; Limoges porcelain, silverware and crystal JFA Technologies, R&D consultants; physists, technologists and engineers. PGP keys at: http://w3.citenet.net/users/jf_avon ID# C58ADD0D : 529645E8205A8A5E F87CC86FAEFEF891 I reserve the right to post publicly any private e-mail sent to me. Unsollicited commercial e-mail will be proofread at US165 $/h Any sender of such material will be considered as to have ac- cepted the above mentionned terms.

1 0

Re: Bit tax proposal?
by Rev. Mark Grant, ULC 17 Dec '03

17 Dec '03

> All interactive digital information would be subject to the new tax. > Thus digital broadcast and digital radio (all 'one to many' broadcasts) > would be exempted from the tax. Gosh, so the TV and radio companies would get to broadcast tax-free and the rest of us would have to pay. Not like this is intended to turn the scary old Internet into the digital equivalent of the broadcast media. I'm sure that idea never even considered crossing their minds... Hmm, maybe "Cypherpunks Productions" should start broadcasting soap operas and gameshows with email and Usenet stego-ed into the low bits. Mark

1 0

Re: The Crisis with Remailers
by Matts Kallioniemi 17 Dec '03

17 Dec '03

At 17:44 1996-05-21 +0200, bryce(a)digicash.com wrote: >Matts, you don't want to do floating point for money, because >floating point doesn't give you good control of precision. Yes I do. Several major currency traders in Sweden keep all their money in 64 bit floating point storage. I think that DigiCash will go floating point (get real?) when you start doing currency. If you sell 1 DEM, you don't want to get paid in cents, you want to get paid in 10-15 decimal places. That's where the currency action is right now, and before Ecash(tm) is fully deployed we'll probably see traders going for 15-20 decimal places. Floating point is the way to do it, but are your accountants ready for it? >Keep in mind that only Ecash(tm) Mints can create Ecash(tm) >coins and choose what values the coins have. Sorry, I thought that the client created the coins and the mint just signed them. I guess I should go back to RTFAPI. Regards, Matts

3 4

CDT Policy Post 2.20 - Clinton Administration Floats Clipper III Draft
by bobpal＠cdt.org 17 Dec '03

17 Dec '03

----------------------------------------------------------------------------- _____ _____ _______ / ____| __ \__ __| ____ ___ ____ __ | | | | | | | | / __ \____ / (_)______ __ / __ \____ _____/ /_ | | | | | | | | / /_/ / __ \/ / / ___/ / / / / /_/ / __ \/ ___/ __/ | |____| |__| | | | / ____/ /_/ / / / /__/ /_/ / / ____/ /_/ (__ ) /_ \_____|_____/ |_| /_/ \____/_/_/\___/\__, / /_/ \____/____/\__/ The Center for Democracy and Technology /____/ Volume 2, Number 20 ---------------------------------------------------------------------------- A briefing on public policy issues affecting civil liberties online ---------------------------------------------------------------------------- CDT POLICY POST Volume 2, Number 20 May 22, 1996 CONTENTS: (1) Clinton Administration Floats Clipper III Key-Escrow Proposal (2) Join Sen Leahy TODAY (5/22) At HotWired to Discuss His Crypto Bill (3) Subscription Information (4) About CDT, contacting us ** This document may be redistributed freely with this banner in tact ** Excerpts may be re-posted with permission of <editor(a)cdt.org> ----------------------------------------------------------------------------- (1) CLINTON ADMINISTRATION FLOATS 'CLIPPER III' KEY ESCROW PROPOSAL The Clinton Administration Tuesday (5/21) unveiled a new encryption policy proposal which would use a government-sanctioned key certification system as an incentive to virtually impose key escrow on domestic users. The draft proposal, "Achieving Privacy, Commerce, Security and Public Safety in the Global Information Infrastructure" (already dubbed Clipper III), seeks to establish a "public key infrastructure" for encryption. Broadly speaking, a public key infrastructure would enable users to clearly identify the people they are communicating with and facilitate key management, and is widely viewed as an important component of a secure and trusted communications environment. However, the Clipper III would establish this infrastructure at a price: All users of the public key infrastructure would have to ensure government access to their encryption keys through an approved key escrow authority. A detailed analysis of the Administration's latest draft proposal is attached below. Among other concerns: * The proposal is hardly voluntary - Key-escrow would become a prerequisite for participation in the Global Information Infrastructure. * The proposal contains few guidelines for how keys would be shared with foreign governments. * The proposal encourages the collection of highly sensitive private key information. * The proposal does not address major privacy concerns such as liability for key holders, limitations on law enforcement access, audit requirements, and other concerns that many have already identified as crucial to protecting individual privacy even in a voluntary key escrow system. CDT believes that the Administration's draft proposal does not meet the privacy and security needs of Internet users or the demands of the marketplace. While the proposal represents real progress by the Administration in recognizing the importance of encryption and the value of a public key infrastructure, in reality it provides few provisions to protect individual privacy. Moreover, the Clipper III proposal, like its predecessors, continues to put law enforcement and national security concerns above the privacy and security needs of the American public. The latest Administration proposal comes in the midst of Congressional efforts to relax encryption export controls and encourage the widespread use of strong, easy-to-use encryption and prohibit the government from imposing key escrow domestically. It also comes in the wake of a letter signed by over 27 Representatives last week urging the Administration to abandon its key-escrow initiative (See CDT Policy Post 2.19) A copy of the Draft proposal is available on CDT's encryption policy web page (http://www.cdt.org/crypto) SUMMARY OF THE PROPOSAL: ------------------------ Taking a nod from the efforts currently under way through the European Commission to establish a Public Key Infrastructure (PKI) in Europe, the Clipper III seeks to establish a means of ensuring authentication and key management for Americans. Among other things, the Clipper III draft proposal: * RECOGNIZES THAT THE GOVERNMENT SHOULD NOT IMPOSE ENCRYPTION STANDARDS ON MARKET: One positive element of the new proposal is an explicit recognition of the importance of encryption and the need for private sector, as opposed to government solutions. The draft states, "Government can no longer monopolize state of the art cryptography ... It is unrealistic to believe that government can produce solutions which keep ahead of today's rapidly changing information technology". * ESTABLISHES KEY MANAGEMENT INFRASTRUCTURE: The draft proposal would create a new public key infrastructure designed to tie individuals and entities to their public keys. * RELAXES EXPORT CONTROLS FOR KEY ESCROW PRODUCTS: The new draft would continue and expand the effort started with the Clipper II proposal by allowing the export of software with 64 bit key lengths (80 bits for hardware) on the condition that products contain a key-escrow function. Keys could be escrowed in the United States or where the US has a bilateral escrow agreement. Other exports to certain markets would be considered on a case-by-case basis. * PROVIDES FOR 'SELF ESCROW' OF ENCRYPTION KEYS: Self Escrow (where a corporation or individual could become an escrow agent for its own private keys) would be permitted, though the exact conditions of and obligations are not specified in the draft. MAJOR FLAWS IN THE CLIPPER PROPOSAL RENDER IT A NON-STARTER ----------------------------------------------------------- * CLIPPER III IS NOT VOLUNTARY & MAKES KEY-ESCROW A PRECONDITION FOR PARTICIPATION IN THE GLOBAL INFORMATION INFRASTRUCTURE While the Administration deserves credit for recognizing that a trusted public key infrastructure is an important component of a workable National Encryption policy, the latest proposal attempts to use the need for a public key infrastructure as a means to impose key escrow domestically. Although the Administration has repeatedly stressed that any key-escrow initiative would be a voluntary system, the text of the latest draft directly contradicts that contention. The proposal states that in order to participate in the Global Information Infrastructure, users will need to escrow their keys; if they choose not to participate in the key infrastructure, "users cannot know with whom they are dealing on the network, or sending money too, or who signed a document, or if the document was intercepted and changed by a third party." (page 3). The proposal goes on to state: "To participate in the network a user needs a public key certificate signed by a CA [Certification Authority] which 'binds' the user's identity to their public key. One condition of obtaining a certificate is that sufficient information (e.g., private keys or other information as appropriate) has been escrowed with a certified escrow authority to allow access to a user's data or communications." (page 5) In other words, the Clipper III proposal would require individuals and businesses to use key-escrow encryption as a condition of participating in the Global Information Infrastructure. Under the proposal, an individual cannot obtain certification by a Key Certification Authority (a necessity under the Clipper III scheme) unless he or she registers with a "certified escrow authority". There is no technical or structural reason (beyond law enforcement access) why key escrow must be a component of a public key infrastructure. In fact, a robust example of a public key infrastructure exists today for exchanging PGP keys (the PGP public key server at MIT <http://www-swiss.ai.mit.edu/~bal/pks-toplev.html>). * CLIPPER III TARGETS DOMESTIC USERS While export controls have ostensibly been aimed at controlling the use of encryption by foreign users (and indirectly, at domestic users as well), the Clipper III proposal is aimed directly at the domestic use of encryption and seeks to establish a system whereby key escrow becomes a de-facto component of domestic encryption products. * RAISES MAJOR QUESTIONS WITH RESPECT TO INTERNATIONAL KEY EXCHANGE In order to work, Clipper III assumes bi-lateral agreements between the US and other countries with respect to law enforcement access to escrowed keys, who could legally be an escrow agent, and other factors. Currently no such agreements exist. Bilateral agreements also raise important privacy issues, including how to deal with releasing keys to foreign governments, particularly those without any tradition of privacy protections. Finally, a patchwork of international agreements can create problems for interoperability. The same encryption and or authentication scheme exportable to Germany or England might not be exportable to India or China in the absence of a appropriate bi-lateral agreements. * CONTAINS NO PRIVACY PROTECTIONS/RESTRICTIONS ON LAW ENFORCEMENT ACCESS TO ESCROWED KEYS: Like Clipper and Clipper II, the latest proposal does not squarely address standards for law enforcement access to escrowed keys, unauthorized disclosure of keys by escrow agents, and other privacy issues associated with key escrow. * CREATES VULNERABILITY AND INSECURITY BY ENCOURAGING STORAGE OF PRIVATE KEYS: The proposal suggests that escrow agents hold either a user's private key or "other information as appropriate". Allowing escrow agents to accumulate private keys creates severe vulnerabilities in the network. Once a private key is disclosed (either to law enforcement or to an unauthorized third party), *every* communication using that key is compromised. Although the draft does attempt to limit this concern by allowing escrow agents to hold "other information", the proposal no where specifies what that would be. NEXT STEPS ---------- Congress is currently considering legislation which would head off the Administration's efforts to encourage domestic key-escrow encryption schemes and promote the widesprad avaiability of strong, easy-to-ues encryption technologies. Several bills, including S.1726 (the Pro-CODE bill) sponsored by Senators Burns (R-MT), Leahy (D-VT), Dole (R-KS), Pressler (R-SD), Wyden (D-OR) and others, along with HR 3011, sponsored by Reps Goodlatte (R-VA), Eshoo (D-CA), Campbell (D-CA) and over 25 others are currently being considered by Congress. Both bills would relax export restrictions and prohibit the government from imposing key escrow domestically. CDT looks forward to working with Members of Congress to pass legislation that encourages the widespread availability of strong, easy-to-use encryption technologies based on marketplace, not government, standards. ----------------------------------------------------------------------- (2) JOIN SENATOR LEAHY TODAY (Wed 5/22) TO DISCUSS PRIVACY AND SECURITY ONLINE Senator Patrick Leahy (D-VT), the "Senior Senator from Cyberspace", ardent proponent of Net.Freedom and co-sponsor of 2 bills to repeal encryption export controls, will hold an online "town meeting" on Wednesday May 22 to discuss privacy and security online. DETAILS ON THE EVENT * Wednesday May 22, 4 - 5 pm ET (1 pm Pacific) on HotWired URL: http://www.hotwired.com/wiredside/ To participate, you must be a registered HotWired member (there is no charge for registration). You must also have RealAudio(tm) and a telnet application properly configured to work with your browser. Please visit http://www.hotwired.com/wiredside/ for information on how you can easily register for Hotwired and obtain RealAudio. Wednesday's town meeting is another in a series of planned events, and is part of a broader project coordinated by CDT and the Voters Telecommunications Watch (VTW) designed to bring the Internet Community into the debate and encourage members of Congress to work with the Net.community on vital Internet policy issues. Events with other members of Congress working on Internet Policy Issues are currently being planned. Please check http://www.crypto.com for announcements of future events ------------------------------------------------------------------------ (3) SUBSCRIPTION INFORMATION Be sure you are up to date on the latest public policy issues affecting civil liberties online and how they will affect you! Subscribe to the CDT Policy Post news distribution list. CDT Policy Posts, the regular news publication of the Center For Democracy and Technology, are received by more than 9,000 Internet users, industry leaders, policy makers and activists, and have become the leading source for information about critical free speech and privacy issues affecting the Internet and other interactive communications media. To subscribe to CDT's Policy Post list, send mail to policy-posts-request(a)cdt.org with a subject: subscribe policy-posts If you ever wish to remove yourself from the list, send mail to the above address with a subject of: unsubscribe policy-posts ----------------------------------------------------------------------- (4) ABOUT THE CENTER FOR DEMOCRACY AND TECHNOLOGY/CONTACTING US The Center for Democracy and Technology is a non-profit public interest organization based in Washington, DC. The Center's mission is to develop and advocate public policies that advance democratic values and constitutional civil liberties in new computer and communications technologies. Contacting us: General information: info(a)cdt.org World Wide Web: URL:http://www.cdt.org/ FTP URL:ftp://ftp.cdt.org/pub/cdt/ Snail Mail: The Center for Democracy and Technology 1634 Eye Street NW * Suite 1100 * Washington, DC 20006 (v) +1.202.637.9800 * (f) +1.202.637.0968 ----------------------------------------------------------------------- End Policy Post 2.20 5/22/96 -----------------------------------------------------------------------

1 0

Criminal Law Web Site
by AFDA2＠aol.com 17 Dec '03

17 Dec '03

The upgraded Web site for the Association of Federal Defense Attorneys (AFDA) is now available at http://www.afda.org The site provides several valuable tools for criminal defense attorneys who practice in the federal courts: (1) a convenient compilation of over 100 Web sites pertaining to federal law, including search capabilities through all the statutes and case law rulings; (2) an online newsletter that is updated weekly; (3) a message board; (4) a form library for downloading documents (we will soon begin uploading documents to the library); (4) a listing of upcoming seminars for which you can register online; (6) a feedback form so that you can give us your comments and suggestions; (7) and a survey function so that we can conduct polls within the criminal defense bar online for submission to Congress. The Web site is financed through membership dues on a non-profit basis. Until mid-June, the site will be free to all users but will then become password-protected for members only. We hope you will take advantage of this important resource and join the Association so that we can continue providing the defense bar with needed support. To join, simply click the "Join AFDA" bar on the main page of the Web site. Best regards to all. Greg Nicolaysen (Los Angeles)

1 0

Re: Another Analysis -- Re: NIST Draft Key Escrow Paper
by jim bell 17 Dec '03

17 Dec '03

At 11:35 AM 5/22/96 -0400, Joseph M. Reagle Jr. wrote: >Declan McCullagh and Gilmore have already provided a brief summary of the >doc, here are a few thoughts I sent to some others last night: [schtuff deleted] >So Clipper III is a bit meaner and leaner. If Clipper I would have sunk >because of sheer clumsiness, a sleeker ship carrying the same load will now >be developed by the free market. The load is the assumption that citizens >can be "compelled in any criminal case to be a witness against himself." I didn't notice any specific reference to the difference between materials encrypted for long-term storage or transmission (data, email) and on the other hand audio telephone communications, the original stated application for the Clipper chip. I can't see any reason that an individual would want the key to his own crypto telephone keys escrowed; unlike the key for data on a computer, which at least theoretically might be lost, the cryptophone data is by definition lost as soon as it is used. Therefore, I can see no argument which would make a person support this key escrow for that purpose. Since the whole system is supposed to be "voluntary", who is going to accept this? Jim Bell jimbell(a)pacifier.com

1 0

Re: An alternative to remailer shutdowns (fwd)
by David Rosoff 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 10:24 AM 5/21/96 -0800, jim bell <jimbell(a)pacifier.com> wrote: >At 06:28 PM 5/20/96 -0500, Jim Choate wrote: >> >>Forwarded message: >> >>> Date: Mon, 20 May 1996 15:02:08 -0700 >>> From: Hal <hfinney(a)shell.portal.com> >>> Subject: An alternative to remailer shutdowns >> >>> was apparently sent through my remailer. According to 18 USC 875(c), >>> "Whoever transmits in interstate commerce any communication containing >>> any threat to kidnap any person or any threat to injure the person of >>> another, shall be fined not more than $1,000 or imprisoned not more >>> than five years, or both." I may not be able to continue operating >>> either of my remailers (alumni.caltech.edu and shell.portal.com) for >>> much longer due to this kind of abuse. >> >>There should be a section in there dealing with 'knowingly'. If not then we >>should immediately bring charges against any and all newspapers who have >>ever printer a ransom letter, or perhaps even the Unibomber Manifesto since >>there is clear evidence of 'threat to injure the person of another'. > >But even "knowingly" needs to be carefully defined. A remailer operator >today KNOWS that his system COULD be used for illegal activities; he merely >doesn't know that they are, currently. I think that the definition should >be so narrow that it is impossible for a third party (or the government >itself) to incriminate the remailer operator by having his system forward >arguably illegal or copyright-violating material. > > >Jim Bell >jimbell(a)pacifier.com Can the same sort of standards as per the U.S. CDA be applied? The first draft of the CDA would have held ISP's responsible for, e.g., porn transmitted using their services. Isn't this the same sort of thing - that is, that remailer operators provide a service, and they cannot be held responsible for people who abuse that service? I think that this line of thought is reasonable. David -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMaNZlxguzHDTdpL5AQGkIgQAkfTaXyFp32yX1CiKK/7xlfvojYK+oG2U BWS5w2gMWeorRB1jPJW3Aec3cAlUQCoYg7TOd+Z8EgHWqHxR30cDUBd56oq1wlmf 0X3d2rjnM64Bcq8gonFXPxeSU+C3O0qobdj58BUpo+o2ueNo0sPGLK79KKAHuhWW oBBXV6jGTWc= =AXOt -----END PGP SIGNATURE-----

1 0

Re: The Crisis with Remailers
by Bruce Baugh 17 Dec '03

17 Dec '03

At 12:30 AM 5/22/96 EDT, E. ALLEN SMITH wrote: > Would you suspect that having more warning labels (before & after, >not just in the headers) would help with any negative reputation thus >generated? Probably not. Does it really matter how many times I tell you "I'm not being a jerk" if everything I send you is in fact jerky? (FBI and "this is not an assault", anyone?) Pointing people at legitimate uses of anonymity, as various folks have suggested, is undoubtedly a good idea. Would anyone care to suggest a few newsgroups where the vast majority of anonymous posts have really good reasons for being so? In cases where there's been serious abuse of remailers that's been caught and dealt with, some PR on the part of remailer operators might go a long way toward helping things. "Yes, this person was doing loathsome things, but we put a stop to it [insert details here." >put into public view... I see no reason to give lawyers more of a privilege >than religious/psychiatric individuals. Ditto. Likewise, I liked the instance last year of a student applying for the mail logs of the local (state?) government. It is Good for rulers to feel the same weight of the rules they impose on others. -- Bruce Baugh bruce(a)aracnet.com http://www.aracnet.com/~bruce

2 1

Re: An alternative to remailer shutdowns
by Ben Holiday 17 Dec '03

17 Dec '03

On Tue, 21 May 1996, Daniel R. Oelke wrote: > > Ben Holiday <ncognito(a)gate.net> wrote: > > At this point there are 2 options, which I havnt examined closely: The > > first is that you require them to send a request for their "consent-code" > > which can be used to decrypt the mail. Under this arrangment you could > > This could be done with no "storage" as well, by a slightly > different method and still require end reciepient acknowledgement. > The end reciepient could be required to reply and include the encrypted > message. The remailer would then decrypt the message and send back the > plaintext. Only storage would be the key vs. a message id database. Well, if we've gone that far, why not attach an encrypted copy of the key to the peice of mail, and eliminate all storage from the r-ops machine? > > The second is to simply include the > > consent-code along with the encrypted peice of mail and a legal notice > > stating that decryption of the mail constitutes your consent to receive > > the mail, as well as your agreement to hold the remailer-operator harmless > > By reduction - you could just do a rot13 on the message and > append the "legal notice". If all the information for decoding > a message is present in that message, is a different encoding > mechanism really any different from straight ASCII text? > (i.e. Netscape 9.13 might have auto decoding built it....) > Then, the user doesn't do anything "extra" - does this invalidate > the notice? Donno. IANAL. :) > I might be wrong, but I don't think that this second method would > gain you anything in the 2 situations where operators will get > hassled. 1) Posting of copyrighted material - the lawyers will > at least harass you no matter what kind of legal notice is up front. > 2) Mailing of "harassing" information - the person still gets > unwanted email, and has no way to stop it. [RANT MODE ON- skip to the next paragraph if you dont like politiks] Here we are back at step one again. In the end, it would seem that there isn't much that can be done about the worst forms of abuse, without filtering mail for content. However, someone pointed out that other package delivery services have acheived freedom from responsibilty for the content of the packages they deliver - and I beleive that a part of the explanation for this lies in the fact that they /do/ make attempts to limit abuse in-so-far as they are able. Part of limiting the remailers liability is tied up with legitimizing them as a useful service, and establishing to the public that we are concerned with abuse. Too many people beleive that the whole point of a remailer is to facilitate illegal and abusive communication, and unless that changes we can expect to be dealt with as criminals at worst, or at best as purposfully negligent. I'm not certain what the solution is, but I am certain that doing nothing isnt it... [RANT MODE OFF--] One idea that came up a while back was a sort of limited tracking of mail -- an example would be keeping a hash of the email address where mail was received from for 48 hours, with the hash value being attached to the peice of mail as a header. This would accomplish two things: We could source block an address without knowing the source; and if push came to shove an address could be backtracked to its original source, provided a complaint was made in time, and that the Bad Guy sent another mail from the same address. I think that legally there would be a good argument that the remailer ops had made a reasonable attempt and holding lawbreakers accountable, while still preserving the anonymity of non-abusers. Just a thought.. Ben.

3 2

Floating Point and Financial Software
by mpd＠netcom.com 17 Dec '03

17 Dec '03

There seem to be a few mini-flames on the list over whether floating point data representations are appropriate for financial software. In a nutshell, the answer is "YES", and the use of floating point arithmetic is common in such applications. One argument heard against the use of floating point is that it is inherently "imprecise." In reality, floating point representations and the results of floating point operations are perfectly well defined, and the points on the real number line which are exactly representable by double-precision floating point values are usually a superset of those representable by the default integer on most machines. Storing monetary values as double-precision floats having integer values in cents is even common in COBOL programs, where the "COMP-3" data type allows the use of fast floating point in lieu of the default and slow manipulation of packed decimal and decimal data. It is even common in certain CPUs, like CDC Mainframes and SPARCS, which are primarily floating point engines, to omit integer divide and sometimes even multiply, and to provide a subroutine which employs floating point calculations to emulate these operations. This is completely transparent to the user of the machine, and there is no problem in using floating point to do integer operations. In fact, when running financial applications on large engineering mainframes, which generally lack a business instruction set, floating point is not only commonly employed, it is the obvious way to get the maximum performance out of the machine. -- Mike Duvos $ PGP 2.6 Public Key available $ mpd(a)netcom.com $ via Finger. $

4 4