December 2003 - cypherpunks-legacy

Re: SEVERE undercapacity, we need more remailer servers FAST (fwd)
by hendersn＠zeta.org.au 17 Dec '03

17 Dec '03

>Had he posted it through a remailer, I think it would have been well >justified. He was obviously blowing the whistle on what he saw as illegal >activities. The only reason that Keith could post NOTS 34 at all was because it had previously been posted to a.r.s anonymously. Prior to that, no-one outside of the Church had a copy of any NOTS materials(or so the Church says). > That's a much different matter than posting the entire NOTs >series, though. The wholesale copying is what most people seem to object >to, though my observations tell me that the "Church" objects to any >copying, even for fair use... Grady Ward got sued by the Church just because he _asked_ for a NOTS pack to be sent to him. The Church will do everything within its not inconsiderable power to prevent NOTS material being disseminated on the Internet - up to and including destroying the anonymous remailer network. Zed(hendersn(a)zeta.org.au) "Don't hate the media, become the media" - Jello Biafra PGP key on request

1 0

DC area physical meeting, this saturday
by Pat Farrell 17 Dec '03

17 Dec '03

Appologies to the 1000+ folks who are too far away to care about this... The next Washington DC area cypherpunks physical meeting will be this saturday, May 25 at 3:00 PM, at Digex.net. Details, directions, etc. at http://www.isse.gmu.edu/~pfarrell/dccp Pat Pat Farrell Grad Student http://www.isse.gmu.edu/~pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>

1 0

Re: The Twilight of the Remailers?
by middle-man-admin＠alpha.c2.org 17 Dec '03

17 Dec '03

On Tue, 21 May 1996, Timothy C. May wrote: > At 7:59 PM 5/21/96, Alex Strasheim wrote: > >I'm closing my mixmaster, nsa(a)omaha.com, on the 4th of June. > Between Hacktic going down, Hal's comments that he may shut down his two > sites, and this, plus others who are more quietly making plans to shut > down, I think the thread title "The Remailer Crisis" is more apt than ever. I tend to agree. I realize that the middle-man remailer requires that there be bastion remailers on the end of the chain. Without them, the "middle-man" concept won't work. I thank the remailer sites the allow the middle-man to work. Anyway, with all the remailers that have either vocalized their retirement and those that are silently considering retirement, I would like to announce that the middle-man remailer should be available for download as early as this weekend. Utopia.hacktic.nl (basement) and c2.org have agreed to carry the middle-man remailer on their FTP sites. As soon as I can get the documentation finished, I'll post it. middle-man-admin

1 0

Reply to e$: The Wealth of Nation-States
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text Date: Tue, 21 May 1996 23:35:22 +0900 To: rah(a)shipwright.com From: tatsuo(a)glocom.ac.jp (Tatsuo Tanaka) X-Sender: tatsuo(a)izanagi.glocom.ac.jp Subject: Reply to e$: The Wealth of Nation-States Cc: tatsuo(a)glocom.ac.jp (Tatsuo Tanaka) MIME-Version: 1.0 Dear Mr. Robert Hettinga, Please allow me to write you. I am a visiting research fellow of Columbia University, and study digital cash from the economics point fo view. I read your article on "e$:The Wealth of Nation-States." ineterestingly. I also think that digital cash will cause a conflict with the Nation-States, though my major concern is financial economics view point, not taxation problem. I wrote a paper on this issue,"Possible Economic Consequences of Digital Cash " which is supposed to be presented at the coming INET96. This paper's URL is http://tenjin.glocom.ac.jp/tanaka/inet/DigitalCash_v1e.html I hope this paper might be of interest to you. Following is an abstract of this paper. Author discusses possible consequences of digital cash from the view of economics and forcasts a possible scenario for the future. Digital cash will bring us benefits as well as problems. One major benefit of digital cash is its increased efficiency which will open new business opportunities, especially for small businesses. On the other hand, it will bring us four problems: taxation and money laundering, instability of the foreign exchange rate, disturbance of money supply, and the possibility of financial crisis. There is one important attribute of digital cash, however, that overshadows these benefit and problems. It is the transnationality of digital cash, that is, the ability of digital cash to flow freely accross national borders. Every bank can issue it and everybody all over the world can use it. This transnationality is a cause for both benefits and problems, and could have significant repurcussions internationally. From the economic stand point, the most important characteristic of digital cash is its transnationality. If digital cash circulated only within a traditional national border and was controlled under a central monetary authority, there would be no economic implications that would be worth analyzing. In this case, digital cash would be nothing more than a convenient transaction method such as a credit card. However, digital cash is more than that. Its transnationality has the potential to cause conflict between cyberspace and nation states. If digital cash spreads successfully in the 21st century, its history may be written as a record of its battle with nation states. Thank you for your time. Sincerely yours, Tatsuo TANAKA Tatsuo Tanaka Email:tatsuo@glocom.ac.jp -Current Address- -Contact in Japan- Center on Japanese Economy & Businness Center for Global Communications 521 Uris Hall International Univ. of Japan Columbia University 6-15-21, Roppongi,Minato-ku New York, NY, 10027, USA Tokyo 106,Japan Fax:+1-212-678-6958 Tel:665-5028 Fax:+81-3-5412-7111 Tel:5411-6677 --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "If they could 'just pass a few more laws', we would all be criminals." --Vinnie Moscaritolo The e$ Home Page: http://thumper.vmeng.com/pub/rah/

1 0

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

17 Dec '03

At 11:58 1996-05-22 +0200, bryce(a)digicash.com wrote: >Matts, _floating_ point numbers are _not_ useful >if you want to handle a number with a lot of precision, nor >indeed, if you want to be able to _know_ the precision! If you >have a number that represents money, you want to know the >precision! As I said yesterday, there are in fact people dealing with billions in all major currencies that keep their money in 64 bit floats. The precision is far better than anything you can do in 32 bit integers. Trust me, this is a fact and can easily be proven. >I shall try to refrain from taking umbrage at your comment that >DigiCash is "not real". The "get real" was a pun on floats. Many languages, such as Pascal, calls them real numbers. Sorry I forgot the smiley. >Also that DigiCash doesn't "do" currency. What could you possibly >mean by that? In my client (2.1.5a MT) there is no way to do currency conversion. If I go to a FIM or DEM merchant I can't buy anything in the store. This will probably change in the near future when a new client is released, and then we'll have the question of how to represent these currencies in one wallet. What do you think will happen if you have a one italian lira coin and you try to deposit it with Mark Twain's USD account? With integer math it won't be pretty. >For further reading on floating point and other representations >of numbers in computing, I recommend any good introductory >university text on mathematical computing. Sorry I don't have >mine handy or I'd give you a specific reference. Maybe you should start looking for it. You'll need it when the lira arrives... Regards, Matts

7 9

Re: Clipper III analysis
by frantz＠netcom.com 17 Dec '03

17 Dec '03

John Gilmore wrote an excellent description of GAK 3 (aka Clipper III, aka Enabling Privacy, Commerce, Security and Public Safety in the Global Information Infrastructure). Here are a couple of other points that even the proponents of this scheme should agree to: (1) GAK3 does not provide for the significant public purpose of protecting dissident groups under repressive regimes. Human rights groups in Bosina/Serbia have used PGP to protect their files. Since their computers have been frequently seized, the only protection for those people who have made human rights complaints has been that the local government has not had access to the keys. (2) The paper fails to differentiate between the needs of communication privacy and data storage privacy. No rational person would want to GAK their communication keys. Data lost because keys are lost can always be retransmitted. Since communications are easy to intercept, having a long term GAK key greatly increases the chances that the long term key will be stolen and the session keys intercepted. Communication session keys should be decided by techniques such as Diffie Hellman which ensure that the only entities with access to the key are the programs/hardware at each end of the link. A better case for escrowing long term data storage keys can be made. Physical security provides some protection for the cyphertext. Loss of a key can mean loss of the data. However, it is not clear why encrypting for data storage is any different from storing confidential data in a safe. If the government has a legitimate need to access the data, they can access it through the same legal processes they use to access data in safes. While long term data storage can use escrow agents, it does not need GAK for any legal public purpose. ------------------------------------------------------------------------ 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

3 2

Another Analysis -- Re: NIST Draft Key Escrow Paper
by Joseph M. Reagle Jr. 17 Dec '03

17 Dec '03

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: - the meat is in the footnotes. - buzzword compliance: key recovery and Key Management Infrastructure (KMI). - intro: market forces and government/industry cooperation. - key bullet points: o Certificate authorities will operate within performance standards set by legislation o Agreements between governments will serve as the basis for international cross certification. o Self-escrow will be permitted under specific circumstances. [1] [1] The escrow agency must meet performance requirements for law enforcement access. - Denning's CACM survey key escrow article and Hoffman's "Building in Big Brother" are cited. - A lot of talk about "mutually trusted CAs" A footnote [4] "A mutually trusted authority is an escrow agent trusted by users to store keys and trusted by law enforcement to provide access upon certification of lawful authority." One has freedom to choose any CA, as long as the mutual trust exists. - At the international level "Law enforcement and some national security concerns would be protected since government agencies would be able to obtain escrowed key pursuant to government-to-government agreements." - Products can be exported to countries with these agreements. - Self escrow: "To avoid this risk [of investigations being compromised], independent escrow authorities could be added as another layer. Such a solution would drive up the cost to operate the PKI and drive down the efficiency of conducting public key certification functions, particularly for individual users." [Ok, so independent CAs are "bad" things"] "The solution may be a national policy which allows CAs for an organization to be escrow authorities if they can reliably turn over keys in a timely fashion when requested and to protect the confidentiality of any request for escrowed key. To this end, the government should seek legislation that would shield organization certificate authorities from internal pressures in the course of law enforcement investigations." [A "good" thing?] - provisions for legislation on civil or criminal liability on the commercial/private side. - gives requirements for KMI: key integrity, key accessibility, key recovery with respect to confidentiality, availability and responsiveness (24 hours) requirements. 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." _______________________ Regards, We could never learn to be brave and patient, if there were only joy in the world. -Helen Keller Joseph Reagle http://farnsworth.mit.edu/~reagle/home.html reagle(a)mit.edu E0 D5 B2 05 B6 12 DA 65 BE 4D E3 C1 6A 66 25 4E

1 0

REMINDER: Leahy at Hotwired 5/22/96 4pm EST
by shabbir＠vtw.org 17 Dec '03

17 Dec '03

------ Date: May 22, 1996 (THIS IS TODAY) Senator Patrick Leahy (D-VT) will be on HotWired TODAY, May 22nd at 4pm EST at http://www.hotwired.com/wiredside/ You can tune in and listen to the chat with the RealAudio software (http://www.realaudio.com) You can ask questions of the Senator through a moderator and get real, immediate responses. Topics likely to be covered: Clipper I/II/III and Net Censorship -Shabbir J. Safdar shabbir(a)vtw.org

1 0

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

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