- cypherpunks-legacy - lists.cpunks.org

politics
by moormajb＠vuse.vanderbilt.edu 17 Dec '03

17 Dec '03

It has been suggested that the politcis discussion be taken to another forum, which I am somewhat in agreement with (though I've enjoyed reading all the messages). I, however, want to take issue with a point made by Robert J. Woodhead: > The maintenance and improvement of [that] society, and the betterment > of your fellow human beings, ought to be a primary goal. Maybe it's your primary goal; it's certainly the goal of every Marxist/ Communist/Fascist regime that has every existed. I'm not accusing you of being any of these, but I wanted to point out that these ideologies all support the idea that one's self-interest is somehow evil and that only actions done for the benefit of society or "fellow human beings" are worthwhile and moral. I contend that one's self-interest should be one's primary goal (it is that one's choice however). This self-interest when combined with honesty and integrity is completely moral. It implies a recognition of others' right to be motivated by their own self-interests. Governments are established in order to make sure that self-interests do not conflict (e.g. my self-interest in having the money in your pocket and your self-interest in keeping it for yourself). The U.S. Government may have initially served such a purpose, but it comes nowhere near that today. I'm not saying there are any better places either; hopefully there will be soon. ---------------------------------------------------------------- | | | Joe Moorman <moormajb(a)vuse.vanderbilt.edu> | | | | To achieve Liberty in my time, | | Ready to relocate to Oceania... | | | ---------------------------------------------------------------- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAizFpXwAAAEEAMSgDF2B19fKu9tjmKPQ8wxmzUFLNLvgHy6UAff6V3zr17g5 Qsg9iE9NPTzhzCmKDPb1r1NcpkcSK+K7K8pVwYU6fqTw+/q81yMZ6Ori305Gbyxt QthNQ+JS5ixqCfzuxZ3h5cqtKXLM/XKTkVRMQGMN7z7+oBdV5AXMccsZHPSxAAUR tCpKb2UgTW9vcm1hbiA8bW9vcm1hamJAdnVzZS52YW5kZXJiaWx0LmVkdT4= =iu34 -----END PGP PUBLIC KEY BLOCK-----

2 1

Destroying data
by Philippe_D_Nave 17 Dec '03

17 Dec '03

Hello, data-killers! After reading recent posts about how to keep data (and PC disk drives) out of others' hands (shredders, double-layer encryption schemes for 'revealing' a bogus plaintext while keeping the real data hidden, etc), I had an evil thought.... >:) Thermit grenades are pretty simple; all they do is provide a means of initiating the "thermite reaction." (Look it up in a chemistry text.) Equal parts aluminum powder and iron oxide (rust), finely ground and ignited by (say) a burning magnesium strip, produce the same effect and would quite satisfactorily destroy a disk drive in a matter of seconds. Likewise the PC, desk, floor - quite possibly setting the whole building on fire - "collateral damage," I guess. Don't screw around with this stuff in your basement, people - it is a _very_ fast, _very_ hot reaction that produces a slug of superheated molten metal. For the truly paranoid among you, however, it might be a viable last-ditch ploy to foil the Gestapo. Do be careful. ........................................................................ Philippe D. Nave, Jr. | The person who does not use message encryption pdn(a)dwroll.dw.att.com | will soon be at the mercy of those who DO... Denver, Colorado USA | PGP public key: by arrangement.

3 2

What is the maximum # of bits a key could ever need to be?
by Robert J Woodhead 17 Dec '03

17 Dec '03

This occurred to me this morning in the inner sanctum of inspired cogitation, aka the shower. "What is the maximum # of bit a public-key would ever need to be, given no breakthroughs in factoring?" I came up with an answer, but it depends on some numbers that I don't have handy; perhaps other people on the list can fill in the blanks. First, we need an equation that tell us how difficult it is, in # of operations, to factor a number of N bits. eg: N_ops(N) = # of operations it will take. Then all we need to do is find the N for which N_ops(N) is greater than U_Duration * U_Particles * (1 / P_time) Where U_Duration is the expected duration of the universe, U_Particles is the number of particles in the universe (I am assuming that every particle can be used as a processor; the programming I leave as an exercise to the alert reader), and P_Time is the Planck time (damned if I can remember it) in seconds, which ought to be a good upper bound for clock speed on the Universal CPU. A most likely useless number, but it would be interesting to know what it comes out to. Best, R

1 0

PGP vs PEM discussion
by Brad Huntting 17 Dec '03

17 Dec '03

Perhaps someone on cypherpunks can help with this... To: pem-dev(a)tis.com Subject: Articulation of PGP point of view? From: "Robert W. Shirey" <shirey(a)mitre.org> Date: Thu, 21 Oct 1993 10:54:43 -0500 Is there anyone who has, or is able to, articulate the PGP point of view for public key management and compentently contrast it to the PEM point of view? Is there, perhaps, someone who has written on this subject or spoken publicly in an organized fashion? I am seeking such a person for a presentation and panel discussion at an international conference. I need names ASAP! Please feel free to forward this message to appropriate newsgroups. Regards, -Rob- SHIREY(a)MITRE.ORG * tel 703.883.7210 * fax 703.883.1397 Robert W. Shirey, The MITRE Corporation, Mail Stop Z202 7525 Colshire Drive, McLean, Virginia 22102-3481 USA

1 0

Mail delivery question
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

I have a somewhat dumb question about mail delivery. This has a CP connection because it relates to a remailer enhancement I am working on. When I receive mail from cypherpunks, this is a typical set of headers for an incoming message: From owner-cypherpunks(a)toad.com Wed Oct 20 23:57:11 1993 Received: from nova.unix.portal.com by jobe.shell.portal.com (4.1/1.34) id AA14713; Wed, 20 Oct 93 23:57:11 PDT Received: by nova.unix.portal.com (5.65b/4.1 1.505) id AA18779; Wed, 20 Oct 93 23:57:09 -0700 Received: by toad.com id AA20355; Wed, 20 Oct 93 23:47:55 PDT Received: by toad.com id AA20115; Wed, 20 Oct 93 23:43:21 PDT Return-Path: <jamie(a)netcom.com> Received: from netcom.netcom.com ([192.100.81.100]) by toad.com id AA20111; Wed, 20 Oct 93 23:43:19 PDT Received: from netcom3.netcom.com by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA27104; Wed, 20 Oct 93 23:43:51 -0700 Date: Wed, 20 Oct 93 23:43:51 -0700 Message-Id: <9310210643.AA27104(a)netcom.netcom.com> X-Mailer: Eudora To: cypherpunks(a)toad.com From: jamie(a)netcom.com (Jamie Dinkelacker) Subject: Re: Something Silly, Something Serious Status: RO Now, my question is, when this mail is delivered to the Unix system which I use, how does the local software know to deliver it to hfinney? My name does not seem to appear in the header at all. In particular, the "To:" address is not hfinney(a)shell.portal.com, as I would have expected, but rather cypherpunks(a)toad.com. I suppose there is some other information that is passed along with the message when it is delivered to portal.com, information which tells my user name. It would be nice if this information were available to scripts which would process the incoming mail. Could someone explain how this delivery process works? Thanks - Hal Finney hfinney(a)shell.portal.com

3 2

why an envelope
by pmetzger＠lehman.com 17 Dec '03

17 Dec '03

Enough people have asked that I'll explain why envelopes are seperated from headers in mail. Lets say I'm sending mail with the following header To: foo, bar, baz Mail gets stored and forwarded many times during its delivery process on a large internet. If at every stage the only hint the mailer had for delivery was the header address, every mailer along the way would have to generate three copies of the mail in order to guarantee delivery. Kind of nutty, eh? Thats why there is a seperate envelope. When you generate the mail, three seperate copies will be produced with seperate envelopes indicating the mail whould be sent to "foo", "bar", and "baz", and the mailers in between don't look at the headers at all. This is a slight simplification because envelopes can contain multiple addresses -- but thats when you are sending one message to many people via a common path -- the mailer at the last step where the mail can take a common path is expected to break the envelope up before sending it further along. Perry

1 0

Re:backing
by doug＠netcom.com 17 Dec '03

17 Dec '03

F_GRIFFITH(a)CCSVAX.SFASU.EDU said: >Greshams law: "bad money drives out good" >i.e. where people have a choice (e.g. gold vs greenbacks post Civil >War), in making payments, they will use the lesser value money and >keep the higher value. Thus, the lesser value money will circulate, >the higher value money will not. So in essence you're saying that poorly-backed digital currency will win out over e.g. U.S. dollars? That's an interesting concept. (I mean the above literally, not sarcastically; I don't care to take either one side or the other of this question right this instant, although I will say that there must be some extra caveats to add.) Doug

6 5

Eavedropping techniques revealed!
by Anonymous 17 Dec '03

17 Dec '03

Darn! They publicized a great spoof! excerpted: CA-93:15 CERT Advisory October 21, 1993 /usr/lib/sendmail, /bin/tar, and /dev/audio Vulnerabilities The CERT Coordination Center has learned of several vulnerabilities affecting Sun Microsystems, Inc. (Sun) operating systems. Three separate vulnerabilities are described in this advisory. The first and third vulnerabilities affect all versions of SunOS 4.1.x and all versions of Solaris 2.x. The second affects all systems running any version of Solaris 2.x (but does not affect SunOS 4.1.x systems). Patches can be obtained from local Sun Answer Centers worldwide as well as through anonymous FTP from the ftp.uu.net (192.48.96.9) system in the /systems/sun/sun-dist directory. In Europe, these patches are available from ftp.eu.net in the /sun/fixes directory. Information concerning specific patches is outlined below. Please note that Sun sometimes updates patch files. If you find that the checksum is different, please contact Sun. [...] III. /dev/audio Vulnerability This vulnerability affects all Sun systems with microphones. This includes all versions of SunOS 4.1.x including 4.1.1, 4.1.2, 4.1.3, 4.1.3c, and all versions of Solaris 2.x including Solaris 2.1 (SunOS 5.1) and Solaris 2.2 (SunOS 5.2). Sun is addressing this problem in Solaris 2.3. A. Description /dev/audio is set to a default mode of 666. There is also no indication to the user of the system that the microphone is on. B. Impact Any user with access to the system can eavesdrop on conversations held in the vicinity of the microphone. C. Solution To prevent unauthorized listening with the microphone, the permissions of the audio data device (/dev/audio) should allow only the user logged in on the console of the machine to read /dev/audio. To prevent unauthorized changes in playback and record settings, the permissions on /dev/audioctl should be similarly changed. *** Any site seriously concerned about the security risks associated with the microphone should either switch off the microphone, or unplug the microphone to prevent unauthorized listening. *** 1. Restricting access on 4.x systems Use fbtab(5) to restrict the access to these devices. See the man page for more information about this procedure. 2. Restricting access on Solaris 2.x systems To restrict access to these devices to a specific users, the permissions on the device files must be manually changed. As root: # chmod 600 /dev/audio # chown <console user's username>.<desired group> /dev/audio # chmod 600 /dev/audioctl # chown <console user's username>.<desired group> /dev/audio

2 1

Re: backing
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

Perry wrote: > > A digital currency can be backed by gold held in some secure location > > like the Zurich Free Transit Warehouse. U.S. Dollars are backed by > > absolutely nothing other than blind faith in the U.S. Governement. > > Who's kidding whom? Banks are contractually obligated to turn over mortgage notes in exchange for U.S. dollars. These contracts are valid over approximately 30 years, and provide unencumbered title to valuable property. These and similar contracts may be said to give value to dollars independent of government promises. Hal

2 1

Re: re:700 Club etc.
by djw＠eff.org 17 Dec '03

17 Dec '03

At 4:21 PM 10/21/93 -0500, F_GRIFFITH(a)CCSVAX.SFASU.EDU wrote: >The right to encryption and the "right" to abortion don't have the same >basis - encryption kills no one. I'm not sure that the FBI would agree with the second half of your statement... ................................................................... Daniel J. Weitzner, Senior Staff Counsel <djw(a)eff.org> Electronic Frontier Foundation 1001 G St, NW Suite 950 East Washington, DC 20001 202-347-5400 (v) 202-393-5509 (f)

1 0