December 2003 - cypherpunks-legacy

Re: Instant Remailers
by cpunk＠remail.ecafe.org 17 Dec '03

17 Dec '03

Someone said: > >It is possible for someone to operate an anonymous remailer anonymously. > >Just get a UNIX shell account under a fake name, pay with cash, and set up > >the remailing software. The identity of the operator of such a remailer > >would be difficult, if not impossible, to discover. Then someone else said: > (Doesn't Sameer's system offer such accounts? Couldn't there be dozens of > remailers based at c2.org? Of the 16 Type-1 remailers listed in one of > Raph's recent reports, only 2 were at c2.org.) This happened. Remember robo(a)c2.org? Whatever happened to it? (Anyone ever figure out who the real operator was?)

1 0

Re: The Crisis with Remailers
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"loki(a)infonex.com" 18-MAY-1996 20:02:12.04 >I was invited to the digicash API design meeting precisely to make sure it >could be used in remailers. It will not be using the current API. The >problem is that Mixmaster requires exact knowledge of the size of every >object in the message, to maintain constant message size. I could set aside >room for one, two, three coins, but there is no guarantee that the payment >will be made with only that many coins. The current API is going to be high >level. It will does not allow the program to know anything about the >internals of the payment. I need to be able to specify payment of amount X >using no more than N coins. As soon as I have that level of control, you >will see postage in Mixmaster. Good. I can see doing a limited postage now, actually, with relatively simple modifications - the postage goes to the initial remailer front end and to the remailer that sends out the message to something other than another remailer. -Allen

1 0

Re: Remailers & what they get out of it...
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"ravage(a)ssz.com" "Jim Choate" 18-MAY-1996 09:43:06.96 >As long as the remailer is run a 'grins & giggles' affair you are right. There is the increase in reputation capital in _some_ quarters possible through running a remailer. (On the other hand, in authoritarian quarters, it would tend to decrease one's reputation capital...) >To me the biggest problem with the crypto work right now is that not enough >professionals are involved. If more remailers and such were initiated as >a business there would be legal avenues to explore. Also, in this vain is >the apparent lack of support for commercial ventures by developers of such >apps as MixMaster (whose license explicity prohibits commercial use). It prohibits commercial use? That's silly. Is it a holdover from when the idea was to turn Mixmaster into a company? >And for the record, yes, we expect to charge real $$$ for access. Our >current plan is $10/month for each account. Money orders prefered. We have >at this point pondered e-cash methods but it doesn't seem popular enough >at this juncture. How would you be doing this? Only remailing from accounts that have paid up, or what? -Allen

1 0

Re: Is Chaum's System Traceable or Untraceable?
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"tcmay(a)got.net" 18-MAY-1996 14:30:54.29 >I agree with Jim Bell on this completely. I don't know if Chaum has been >seduced by the Dark Side, or is looking to get digicash widely deployed by >"respectable" institutions, or is telling the truth (that his system >_never_ provided for real untraceability), but I know that Cypherpunks >should always strive for full untraceability. Given what I've picked up (including what institutions he's chosen to deal with, the behavior of these institutions - MTB's dropping of merchants disapproved of by Mrs. Grundy et al, and other information), I am willing to bet that the second is the priority. Once his patents run out, all bets are off... but it looks like he's wanting to get ecash accepted before then. Otherwise, everyone may be using various non-anonymous (or GAKed anonymous) methods like credit card encryption. Unless I'm reading the ecash protocols wrong, using the current version of the software some degree of payee anonymnity is possible. -Allen

1 0

Re: A cryptographic alternative to escrow agents (Matts' half coin)
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: IN%"unicorn(a)schloss.li" "Black Unicorn" 18-MAY-1996 11:46:08.35 >The mint is the escrow agent. It still (obviously) needs to be trusted. The mint will need to be trustworthy anyway; otherwise, you can get a "final round" problem in which they print up lots of ecash and spend it before the value completely plummets, or they get lots of requests to cash existing ecash in. -Allen

1 0

Re: SEVERE undercapacity, we need more remailer servers FAST
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 6:07 AM 5/20/96, E. ALLEN SMITH wrote: > What countries are noticeable for being anti-Scientology? They would >appear to be good locations for special-purpose remailer ultimate-output ends. But any country that is "anti-Scientology" is likely to be repressive in various ways we would find inimical to our goals. Germany is a prime example: yes, they have placed restrictions on the CoS, but they have also ordered crackdowns on Internet sites. Whatever one may think of Scientology, or Catholicism, or Baalism, or whatever, crackdowns by the government ("anti-Scientology," "anti-Catholic," etc.) is not a good thing. (The issue of how believable the claims of CoS are is no more relevant than similarly outlandish claims that taking communion is eating the flesh of JC. And the issue of CoS seeking legal actions against those they claim are violating their copyrights is separable from their religious status. As I have said many times, "Newsweek" would likely take similar actions in similar circumstances.) --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: The Crisis with Remailers
by lcs Mixmaster Remailer 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > not!!! I should have made this clear, but imho no matter how favorably > the public sees anonymity, I still believe there will be little > incentive to run remailers until there is some kind of ecash > scheme. I hope this is not true. Some of us simply believe it is important to help people with unpopular opinions speak without fear of harassment. I for one will continue to operate a free remailer even if the technology becomes available to charge for the service. I hope others will, too. Some people do care about things other than money. I hope the reason there aren't more remailers out there is simply that it is sort of a pain to set one up, rather than simply because nobody cares. > >People seem to forget that anyone can drop a letter into the mailbox with > >no return address. Did the Unabomber bring negative publicity to the > >postal service, causing people to demand that return addresses become a > >requirement? :-/ > > agreed, but the subject at hand was not whether anonymity is good or bad, > but whether there is some incentive to run remailers. Well, wanting there to be remailers is a good incentive to run one. Another good incentive is if you ever want to send a truly sensitive anonymous message. If you chain through your own remailer, then you can be absolutely sure that at least one remailer in your chain is not run by "bad guys." > I would be interested if any longtime remailer operators posted > statistics about the amount of mail going through their services. Usage statistics are publicly available from mixmaster remailers by sending mail with subject "remailer-stats". Whenever I've checked, the number of messages through the lcs mixmaster remailer has been around 300/day. This is neither a longtime remailer nor a particularly accurate statistic, but it should give you some idea. mix-admin(a)anon.lcs.mit.edu -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMZ//ZETBtHVi58fRAQHePQP+JQcCu/zDfhRB1BLOea+OSENfM6qRxj0h KlYtV5O+IgcmlfZ+vupbtds6IrL8GN5YAQ7kpLoSCIUPC3+r4X0ppJjqgETEYI23 cJoZU9tG3Csj+KNSRn7tDjXdPFcGooqemvhV5SERiQEkAYqzRBDCcd7VQTOGgls5 TTRHxUQ1F+c= =DOAo -----END PGP SIGNATURE-----

1 0

Re: Rumor: DSS Broken?
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 8:05 PM 5/19/96 -0800, jim bell wrote: >At 08:33 AM 5/19/96 -0400, Robert Hettinga wrote: >>At 9:41 PM -0400 5/18/96, Bill Stewart wrote: >>> MD5 is at least weakened, maybe broken; there's an abstract by Hans >>>Dobbertin >>> that says something about generating collisions, and gives an example >>> (though the abstract doesn't say how general the method is.) >> >>That's what I get for not reading the DSS stuff when it came out. I'd heard >>lots about the MD5 stuff, but I didn't put the two together. >> >>It also looks like I'm behind in my reading. Time to buy another edition >>of Applied Cryptography... > >It should occur to all of us that if the NSA was actually doing the job we >are vastly over-paying them to do, it is THEY who should be finding, >exposing, and correcting these kinds of cryptography faults. Has anybody >ever heard any evidence that the NSA has ever acted in this sort of >responsible role? I was rather impressed by NSA's role in the creation of DES. The strengthened it against an attack which was not publicly known, and didn't, in the process, reveal the attack. (See AC2.) ------------------------------------------------------------------------ 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

1 0

CAPITALISTS' SUCK
by qut＠netcom.com 17 Dec '03

17 Dec '03

! Date: Sun, 19 May 1996 20:28:04 -0400 ! From: "Perry E. Metzger" <perry(a)piermont.com> ! ! >Dave Harman writes: ! > ! > CAPITALISTS' SUCK ! ! What witty social commentary. Information wants to be free.

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