- cypherpunks-legacy - lists.cpunks.org

Re: Anti-Spam Methods
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- Nathan Zook writes: > Ivan Boskey? (sp) "Boesky" [...] > We are capable of controlling mail bombs, for instance, in the > following way: > > Take an incoming message, capture From: line. Strip header. MD5 body. > Add to sorted table [From: MD5(message) date]. Check for repetition of > first two fields. If reps = 1, forward message. If reps = 2, send message > to From: "Possible error. Two copies of message <message> received." We were just discussing this on the remailer operators' list. Homer was mulling over sending an automatic acknowledgement of each article submitted for anon posting. I pointed out that From: lines (and even From lines) are notoriously unreliable. For example, in the Scythe spam, the articles were ostensibly from various people @crl.com. Autoacks might have raised the ire of plenty of people, but wouldn't have reached the real perpetrator. > If reps = 0 mod 5, send letter to postmaster@From:. "Possible mailbomb or > spam. <reps> copies of <message> received from <From:> at your site in the > past week." Clear table of entries more than a week old every midnight. This would necessitate keeping full logs of all traffic passing through the remailer for up to a week. Speaking only for myself, I can't imagine adopting such a remailer policy. YMMV. > If all remailers did this, then no matter where the net was entered, > the messages would be rejected. And spammers/bombers would be spamming/ > bombing their own postmaster. Again, in a forged-spam case like Scythe, the spammers/bombers would be inducing the remailers to spam/bomb some arbitrary postmasters -- perhaps even the remailers' postmasters -- as a side effect. A "call-back" scheme might, however, be used to verify an originator's address. In this scheme, when a remailer receives a message for remailing, it generates a few lines of random garbage and associates them with the message. These lines are sent, along with a hash of the original message, in a brief ack message to the address in the From: line of the message. The headers of the message are discarded. When the remailer receives a message with a Callback: header, it checks the reply against the table associated with the current message pool. If a match is found, the associated message is marked ready for remailing. After a fairly short period, a message which still hasn't been marked for remailing is deleted. With chaining, more record-keeping by the remailers would be needed. The remailers can't automatically honor all callbacks from other remailers, because wise forgers would simply forge their mail so it appeared to originate from some known remailer address. So each remailer would need to keep (for a brief period) a hash of each message it remails, in order to decide which callback queries to answer. A list of current remailers could be used to winnow out messages which are not being remailed to other remailers, and hence need not be hashed and kept. This protocol would aid a remailer operator who decided to trace a spam in progress, because it should prevent spammers from forging their messages. Couple this with mandatory appending of encrypted reply blocks, and the release valve of two-way communication might be opened. Legal proceedings obviously can't be brought successfully against anonymous parties, so achieving common carrier status is about the only antidote to that problem I can foresee at the moment. I'm thinking about working on code to implement some of this stuff in existing remailer software, so I'm especially interested in hearing objections, flames, suggestions, encouragement, etc. about it. I've spent a while contemplating the wants and needs of prospective benign remailer users -- market research, if you will. At this point, I think patching together various pieces of existing remailer technology might greatly improve the attractiveness of the c'punks style remailers. -L. Futplex McCarthy; PGP key by finger or server "The objective is for us to get those conversations whether they're by an alligator clip or ones and zeroes. Wherever they are, whatever they are, I need them." -FBI Dir. Freeh - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLx4/Tmf7YYibNzjpAQGcHgP+Nmo+c/Cfdul7HsZGOXR+cP+rmAVP1tRB 6PZcm/PDycd9HBTYqhraPsmwn7OGbqnWTeF0O5AitGSnwdG5o8+sSdUJ+KfJ1AcQ tcyBFlvk9Rh/UIuzksUOeY935CVMA0nEmiXLoyJnnpiRoThctd/yILd8V+qiQ1pK 46j6Y7WeK5E= =vUEc - -----END PGP SIGNATURE----- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLx5AZCoZzwIn1bdtAQE70wF/dta1dAuc7yWpkqkK2asa+9V/H3zN/cPI vGyOSZMIvRCcAGLgSCUwZes+e3l7ETnZ =2HOy -----END PGP SIGNATURE-----

1 0

Re: EE Times on PRZ
by jalicqui＠prairienet.org 17 Dec '03

17 Dec '03

Strick wrote: >THUS SPAKE jalicqui(a)prairienet.org (Jeff Licquia): ># Another quote from the article posted elsewhere said that, "PGP, which is ># based on the Diffie-Hellman public-key technology developed in the 1970s..." ># This is technically true, since all public-key work (including RSA) is based ># to some extent on DH. It could be, however, that the author is confusing > >DH uses "discrete log" as the hard problem, and very straightforward >mathematics. > >RSA uses "factoring" as the hard problem, and a very clever back door. > >How do you decide if one is based on the other? Sorry, I wasn't perfectly clear. Of course, RSA is not based on Diffie-Hellman specifically; what I mean is that all public-key work is based on that general paper, which "invented" public-key cryptography. I think this very confusion may be plaguing the writer of the aforementioned article. ># public-key technology with Diffie-Hellman public-key in particular, which ># (as I understand it) is not particularly secure. > >It's still up in the air, isn't it, whether the discrete log or >factoring is the harder to crack. My intuition is they're the >same hard. It was my impression that DH had a further weakness not related to the difficulty of the hard problem. As my copy of Schneider is at home, I must defer to ignorance at this point.

1 0

Factorisation and Discrete Logs (was Re: EE Times on PRZ)
by dwa＠mirage.svl.trw.com 17 Dec '03

17 Dec '03

strick wrote: > > DH uses "discrete log" as the hard problem, and very straightforward > mathematics. > > RSA uses "factoring" as the hard problem, and a very clever back door. > > How do you decide if one is based on the other? > > # public-key technology with Diffie-Hellman public-key in particular, which > # (as I understand it) is not particularly secure. > > It's still up in the air, isn't it, whether the discrete log or > factoring is the harder to crack. My intuition is they're the > same hard. > > I know of no problem with DH that RSA doesn't have similar problems. > > strick It seems to me that factoring a large number is no harder than finding a discrete logarithm. Assume, for the moment, that an efficient method of computing discrete logs has been discovered, rendering systems like Diffie-Hellman key exchange unusuable. I contend that RSA is now equally unusable. The following variant of the Pollard p-1 method should provide an efficient factorisation method for an RSA modulus, say N. Choose, at random, "a" such that gcd(a,N) = 1. Compute x such that: a^x = 1 (mod N) [ Discrete log time! ] Partially factor x; say x = f * f * f ... where f is not necessarily prime. 1 2 3 n Note that it is usually easy to partially factor a "random" large integer. Simply using trial division up to some limit; or, at worst, pollard rho or pollard p-1 (on x) should suffice. If you're truly unlucky, pick another value for a. Compute: M = a^(10000! * f) (mod N) Where f is some partial factor of x. gcd(M-1,N) should yield a non-trivial factor of N. If it doesn't, another choice of f and/or a should work. I'm by no means a professional mathematician, but it seems that this scheme should work. Comments, anyone? Dana W. Albrecht dwa(a)mirage.svl.trw.com

4 3

Re: Judges-L FAQ
by jrochkin＠cs.oberlin.edu 17 Dec '03

17 Dec '03

At 3:43 PM 02/08/95, Craig A. Johnston wrote: >It has come to my attention that the Judges-L FAQ is being distributed >by someone who obtained it on this list, and being sent to people made >to look as if it has issued from David Stodolsky. > >I must inform you that this FAQ is copyrighted material, and >you are requested not to distribute it. Huh? What kind of an FAQ is it, that can't be freely distributed? If you don't expect people to redistribute the text, don't call it an "FAQ". The phrase "FAQ list" is understood internet-wide (or at least usenet-wide) to mean a freely distributable list of information someone might want on a certain topic. (It doesn't neccesarily mean "Frequenty Asked Questions", literally, these days. Cause there are often FAQs distributed that just contain general information on a certain topic, but not actually questions that have ever been asked before. The Judges FAQ might be a good example.) If you don't want people to redistribute the thing, the really should change it's name. And write very explicitly at the top of the document that no one should copy it without permission of the author. These things just aren't generally supposed to be true of FAQs.

1 0

Re: Not necessarily crypto but scary anyway...
by droelke＠spirit.aud.alcatel.com 17 Dec '03

17 Dec '03

> > On Wed, 8 Feb 1995, Ben wrote: > > > On Wed, 8 Feb 1995, root wrote: > > > > A friend advises me that today House Bill 666 passed. This supposedly would > > > allow police officers to use evidence collected illegaly if they 'believed' > > > that it was collected in good faith. > > > This sounds like a spoof. Look at the number. > > Unfortunately, it is not. World Wide Web yourself over to > http://thomas.loc.gov/ and search for hr 666...you will find it. > > "A Bill to control crime by exclusionary rule reform..." maybe if > "control" means "aiding and abetting" > > -Thomas > I haven't looked it up yet, but I did hear about the bill on news last night, so I would say it is legit. The number of the devil indeed. ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX http://spirit.aud.alcatel.com:8081/~droelke/

1 0

S.314 on Web
by Richard Martin 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The text of S.314 (the pi bill, as Doug pointed out to me earlier today -- why I didn't realise earlier...) is available at http://baldric.resnet.cornell.edu/frodo/s.314.txt.html with a rapidly hypertextified version of Slowdog's text on what the bill will do to American law at http://baldric.resnet.cornell.edu/frodo/s.314.changes.html If there are errors or omissions, please tell me. If the URLs are wrong, the failsafe is my homepage, http://baldric.resnet.cornell.edu/frodo/frodo.html which has links to both. (Really. They're there. There's some bumf about me. But the links are there.) This may be useful to some. I find it handier to have it there than in an odd text file lying around here. frodo =) Richard Martin ChemPhysCompSci 9T7+PEY = 9T8 g4frodo(a)cdf.toronto.edu Trinity College University of Toronto SVW92 martinrd(a)gpu.utcc.toronto.edu My opinions, when not poached. (or fried) frodo(a)uhura.trinity.toronto.edu -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBLzqwH6+lG3+zwTCVAQEGfwP+MOSWEAB2kbbabdai/y3o6QIDIWNefRle UPTCVyqadfIIs7s8bJjymlJs/OCutm76Pdfst8U40Tpi4DcE6NGyuLe9TauHkQEf +wFtgOYrju35YV/pdiXvIBmdnv8etthbtLA+b0KcaRVEKXVYP2NsZ7+WBT/gAVV1 XPbBwe1UJXw= =kaQ8 -----END PGP SIGNATURE-----

1 0

Crusade's End
by Nathan Zook 17 Dec '03

17 Dec '03

Date: Wed Feb 1 20:35:31 1995 From: Rick Busdiecker <rfb(a)lehman.com> Date: Wed, 1 Feb 1995 18:59:54 -0600 (CST) From: Nathan Zook <nzook(a)bga.com> Instead of routing all of those messages to /dev/null, forward them back to the authors, perhaps with a notice that the message appears to have been mistakenly routed to you? And then all LD has to do to have lots-o-fun is to send you a whole bunch of "your OS sucks" messages with the From: line set to alt.religion.scientology(a)some.mail2news.site . . . . Rick Presumably, this sort of censure would occur very rapidly. The script had specific from/to lines it was looking for. Neat idea, though. Nathan

1 0

re: Remailer Encryption Module
by Nathan Zook 17 Dec '03

17 Dec '03

From: eric(a)remailer.net (Eric Hughes) From: Nathan Zook <nzook(a)bga.com> I also believe that hacking PGP is a bad thing (tm), because it means that every time an upgrade comes out, it will need to be re-hacked, and once you start hacking, when do you stop? I agree. PGP just does not have the support for the encryption required for mixing remailers. These deficiencies have been known for about two years at this point and still nothing has happened. I expect this not to change anytime soon. That means that we have to replace PGP as the encryption module for remailers. The first thing to do is to design a data format which supports what the remailers need now, and nothing speculative. Since this data format has a single purpose, we can make new revisions more easily than for a general purpose package. Once we get a data format, implementations will follow. Eric As I've considered this problem, I've arrived at essentially the same conclusion. We need an RSA-IDEA package that does something very close to Mixmaster. The only caveat is that we _must_ retain compatibility between signature formats, even though, as I've suggested, a signature on a remailer's key might mean something different than a signature on an individual key. Nathan

1 0

COO_kie
by John Young 17 Dec '03

17 Dec '03

2-12-96. FinTim: "This bug in your PC is a smart cookie." Netscape Navigator contains a little-known wrinkle that increases the power of companies to find out who their customers are and what they are up to. It allows companies to track which Web pages an individual looks at, when, for how long, and in what order. The information is stored on the customer's computer as "persistent client-state hypertext transfer protocol cookies". 2-12-96. WSJ: "Consumer Privacy on Internet Goes Public." The advertising industry's response to the volatile issue of consumer privacy is drawing howls of protest from consumer advocates. The battle is over what should marketers be allowed to do with personal information they gather from consumers visiting Web sites. Marketers "want to have dossiers on people with incredible detail so they can pick and choose what they send to you." "Invention Machine's Software Wins Orders for Picking Brains of Inventors." A software program is being snapped up by a growing number of America's biggest companies to provide inventing partners for their engineers. The program codifies the invention principles behind some two million international patents and the inventive techniques of some of the world's greatest inventors. Mr. Tsourikov said the product grew out of his early studies under Genrich Altshuller, who posited that invention isn't a random process but has a certain algorithm which drives it. COO_kie

2 1

Threat models. [was: Why encrypt intra-remailernet]
by Nathan Zook 17 Dec '03

17 Dec '03

> From: Nathan Zook <nzook(a)bga.com> > > When I say that the Mark I remailers are laughably easy to crack, I mean > laughably easy. > > By whom? I am hearing a general denunciation of the current remailer > system. These blanket denials are false on their face, because they > are not true in every circumstance. > By anyone with the resources to snoop up- and down- stream of all the remailers. > The only reason that our systems are actually able to do any good is that > our threat model _is not_ an LEA--with government resources, and government > patience. > > _Our_ threat model? > > There is not one threat model. Each person has their own threat model > and their own desired level of security. An individual also desires > more security for some messages than others. The current remailer > network is good for some purposes and bad for others. > > Every evaluation of security _must_ include the nature of the security > desired, because there is no single concept called "security" which is > the same in every situation. > > Eric Yes, but... The very act of going to the trouble of using these remailers means that you are dealing with someone powerful enough to read past forged From/From: lines. Does it take that much more to snoop these sites? My gut says no. Everybody harps chaining. Does snooping take more effort than compromising? I think it would be hard indeed to say so. So if we think Eve can compromise some remailers, and/or read past From/From: faking, we are, I believe, forced to believe that Eve can snoop all the remailers. Threat models need to be uniform in the power of the opponent. Nathan

1 0