- cypherpunks-legacy - lists.cpunks.org

Re: remailer spam throttle
by Hal Finney 17 Dec '03

17 Dec '03

dlv(a)bwalk.dm.com (Dr.Dimitri Vulis KOTM) writes: > With the present scheme, if a remailer is "raided", it has precious little > interesting stuff on it at any one time. Now consider the scenario: > > X sends 1000 copies of child porn/seditious libel to 100 people believed not > to be using remailers right now. The remailer keeps the 100 e-mails onits > hard disk and e-mails each receipient a ping, inviting them to agree to the > disclaimer terms and to retrieve their anonymous e-mail. The first recipient > to retrieve the e-mail gets upset and contacts the feds. The feds figure, the > remailer still has the 99 other e-mails and the information on who's supposed > to receive them in its queue; why not seize it and take a look. This is a potential problem, but there are some other considerations. First, there is no particular reason why one recipient of some email from the remailer should know or even suspect that other people have the same email waiting. Then, to defend against raids like this, the material could be separately encrypted to each recipient. There would be no way to know that material sent to one recipient matched material sent to someone else. The raiders would just find a bunch of encrypted files. Of course, if it were a sting operation, with the recipients being lured or entrapped into requesting information they shouldn't, then the sender might avoid using these countermeasures. However, there wouldn't really be any need to use a remailer for a sting operation like this, it could be done just by offering the material from an ordinary address. More generally, I think we need to keep in mind what a remailer does and what it doesn't do. The essential function of the remailer is to provide anonymity via mixing messages. It does not provide confidentiality of message contents. That has to be taken care of by encryption. And, as I wrote yesterday, it doesn't (can't) keep secret who the people are who send and receive anonymous mail. All it can do is to disguise which particular people send and receive to each other. The same is true of a DC-net or a perfect Chaumian mixnet. These systems do not disguise their particpants, or protect the confidentiality of their message contents; they only hide the knowledge of who is talking to whom. Having said that, I do like some aspects of this idea: > There's a big distributed database of pgp keys on the several keyservers. > Add a bit to the database specifying whether the key owner wants to receive > anonymous e-mail. By default set it to true for the existing addresses. (The "default true" is going to allow the same kinds of abuse which we have seen in the past. Some remailers may be able to tolerate this, but as we have seen, many can't.) > When the final remailer in the chain wants to send someone an anonymous > message, it attempts to retrieve a key from the keyservers. > > If it fails to find a key, it junks the mail (you don't want to keep it > around, it's baiting the LEAs!) and instead sends a notification to the > recipient that some anon e-mail was addressed to it, but it was junked; > and if they want to receive anon e-mail, they need to give a pgp key > to one of the key servers this remailer uses. This is what I like. It's a lot simpler than trying to keep a copy of the anonymous mail and deliver it later when the person asks for it. Just let him know that someone is trying to reach him anonymously, and let him enable that if he wants to be able to receive the next anonymous message that comes in for him. You can load his permission message down with all kinds of disclaimers that say he knows he's likely to receive obscene, threatening and illegal material, that he doesn't mind, that he knows the remailer is an automated system which doesn't look at the contents, etc. Not only does this give you a defense but it makes the person think about what he's getting into, so he will in fact be better prepared when something bad comes his way. Plus, having taken positive action to enable receiving anonymous mail, he will hopefully be more knowledgable about how to request that you stop, and it won't be such a big deal. He opens the pipe, and if he gets a face full of sewage, he closes up the pipe right away. You warned him. > If it finds a key, it looks at the anon mail bit; if it's on, it encrypts > the e-mail with the recipient's key and sends it; otherwise it junks it. > > Obviously, the key servers would need to be modified to allow users to > specify whether they want anon e-mail when then store their keys, and > to change this setting any time. Key servers wouldn't be the only place to store this information. I think the remailer could keep its own list, especially if it were defaulting to "off". This way recipients wouldn't have to generate and submit PGP keys, which is more work than just sending a reply to a remailer giving the OK to receive anonymous mail. > Right now, there's a very large number of addresses in the key servers. > Instantly making them into a list of addresses that accept anon mail > will make it hard (hopefully infeasible) for the LEAs to investigate > everyone willing to accept anon e-mail as a suspect in sending it. More cautious or politically vulnerable remailers might default in the other direction. It would be a matter of the individual situation. Hal

2 1

Re: PKC
by lucifer＠dhp.com 17 Dec '03

17 Dec '03

Warning: if you fuck Tim Maya in the ass, a rabid tapeworm might bite your penis. /\ _ /\ | | 0 0 |-------\== \==@==/\ ____\ | \_-_/ _|| _||

2 1

Re: remailer spam throttle
by Bill Stewart 17 Dec '03

17 Dec '03

>From a legal perspective, Greg is right. However, from a practical perspective, the important impediments to running remailers are (1) mail recipients hate you and send lots of complaints and (1a) usenet readers hate you and send lots of complaints (if you still support news posting.) Andy's model of a remailer in which the remailer sends the recipient a delivery notice with a disclaimer/waiver/etc. and the recipient returns it to pick up the message raises the level of politeness and lowers the amount of surprise compared to current remailers, so it's a potentially big win. If I start up a remailer again some year, other than a middleman, it'll definitely need this kind of feature. Building the positive public reputation of remailers and remailer operators is a critical part of keeping the remailer system running, at least as much as convenient, widely-deployed software. For posting to Usenet, the "we have an anonymous posting, anybody want it" approach doesn't sound highly practical, though it could be done, but I'd probably limit postings to moderated newsgroups (where a human will be filtering out the blatant spam and abuse) and flame-tolerant newsgroups like alt.anonymous.messages and alt.flames. I find this highly frustrating, since one of the big wins about remailers is posting to talk.politics.* and alt.religion.scientology and other groups where posting your opinion with your name on it may be unsafe. There's also the problem of publishing acceptable newsgroup lists, since failing messages silently is unfriendly to users, but there's a traffic analysis problem (Bad Guys can watch who fetches remailer use policies and build up their dossiers.) Most of the problem with (2) Third Parties _can_ be helped a bit by disclaimers, by plausible deniability, by not having logs to subpoena, and by having remailers that you're willing to shut down with profuse apologies to head off lawsuits. It isn't a perfect job if someone really wants to go for blood by making you defend repeated lawsuits (especially if they're really targeting you, e.g. posting their Secret Documents through your remailer themselves to entrap you.) But it'll let most remailer users defend against most reasonable complaints. I do also agree with Greg that getting the sender of a message to indemnify you isn't worth the recycled electrons used for the log file you aren't keeping. That's especially the case if you're forwarding messages received from other remailers, unless you can get other remailer operators to indemnify you, in return for which you'd probably have to indemnify them. No thanks. At 01:58 AM 3/25/97 -0800, Greg Broiles wrote: >I think there are two broad models of complaints/problems with remailers: >1. The recipient is angry because they received a message they didn't >like. (because it's an advertisement, or it's rude, or [....] >2. A third party is angry because the sender sent some information to the >recipient which the third party thinks should not have been sent. >(copyright, >trademark, defamation, tortious interference [...] >Your "contract" model (which looks like you really mean it to be a >waiver of warranty/damages and/or an indemnification agreement) >addresses (1) to the point of overkill, but it doesn't reach (2), >because there's no contract with the third party, who is the party who's >likely to be filing suit. >(Indemnification by the sender might work, if you worded the contract >correctly - but then you've got to abandon anonymity, and the value of >indemnification from person you don't know whose assets/finances are >unknown is pretty low.) > >Further, some fraction of the messages causing concern are message sent >or available to minors .. whose contracts (modulo some exceptions) are >voidable at their option. :( >>..[disclaimers].. >[doesn't help 2 for same reason] # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)

2 1

OECD: No GAK
by John Young 17 Dec '03

17 Dec '03

The New York Times, March 27, 1997, pp. A1, D3. U.S. Rebuffed in Global Proposal For Eavesdropping on the Internet By John Markoff In a setback for the Clinton Administration that demonstrates the difficulty of setting global policies for the Internet, the leading industrial nations have declined to embrace a United States proposal to allow computer eavesdropping by the world's law enforcement agencies. The United States proposal, backed by Britain and France, was an attempt to restrict the private use of increasingly advanced data-scrambling technology that can protect the privacy of electronic mail and other forms of computer communication. The equipment can make it difficult for law enforcement officials to crack a code when they suspect it is masking criminal or terrorist activities. The proposal called for international endorsement of a system in which mathematical keys to computer-security codes would be held by escrow agents from whom law enforcement officials could obtain the keys once they have a court's wiretapping warrant. But policy guidelines scheduled to be released in Paris today by the 29-nation Organization for Economic Cooperation and Development fail to endorse the United States proposal. And they leave such leeway for members to regulate data-scrambling technology--or not--that computer security experts say any uniform international policy remains elusive. "The difficulty with the guidelines is that anybody can interpret parts of them in their own way," said Konstantine Papanikdaw, a policy analyst for information security at the European Commission in Brussels. Indeed, the industrial world seems to be deeply divided on whether governments can ever legitimately eavesdrop on the electronic communication of their citizens. Because messages on the Internet are easy to intercept, a growing number of individuals and corporations are protecting the privacy of their communications and the security of their commercial transactions by scrambling such information. Some O.E.C.D. nations, including Britain and France, have either outlawed or are in the process of tightly regulating the private use of data-scrambling systems. But other nations--including Australia, Canada Denmark and Finland--have policies that protect individual privacy. Among other member nations, Japan had initially resisted the United States proposal but was said to be moving closer to it, while Germany remained deeply divided. Most other countries, inside or outside the O.E.C.D., have yet to confront the data-scrambling issue. And even the United States has a somewhat contradictory national policy that permits citizens to use whatever data-scrambling software they wish within the nation's borders, but restricts the export of the most up-to-date computer-coding technology. That seeming contradiction, however, did not prevent the Clinton Administration in recent months from waging a vigorous behind-the-scenes effort for its proposal. And hoping to resolve some of the policy conflicts, the Administration is now circulating draft legislation on Capitol Hill which would attempt to control even the domestic use of data-scrambling software and establish a key-escrow system for the United States. While the O.E.C.D. has no authority to set international policy, its recommendations are frequently used by member nations in setting their own foreign and trade policies. And the privacy and law-enforcement aspects of the Internet are issues on which member governments have been desperate for guidance. But even though most of the O.E.C.D. discussions involved law enforcement officials, who have been the main advocates for measures that would insure their ability to crack codes, European officials say that there was never much agreement on what to do. And so the primary recommendation in the report, a copy of which was obtained by The New York Times, simply gives O.E.C.D. member nations the latitude to do as they see fit when it comes to data scrambling, which is formally known as cryptography. "National cryptography policies may allow lawful access to plain text, or cryptographic keys, or encrypted data," the report says. Privacy-rights advocates see the O.E.C.D. guidelines as a critical setback for the Clinton Administration. "The U.S. proposal to endorse lawful access to private keys was explicitly rejected by the O.E.C.D. member countries," said Marc Rotenberg of the Washington-based Electronic Privacy Information Center and a member of the O.E.C.D.'s advisory group. "The O.E.C.D. chose instead a policy based on voluntary, market-driven development of cryptography products." And even supporters of the United States position acknowledged that guidelines were a disappointment. "The United States probably had more success raising consciousness then getting language that could he treated as an endorsement for key recovery," said Stewart Baker, a former National Security Agency official who participated on the American delegation to the O.E.C.D. Meanwhile, executives for the United States computer industry were critical of the O.E.C.D. for even leaving the door open for governments to set national policies on data scrambling. "We think that markets, not governments, should be the primary determinants of technology solutions," said Jon Englund, a vice president at the Information Technology Association of America, a trade group. Many experts question whether governments can ever hope to insure law enforcement access to electronic messages or to restrict the spread of super-strong coding software, because new, more powerful versions can always be developed and easily transmitted over the Internet in the blink of an eye. And any international effort is almost certainly doomed if some countries refuse to go along with a common approach, because people looking for strong encryption can simply acquire it wherever the laws are lax. In fact, the big German company Siemens A.G. recently introduced an encryption system that it advertises as being much more powerful than American companies can export under United States law. Besides the United States, France and Britain both support a system for enabling law enforcement officials to obtain keys to data-scrambling codes. France has already passed a stringent law that requires participation in such a system, although the rules to carry out the law have not yet been worked out. And in recent days, Britain has quietly circulated the most restrictive proposal of any nation, a domestic policy under which the Government would allow private use only of cryptography that was officially licensed, to make sure that the software uses code that law enforcement officials can crack. Under such laws, of course, criminals and terrorists might logically choose to use unauthorized encryption software. But the mere fact that such use would be a crime may be a deterrent--or give the police grounds to arrest anyone whose communications were indecipherable. In Germany, encryption remains a deeply divisive issue. The Interior Ministry has supported the need for encryption restrictions of some sort, but the Justice Ministry and the Economics Ministry have both signaled their opposition. And German businesses have been outspoken opponents against any new restrictions on data scrambling. Meanwhile, United States export restrictions have been a boon for Brokat Informationssysteme G.m.b.H., a two-year-old start-up company in Boblingen, Germany. Brokat supplies secure electronic transaction software for banks like Deutsche Bank and on-line services like America Online in Europe. One of Brokat's hottest products is the Expresso Security Package which essentially adds strong encryption to the World Wide Web browsers and Internet server software sold by two of the largest American software companies-- Microsoft and Netscape Communications. [End]

3 2

Re: [Proposal:] Revolving Web Mirrors
by Toto 17 Dec '03

17 Dec '03

Bill Stewart wrote: > > >> Maybe a mailing list/news group that could > >> post current URL's for the mirrors? > > Having the pattern matcher look for (and delay) potential mirror lists > is more productive, since you can catch them at the Nationalist Firewall > before they get into the country. Maybe. If readers know what to > look for in their news postings, censors probably do to. > > Email is tougher - the Bad Guys don't need to find the source of the > mirror listings (presumed to be in a non-cooperative country, > if you can find it at all) - they can find the recipients of the lists, > and go beat them up. Maybe it's time to set up an "InterNet Free Europe" type of program. Crypto and remailers seem to be well-suited to the task of implementing the dissemination of information and protecting identities of the many individuals who would be involved. CyberHackers could compromise a few systems, to turn them into innocent remailers, and this would open the door for the administrators of other systems to 'fake' system attacks, and do some remailing themselves. CryptoRebels could disseminate encryption programs containing the public keys that would be used for the InterNet broadcasts in certain cases. One of the keys to "InterNet Free World" (a better name?) would be to make a habit of disseminating a plethora of 'false' encrypted messages with little or no meaning, and no available key, as a cover for the messages that are actually targeted for certain users or systems. -- Toto "The Xenix Chainsaw Massacre" http://bureau42.base.org/public/xenix/xenbody.html

1 0

MC / My Computer?
by lucifer＠dhp.com 17 Dec '03

17 Dec '03

1 0

Re: KRAP
by Alan Olsen 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 05:21 PM 3/26/97 -0600, Toto wrote: >Jeremey Barrett wrote: > >> > Key Recovery Agents Plan > >> I dunno, but they couldn't have picked a better acronym :-) > > Good eye. I read about it and never noticed their >truth-in-advertising acronym. > > You are hereby awarded 50,000,000 Toto Eca$h credits. > (1,000,000,000,000,000,000 = 1 peso) Actually the anacronym was posted a couple of months ago. (Check the archives, if they still exist.) In the original posting, I pointed out that if they are the Key Recovery Alliance, then what they produce mut be Key Recovery Alliance Products (aka KRAP). But then that was on a parellel universe/listserv. -----BEGIN PGP SIGNATURE----- Version: 4.5 iQEVAwUBMzqe2OQCP3v30CeZAQGK1Qf9HTYic3rKPZMVqd2uyfUbGTIP9J1vXF1X h4ikOzKUR5gf3vhRDzxdViEA/KcE/4neXgZZe2tpB/H5XEiPhxMg5IksyXhSTgDx hC+9kpRMlO7hj8JxHA3dtsqzZjUSdt3ws8YjfmXaz/76HBG9FpAYNyYg7xBheYd/ 5J4mfSQS5cn2libq0B1gAnDxWROJ6NxywpD8fVq46JoxE+vJdUtR2CRkOe4HOvbr Zh98FBx6VH1i1xUo6LDlrqI3YLm6VfAjrhOU6wTImiSnuZdh276cbR1FtqQxdz8o X01W2Agug/UaEtnXYnzXxkFuIU8AB46z4nDTj3ZTlKw7fmJCYAWIXw== =skFo -----END PGP SIGNATURE----- --- | "Mi Tio es infermo, pero la carretera es verde!" | |"The moral PGP Diffie taught Zimmermann unites all| Disclaimer: | | mankind free in one-key-steganography-privacy!" | Ignore the man | |`finger -l alano(a)teleport.com` for PGP 2.6.2 key | behind the keyboard.| | http://www.ctrl-alt-del.com/~alan/ |alan(a)ctrl-alt-del.com|

1 0

Higher Sources / Index
by Bubba Rom Dos 17 Dec '03

17 Dec '03

1 0

Heaven's Gate / Main
by Bubba Rom Dos 17 Dec '03

17 Dec '03

1 0

[NTSEC] CIFS Authentication Protocol Errata (fwd)
by Ray Arachelian 17 Dec '03

17 Dec '03

=====================================Kaos=Keraunos=Kybernetos============== .+.^.+.| Ray Arachelian | "If you're gonna die, die with your|./|\. ..\|/..|sunder(a)sundernet.com|boots on; If you're gonna try, just |/\|/\ <--*-->| ------------------ |stick around; Gonna cry? Just move along|\/|\/ ../|\..| "A toast to Odin, |you're gonna die, you're gonna die!" |.\|/. .+.v.+.|God of screwdrivers"| --Iron Maiden "Die With Your Boots on"|..... ======================== http://www.sundernet.com ========================= For with those which eternal lie, with strange eons even death may die. ---------- Forwarded message ---------- Date: Wed, 26 Mar 1997 23:21:52 -0800 From: Paul Leach <paulle(a)microsoft.com> To: "'cifs(a)listserv.msn.com'" <cifs(a)listserv.msn.com>, "'WWW-SECURITY(a)ns2.rutgers.edu'" <WWW-SECURITY(a)ns2.rutgers.edu>, "'NTBUGTRAQ(a)RC.ON.CA'" <NTBUGTRAQ(a)rc.on.ca>, "'ntsecurity(a)iss.net'" <ntsecurity(a)iss.net> Subject: [NTSEC] CIFS Authentication Protocol Errata Sharp eyed reviewers have already caught the following errors in CIFS-Auth (CIFS Authentication Protocol), draft 3. A new version will be forthcoming shortly. In paragraph 2 of section 1.1, it should say: The response is computed by DES encrypting a challenge (a nonce) selected by the server with three keys derived from the user's password. In section 1.2, [s]<n:m> be the "n" bytes of s starting at byte "m". should be clarified to be: [s]<n:m> be the "n" bytes of s starting at byte "m" (the first byte is numbered 0). In step 1 of section 1.4, was: Kb = [Ks]<7:8> Kc = [Ks]<15:2>, Z(5) should be: Kb = [Ks]<7:7> Kc = [Ks]<14:2>, Z(5) In step 4 of section 1.4 was: Kb' = [Ks']<7:8> Kc' = [Ks']<14:2>, Z(5) should be: Kb' = [Ks']<7:7> Kc' = [Ks']<14:2>, Z(5) and Km' = Ks, R should be Km' = Ks', R In step 6 of section 1.4, C: MS' = [MD5(Km, SN, Msessr, CC, CS)]<8> should be C: MS' = [MD5(Km, SN, Msessr,)]<8> In step 2 of section 1.5, there is a missing right bracket: S->C: Mrsp, [MD5(Km', SN', Mrsp)<8> should be: S->C: Mrsp, [MD5(Km', SN', Mrsp)]<8> > ---------- > From: Paul Leach > Sent: Tuesday, March 25, 1997 1:18 PM > To: 'cifs(a)listserv.msn.com'; 'WWW-SECURITY(a)ns2.rutgers.edu'; > 'NTBUGTRAQ(a)RC.ON.CA'; 'ntsecurity(a)iss.net' > Subject: CIFS Authentication Protocol Review > > We are releasing preliminary drafts of the proposed fixes to the > CIFS/SMB authentication protocols for widespread public review. If > they pass review, they will be in Service Pack 3 for NT 4.0. > > The original protocol from which the new version descends was designed > more than a decade ago; recently, quite a few weaknesses have been > found in those previous versions. This latest revision is an attempt > to repair those weaknesses with as small a change to the protocol as > possible, so that it can be incrementally and rapidly deployed. > > All three documents are available in .doc, .txt and postscript. > > Information on how to get them is available from: > ftp://ftp.microsoft.com/developr/drg/cifs/sec.htm > > All followup discussion should be on the CIFS mailing list at > CIFS(a)listserv.msn.com. > > Your comments are actively solicited. > ------------------------------ > Paul J. Leach > paulle(a)microsoft.com >

1 0