December 2003 - cypherpunks-legacy

MIN_ers
by jya＠pipeline.com 17 Dec '03

17 Dec '03

New Sci 25 May 1996: "Panning for data gold." Nowadays nearly every organization from supermarkets to the police can boast a vast mine of electronic data. Separating the gold from the dross is the real challenge. A growing band of computer scientists say they can dig out nuggets of 24-carat knowledge from huge mountains of database dross. They call themselves "data miners", and they are wielding some pretty impressive tools -- information theory, laws of probability, neural networks, tree induction, genetic algoritms, disjunctive normal form logic. But the impact of their efforts is anything but esoteric. By identifying potential new customers -- or ways of hanging on to existing ones -- this information is worth millions in extra revenue. And this is just the start, according to Usama Fayyad of Microsoft Research and co-editor of a new book on data mining. MIN_ers

1 0

Asendmail For Mix [Testers Needed]
by Ben Holiday 17 Dec '03

17 Dec '03

For the past several days i've been working on a method of concealing the identity of Remailers.. I've put together a program that acts as a replacement for sendmail with mixmaster, along with a list of 135 sites on the internet that either do not add received headers at all, or add headers that don't indicate who the originator was. The program is called asendmail and what it does is pick 2 servers from its list of proxy's (using a modified version of the rnd generator from Lance Cottrell's reorder package). It then opens an smtp socket with the first server, sends the second servers name in its introduction, and procedes to send its mail that way. I'm not an expert on such things, but a careful look at the resulting mail has revealed no sign of the originating remailers address. As far as I can tell the only way to identify the remailer would be by obtaining logs from the proxy host, if they exist. Asendmail is being used for all mixmaster mail sent through ncognito(a)cyberpass.net currently. It would be helpful in debugging if some people could route a few test messages through the mailer, examine the headers, verify that mail has arrived, etc. Any and all feedback will be greatly appreciated. Assuming that the results of this testing are acceptable, i will make a beta version of asendmail, and my (ever expanding) proxy list available. Thanks,

2 2

Re: [SCARE]: "If you only knew what we know..."
by Jean-Francois Avon 17 Dec '03

17 Dec '03

On 27 May 96 at 21:46, Subir Grewal wrote: > > Oh, you mean, "for them, anybody who pass a judgment of his own > > that :contradict them should be killed" I see... > Glad you noticed that. Now tell me how AP for any other cause is > different? It has similarities. But AP will not be the enforcer of *one* opinion. And, according to Jim Bell, people will realize that the best way to behave is to adopt a low profile. Again, this is where I do not agree with JB, although I cannot say I disagree. I simply do not know. Maybe, since the basis for sustenance of human life is production, and since the majority has to be producers, the majority will endorse more libertarians ideas. But again, maybe Joe Average was so convinced that "the rich" owe him a free lunch that AP will lead to complete destruction of the system. I personnally tend to believe that Joe Average still has some common sense and integrity. JFA PLEASE NOTE: THIS POST DOES NOT MEAN THAT I ENDORSE MR. BELL'S SYSTEM. MY RATIONNAL CONCLUSIONS ABOUT IT'S INTERNAL MECHANICS AND IT'S INTRINSIC LOGICS DOES NOT MEAN THAT I LIKE NOR ENDORSE THE SYSTEM. I SIMPLY CONCLUDED THAT IT IS IMPOSSIBLE TO PREVENT THE SYSTEM FROM BEING IMPLEMENTED. IMO, IT IS UNAVOIDABLE. DePompadour, Societe d'Importation Ltee Limoges porcelain, Silverware and mouth blown crystal glasses JFA Technologies, R&D consultants. Physists, technologists and engineers. PGP keys at: http://w3.citenet.net/users/jf_avon ID# C58ADD0D : 529645E8205A8A5E F87CC86FAEFEF891

1 0

Re: Mixmaster version usable with POP?
by Bill Stewart 17 Dec '03

17 Dec '03

At 12:44 AM 5/27/96 EDT, E. ALLEN SMITH wrote: >From: IN%"markm(a)voicenet.com" "Mark M." 26-MAY-1996 18:46:13.23 > >>On Linux this works: >>popclient -3 -c POPHOSTNAME | formail -s mixmaster -R >> $MAIL > >>It will work on any system that has formail and popclient on it. > > Is this only for getting mail, or also for sending it? Sorry, I'm >not very familiar with UNIX, especially the pipe commands. A pipe takes the standard output of the program on the left-hand side and feeds it to the standard input of the program on the right. On Real Operating Systems, like Unix, both programs are running at once, so the pipe doesn't need to buffer very much information; MS-DOS fakes it out by running the first command while dumping its output in a temp file, then running the second command with its input from the temp file. A program named "popclient" is almost certainly designed for fetching mail from a Post Office Protocol server, which keeps a mailbox for you. I'm don't know what "formail" does, but it's presumably going to crunch your newly fetched mail through mixmaster to send it out. (A not unreasonable guess for what it does is to take a bunch of mail from standard input (e.g. the output of popclient) and crunch each mail message according to the options on the command line, for instance filing it, prettyprinting it, or whatever.) So this is a remailer. To just send mail, you'd use mixmaster. # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com, +1-415-442-2215 # goodtimes signature virus innoculation

1 0

PGP MIME INTERNET DRAFT considered harmful.
by paul.elliott＠hrnowl.lonestar.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Summary: The PGP MIME INTERNET DRAFT, draft-elkins-pem-pgp-03.txt, contains a design error with respect to signatures on binary data. This error results from the failure to recognize the distinction between those features of MIME which are necessary to represent complex data and those features of MIME that are used to transport the data. The design error will result in the following negative results if PGP-MIME is widely used with binary data. (1) Huge unnecessary inefficiency whenever binary data is sent signed and encrypted. (2) The signatures on PGP MIMEd objects can not be extracted from a MIME context and used where MIME programs are not available. (3) Many users will rightly refuse to sign the entities the PGP-MIME draft envisions. This reduces the utility of PGP-MIME. (4) If users do sign these files, they will be signing data for which there are no commonly available inspection tools. This will eventually result in a security breach. - ---------------------------------------------------------------------- The problem is that when binary data is to be signed the data is to be PGPed _after_ base64 has been applied and the MIME headers added. This is required by the draft: > >3. Content-Transfer-Encoding restrictions > > Multipart/signed and multipart/encrypted are to be treated by agents > as opaque, meaning that the data is not to be altered in any way > [1]. However, many existing mail gateways will detect if the next > hop does not support MIME or 8-bit data and perform conversion to > either Quoted-Printable or Base64. This presents serious problems > for multipart/signed, in particular, where the signature is > invalidated when such an operation occurs. For this reason it is > necessary to REQUIRE that ALL data signed according to this protocol > be constrained to 7 bits (8-bit data should be encoded using either > Quoted-Printable or Base64). Note that this also includes the case > where a signed object is also encrypted (see section 6). This > restriction will increase the likelihood that the signature will be > valid upon receipt. > > Data that is only to be encrypted is allowed to contain 8-bit > characters and therefore need not be converted to a 7-bit format. > > In this the draft follows RFC1847. [Encrypted & Signed binary data.] Now when there is a data path for PGP's cyphertext, PGP provides a binary data path for its plain text. Thus, the inner base64 that PGP MIME internet draft requires is totally unnecessary. It will cause a 30% increase in the size of those messages that are encrypted and signed and large amounts of CPU time will be used applying & removing the base64. It is worth noting that huge amounts of binary data will be transferred by MIME, so the above represents a significant problem. [Signed binary data.] Now let us consider the question of what PGP-MIME draft requires users to sign. Suppose we want to send a signed .gif file to a sysop. The sysop wants to store the .gif in his download section. Suppose the sysop wants to store the signature as a detached signature so that people who download it can check the authorship. But the signature proposed by the PGP-MIME draft is useless for this purpose. It has MIME headers attached and it has been base64'ed. People who download such a file from a BBS have no use for it, unless they have MIME. Or suppose we send as signed .gif file to the maintainer of a WEB page. He stores the .gif on an insecure UNIX system connected to the internet. Suppose, a year later the maintainer wants to check if the .gif has been tampered with. Can the maintainer store the signature on a floppy and use the signature for later checking? No, the only way the signatures specified by the draft can be used, would be to add MIME headers and apply base64. The maintainer will have to store the entire MIME message, .gif and all if he wants to check the signature later. Or let us consider an .gif artist. The artist has a policy of only signing works that he can be proud of. He does not sign his sketches, because he does not want sketches to tarnish his reputation. Before signing and releasing a work, he examines it with several different gif viewers and paint programs. But what does the draft PGP-MIME want the artist to sign? It wants him to sign a file that has been base64'ed and with mime headers added. The artist can not examine the file to be signed with any of his gif viewers or paint programs. Everyone's mother has told them to "Never sign anything unless you have read the fine print first." But here we have a file that has been scrambled so that it can not be inspected with the commonly available tools. The artist refuses to sign. Not only does he not know what he is signing, but the base64 offends his artistic standards. Who can be proud of base64? Necessary perhaps, but lets face it, base64 is an horrible kludge built to meet the deficiencies of a network. If users get in the habit of signing binary files which represent multimedia data, and which can not be examined with commonly available inspection tools, it is inevitable and predictable that sooner or later this will cause some kind of negative security event. Now there is some justification for the way the draft handles text. Different operating systems and machine architectures represent text in different ways, so that it is necessary that digital signatures be taken over some "canonical" format so that signatures will check on different operating systems. Even after text has been mangled by Quoted-Printable it can still be read after a fashion by the person asked to sign it. Operating systems and machine architectures also differ in the way they represent binary data. The differences in the ways integers, floating point numbers and other such thingies are represented are well known. However, such differences must be handled at the application level. The location within a file of integers, floating points, etc must be set by the application programmer/designer. PGP, MIME, and base64 can not deal with these differences, because the location of integers and floats can not be specified in advance for an arbitrary data file. Thus, from the point of view of PGP and base64, these differences do not exist and binary data may as well be a stream of bytes. Thus, in the case of binary data, base64 is not more "canonical" than the original data. There is no good reason to sign the base64 rather than the original data. Once a file has been base64ed, the file can not be examined with the usual inspection tools. The draft has chosen to treat text and binary data similarly. This results in negative results mentioned above, but the developer and draft author do not have to deal with any logic to handle text and binary data separately. User utility and security have been sacrificed for the convenience of simplicity for the draft author and the PGP-MIME developer. The typical user of MIME software is not necessarily technically sophisticated. When the deficiencies and disasters associated with software patterned on this draft become apparent, not everyone will know exactly which software component is at fault. The problems associated with the draft (or its successors) may adversely affect the reputation of PGP. Now some descendant of the draft could become a standard or the draft could become a de-facto standard through wide-spread use. Such a standard could become a barrier to the acceptance of other software without the draft's deficiencies. Thus, the draft could permanently inflict poor software on the world. (Look at the memory architecture of the IBMPC for one example. Or look at the MSDOS operating system for another example.) The draft should be withdrawn. People should rethink and create a better plan to combine the benefits of PGP and MIME. It should accommodate the user who wishes to mail a generally usable PGP signature (that is, one that can be used outside the context of MIME) along with multimedia binary data. It should not ask a user to apply a signature to any data that cannot be examined with commonly available tools. It should not require anyone to sign an artifact of a data transfer system such as base64. It should not require any additional space overhead (more than that which may be necessary for transport) when signing and encrypting. - -- Paul Elliott Telephone: 1-713-781-4543 Paul.Elliott(a)hrnowl.lonestar.org Address: 3987 South Gessner #224 Houston Texas 77063 -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: cp850 iQCVAgUBMaBPRPBUQYbUhJh5AQH2hwP+J1ADSzD3Yx4gvUIvAwN+EDikIN2IaHhM j+znIlt9QPzl5SSp44H+JnhoivhKR3562ACI1nexNMZ9E2MrPNioiGmrmz0uGwM6 Px/k2HbioQrgqmmP0IO/98cTZGA71pK7iNk7AZbWpEW4XfWkyRDW9hQzrCEZXXw8 jQwM/VHUPl8= =BvoZ -----END PGP SIGNATURE-----

1 0

Re: net-based key archival
by an116512＠anon.penet.fi 17 Dec '03

17 Dec '03

In .cypherpunks, Matt Blaze <mab(a)research.att.com> writes: >I've put a revised version of my "Key Escrow without Escrow Agents" >abstract in my ftp directory, in PostScript and Latex formats. > ftp://research.att.com/dist/mab/netescrow.ps > ftp://research.att.com/dist/mab/netescrow.tex I just brought these files down + a few others in the same directory that he didnt tell us about (you can see them with netscape by leaving off the last part. Check out MKCS.PS and others. They take a while to see because you need a postscript viewer but if you can read them they are enlightening abot this guys character. It looks like AT&T is in the key escrow biz, folks!!! Maybe someone should scan them in and post them to the list, so we know what the enemy is doing. The MKCS.PS file is about how to make a code for other people to use so that you can break. And then they say dont worry the government would never do this!!! Riiiiggggght. PS I hope this message goes through, my posting software on connectnet doesn't work so I'm using penet. ++arlo : --****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

2 1

Re: Philosophy of information ownership
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:55 AM 5/28/96, Bruce Baugh wrote: >What specifically bothers me is the reselling of information that I chose to >reveal for a specific transaction, most especially when I did so with an >assumption of privacy. I'm happy to provide businesses with the info they >need to see that I'm not going to stiff them on a sale. I am _very_ unhappy >that some of them then turn around and sell that info to others, and doubly >so when what gets passed on is wrong. Contracts are the key. If Alice contractually agreed to hold data confidential, then didn't, Bob would have a case for suing. If Bob revealed information without a contract, Alice can do with it as she pleases. And in most of the cases I was talking about a few days ago (I was gone for the weekend and could not participate in this debate until now), Alice is using various records or observations that are free for anyone to remember, save, use, etc. Alice compiles a dossier on Bob based on press items, public court records, bankruptcy filings, divorce decrees, and all the various things that are available to anyone who is "observant." (The government has attempted to interfere with this record-keeping and -reporting, such as with the "Fair Credit Reporting Act," which makes the "remembering" of bankruptcies, defaults, and other such indiscretions a crime if the records are greater than 7 years, or somesuch. My point is that such laws are not only unconstitutional, even under the "regulate commerce" clause, but are laws which ultimately invite the government to inspect the files and records of someone...so much for "secure in one's papers.") Face it, if one makes public utterances, or utterances on lists like this, or one files for bankruptcy protection, or any number of such things, then others can and will "remember" these things. How they use these remembrances or who they pass them on to, or sell them to, has *never* been something that the U.S. government has been empowered to control or regulate. Until recently, of course. All to the worse. >>When I walked off with your blood chemistry data, did you lose the use >>of it for your future purposes? > >What I've lost here is privacy, something which does have monetary value to me. As others have noted, the proper solution is to make contractual arrangements with those doing blood analyses, or handling the data. It works for financial data, more or less, and so on. There is no justification (and many reasons against such a thing) for invoking some nebulous "right to personal information." >[example of info gleanable by my reading/posting to Cypherpunks and other >sources out there for the world to see] >>What do you propose as to the obligations I should have to you as regards >>the disposition of this information? For example, what if I receive a > >Things like that don't bother me, either. If I really didn't want to be >associated with Cypherpunks that way, I could do things to protect my identity. Fine, you draw the line at "Cypherpunks information can be revealed, but you'd better not reveal XYZ." Others would use your same logic to argue that even the "who cypherpunks" command information is "private" and not to be compiled into a dossier or revealed or, God forbid, sold. Again, what are the contractual relationships? >On the other hand, say I sign up for a mailing list that charges a >subscription fee, like Extropians. I would feel no ground for complaint if >someone markets a list of Extropian subscribers - but I'd feel much ground >for complaint if I learned the list owner were selling credit histories >gathered during the subscription process. (Unless, of course, I assent to a >clause to the effect that the list owner can do anything he wants with my >credit info, as opposed to the specific purpose of getting payment for the >list.) Here you seem to be referring to contracts. A good start. And much better than mere appeals to intuition about what ought to be private and what ought to be public. --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, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: Philosophy of information ownership [ Re: Children's Privacy Act ]
by Bruce Baugh 17 Dec '03

17 Dec '03

At 09:24 AM 5/27/96 -0500, Mike McNally wrote: >What if I just *see* your couch, and then back in my garage I use my >couch replicator to make a couch just like yours, complete with fuzzballs >and loose change between the cushions? Now I have your couch, in a sense. >Are you still upset? Watch and act. This doesn't bother me. What specifically bothers me is the reselling of information that I chose to reveal for a specific transaction, most especially when I did so with an assumption of privacy. I'm happy to provide businesses with the info they need to see that I'm not going to stiff them on a sale. I am _very_ unhappy that some of them then turn around and sell that info to others, and doubly so when what gets passed on is wrong. >When I walked off with your blood chemistry data, did you lose the use >of it for your future purposes? What I've lost here is privacy, something which does have monetary value to me. [example of info gleanable by my reading/posting to Cypherpunks and other sources out there for the world to see] >What do you propose as to the obligations I should have to you as regards >the disposition of this information? For example, what if I receive a Things like that don't bother me, either. If I really didn't want to be associated with Cypherpunks that way, I could do things to protect my identity. On the other hand, say I sign up for a mailing list that charges a subscription fee, like Extropians. I would feel no ground for complaint if someone markets a list of Extropian subscribers - but I'd feel much ground for complaint if I learned the list owner were selling credit histories gathered during the subscription process. (Unless, of course, I assent to a clause to the effect that the list owner can do anything he wants with my credit info, as opposed to the specific purpose of getting payment for the list.) -- Bruce Baugh bruce(a)aracnet.com http://www.aracnet.com/~bruce

1 0

Re: Remailers & liability
by Greg Broiles 17 Dec '03

17 Dec '03

At 05:06 PM 5/27/96 EDT, E. Allen Smith wrote: > Why, precisely, do you think that remailers don't do much good where >the operator isn't root? The possibility of the sysop looking at the mail & >getting the private key, the increased susceptibility to cracking of >non-root accounts, possible sysop non-cooperation in an honest manner (as >opposed to the first one), or what? I think it's more difficult to covertly monitor communications through a remailer if the remailer operator isn't root; this is also the case if the primary MX record doesn't point directly to a machine under the operator's control. I think it'd be possible for a hostile party to monitor/intercept communications through any remailer; but it's more likely to cause an unexplained disruption or outage where the hostile party has less access to the target machine/network, and the operator (who we assume is trusted) has more access. I also think that where root is not the remailer operator, root is a lot less likely to say "fuck off you evil TLA I won't help you monitor remailer traffic." My hunch is that many/most remailer operators would shut down a remailer instead of letting a TLA monitor traffic, and/or would refuse to take clear steps to publically reestablish the integrity of a remailer if its confidentiality was in question. My hunch is that many/most "professional" sysadmins would let a TLA monitor traffic if a user was running a remailer, and wouldn't do anything to let either the user/operator or the clients of the remailer know anything was amiss. Look at the way that the WELL and Netcom and AOL (I'm probably missing some examples here) have been willing to let amateur and professional spooks & cops wander around their systems reading mail and looking in home directories while chasing "bad guys". How many ISP's are going to say "come back with a warrant" if cops show up with badges & guns, saying "User X is running a remailer which sends kiddie porn/drug sales transaction info/whatever"? I bet very, very few. (And no, the ECPA won't be much help, see _Steve Jackson Games_ re "what does intercept mean?") Obviously I'm talking about "more" and "fewer" and hunches, not a mathematical proof. This is really just another web-of-trust; I may trust X to run a remailer (and not log traffic or disclose it to outsiders), but I probably don't trust X to pick a service provider who will not be susceptible to "the Briefing" and who won't hire anyone as a sysadmin who isn't bribable or coercible. My intention is not to slam remailer operators who aren't root, just to point out that the level of protection we should expect from those remailers is relatively small. Ditto for remailers operated by unknown nyms who don't have well-known people willing to vouch for their integrity. Truly, no offense is intended. If I have some idea who the remailer operator is, and they are root, I feel like I learn something if the operator says "My system doesn't log traffic." If the operator isn't in a position to know (because they're not root) or if I don't have a reason to trust them, I assume the remailer is logging traffic. And a remailer that logs traffic may be more dangerous than no remailer at all, because the amount of security provided is illusory. -- Greg Broiles |"Post-rotational nystagmus was the subject of gbroiles(a)netbox.com |an in-court demonstration by the People http://www.io.com/~gbroiles |wherein Sgt Page was spun around by Sgt |Studdard." People v. Quinn 580 NYS2d 818,825.

1 0

Re: Philosophy of information ow
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:46 PM 5/27/96, Chris Adams wrote: >On 27 May 1996 11:25:28 pdt, m5(a)vail.tivoli.com wrote: > >>What if I just *see* your couch, and then back in my garage I use my >>couch replicator to make a couch just like yours, complete with fuzzballs >>and loose change between the cushions? Now I have your couch, in a sense. >>Are you still upset? >> >>When I walked off with your blood chemistry data, did you lose the use >>of it for your future purposes? > >I believe that you are free to keep information, use it, etc. but >you MUST get permission before selling it. This opinion summarizes what's wrong with the world today. Facts are facts. Statements about reality. If I happen across a piece of information, such as "Chris Adams is subscribed to the Cypherpunks list," I need not get permission from Chris Adams to sell this fact to another. (Unless of course I have a contractual relationship with Chris involving this in some way.) Not even in these Beknighted States, unless the laws have recently gotten much worse that they were a short while ago. --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, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0