December 2003 - cypherpunks-legacy

Why encrypt intra-remailernet.
by Nathan Zook 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Lance Cottrell <lcottrell(a)popmail.ucsd.edu> >I agree completely that messages should be encrypted between remailers. >This does raise the issue of keeping a database of all other remailers at >each remailer. Lets settle for encrypting to the next remailer most of the >time. Well, actually, I'm suggesting a database that includes all remailers and all selected users. ICT: in order to beat TA, first or last remailers are going to _have_ to used standaradized, encrypted packets. The remailers are almost secondary here, except that we aren't sure that TA through the net is impossible. Or we could be facists, and _only_ send out PGP-ed, standard sized packets. (Forcing remailer-users to get into PGP.) Something would have to be done about lists & mail-to-news. Is there some difficulty in maintaining a database? Remailers would want to publicize their exsistance. This might involve pinging, but so what? That's just more noise. >The best way to do that is to open a socket between the remailers, and use >DH key exchange (authenticated with RSA?), to generate the encryption key. >This gives forward security to any intercepted messages. It is high on my >list of upgrades to Mixmaster. But doesn't this require a realtime connection to be practical? ie: remailers must be _on_ the net? As far as this all goes, the sender could stick _all_ packets together, PGP the whole thing, and send _that_. This would only require signing once per recipient per tick. T1, anyone? *** P.S. Could you mail me that essay? I'm long distance to the net right now. *** Adam Shostack <adam(a)bwh.harvard.edu> >Nathan Zook: >| >| Suppose Alice sends Bob a message e(M) through Chaum. Eve, a stong >| opponent, wants to trace the message. She keeps track of all outgoing mail >| from Alice, an MD5 hash of all incoming messages to Bob, and outgoing from >| Bob. Eve then sends Chaum e(M), and waits for a matching MD5 to Bob that >| doesn't correlate to an outgoing MD5 from Bob. (Eve knows that Bob is a >| remailer.) >| >| Gentlemen, I believe that I have just stumbled upon a strong proof of >| the necessity of remailer auto-encryption of all messages. Since the >| session key is PRG, MD5 will change (a lot;). Furthermore, remailer auto- >| encryption allows the mailers to number their messages to each other. A >| low number means a re-transmit from the remailer, which is not possible, >| unless some sort of ACK system is in place, and even then, would still >| flag. Of course, if the remailers _sign_ their messages (on the way out) >| as well, you could compare the timestamps of the signatures with the >| message itself. > > This is strong argument for encrypting your chain of messages, >using premail, or chainmail, or something similar. Why the remailers >should do this is not clear at all from your argument. Remailer >operator should be discouraged from cooperation beyond that which is >needed. > >Adam I think that you are missing the attack. Eve wants to prove that Alice sent a message to Bob. By resending Alice's message, it will route through Chaum just fine, producing identical output (message to Bob) as before. Assuming that Eve doesn't intercept the message, stopping Bob from getting it, Bob will know that something is up when he gets the message the second time, but by then it is too late. Eve knows that Alice's message, sent at time X, corresponds to a message received by Bob at time Y. This is exactly the sort of thing that LEAs love to use in building a case. My claim is that the only way to prevent this attack is for Chaum not to send out identical messages if he receives identical messages. Identical, in this case, would include messages identical except for "cryptographically strong random" data tacked on to the end, because if Eve had the storage space, she could compare messages _that_ way, stripping off the end bits, and getting the real message (encrypted) to Bob in the process. The natural way to do this is to super-encrypt. Of course, if Chaum just sends one rather large file to Bob each tick, Eve is hosed. BTW, if Chaum does an MD5-compare of all incoming messages, he can limit a spam to 1 per tick from his remailer with _no_ recordkeeping. Or maybe he could send a bunch of identical garbage messages to a random remailer, 85% of the time.... I really don't see how you can call this "cooperation beyond that which is needed". If the remailers default to strip nested envelopes, and to pad messages to standard sizes, the only "cooperation" between the operators is to publish PGP keys. They aren't "helping" each other, they are helping the end users. But this is all so trivial, compared to arguing operating systems. Nathan Finger or request keyserver for PGP 2.6.2 (tm) key. PGP<->Mail/News installation incomplete. Factors for modulous are not proven primes. Key may be far weaker than expected. Encode at your own risk. Key ID: 14712B4D 1994/12/26 Nathan H. Zook <nzook(a)bga.com> Key fingerprint = 44 B3 D8 66 3D 55 1E 2E F8 92 22 A6 33 8C DE 24 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLywNqHmgMs8UcStNAQEgMAf/U+1rc6/5h6dZZAM9PuAJL0co25yE3JM4 vH3YSmRw31gQdjdRMw36XXZ4OLtTgV3CMBmlu5NoH5m80EAjUji3WCoRwhkin7G9 BgZnXhghR/ceLeE3MgyWZLTtApZkYO+z3zYxm1mYS4GLkuil/PENmuRrAFlihR4D jx/OgCbEU6EnR8Nyh0nGKqToOsE8wPZJfT5ff17vOSHV8hBre354ePB5tnkDoV5H MKgDTCkOx4vQJI8LNmQZHUCNyFmxuJTcYmxAM0j+8rAcdJzKo78eG7/vtJ4uxyBV AxPN7SJyCyplJGgQQ4+y9m5RkSYM6CQFy5PS+jLY66f3ZLmgDaW5vw== =Er9Z -----END PGP SIGNATURE-----

1 0

CERN Web Proxy
by Johnathan Corgan 17 Dec '03

17 Dec '03

Could someone post the host/port number of the proxy server at CERN? Thanks, Johnathan

3 3

Re: Secure (?) Remailer-net
by Hal 17 Dec '03

17 Dec '03

From: Nathan Zook <nzook(a)bga.com> > >> First, the message is signed with the sender's key. (More on that > >> later.) > > > >I did not see why this should be done. > > > > No? Isn't the InterNet currently under a serious packet-spoofing attack? > Don't we expect Eve to be AKA NSA? If I run a remailer, I want to know > that I'm not being lied to in the process. That insistance might just save > the legal butt of the guy being spoofed, by demonstrating that the packet > did not in fact originate from the remailer. Just because remailers are > legal doesn't mean that the govt won't still try to shut them down... I can see the advantage from the sender's point of view. If I sign all messages I send, then I have some defense against the charge that I sent a particular message, if it doesn't bear my signature. (OTOH the prosecutors can argue that I simply skipped signing that one.) This does of course expose me to the risk that if I _did_ send a particular message, my signature will be incriminating. In any case I am still puzzled by your statement that you as a remailer operator would want to be able to verify the source of all incoming messages. Would you do things differently with messages from different sources? I hear you saying that you care if you get a message claiming to be from Alice but not bearing a good signature from her. Why? Again, what would you do differently? > >A better approach IMO is to embed the message length in the encrypted > >information (as PGP does) and pad with cryptographic random garbage > >(which PGP could be patched to do). > > > > In this instance garbage is defined as cryptographic random. If the > message has a length indicator in the clear, then Eve can read it. > (Remember, Eve runs snakoil(a)nsa.gov.) Therefore, such a marker has to be > _inside_ the wrapper. Given this, (that everything is PGP wrapped) there > is always the chance that PGP will compress a message, even one with > cryptographically strong bits in the end. While compression can improve > protection, it is not likely to do so if the original message was already > PGPed. Only "clear" messages, therefore, risk losing protection. As you > note, such messages don't deserve as much help as opaque ones. PGP already includes a cryptographically protected length field in the message. It will ignore any data past that, according to my experiments. All that is needed is a simple patch to add junk data to the end. > >> Note that this system would allow the extropian remailer to be > >> compatible with Matt Ghio's alias system. (Right now, the remailer doesn't > >> like separate pgp packets, or packets it can't read, or something.) Under > >> the current system, the precausion is entirely warranted. > > > >I don't think so. The problem with Miron's extropy remailer is that it > >only passes through the contents of a PGP block. For anonymous addresses > >to work, the (chained,encrypted) address must be in a PGP block which > >precedes the message body. I don't see how any cutmarks idea would > >affect this. > > > > Sure it does. If the whole thing is inside a PGP wrapper, then it is > secure. "Only passing through the contents of a PGP block" is currently a > security measure that makes good sense. But if you have two separate > blocks _inside_ an outer wrapper, you already have full security. Strip > off the outside, find two more wrappers. Strip the first, get remailing > instructions. Attempt to strip the second. Fail. Attach second wrapper > to forwarded message. Full security. I still don't quite follow this. Exactly what attack would be possible against Miron's remailer if it allowed encrypted reply blocks (as all others do) which would fail if the messages were wrapped as you suggest? > Alice signs her messages to the remailer because she doesn't want anyone > spoofing her use of the remailer. If a message goes in at 00:00:00.01, 1 > Jan, 2001 that is "From:" her, it is FROM her. More of the same reasoning. > This key doesn't have to have anything to do with the key she uses with > Bob. It is the one that she wants the general public to use for HER. Alice may not have a key whe wants the general public to use - she may just be using one for her private correspondents. Actually it seems to me given the nature of remailing that it would be superior if it were easy for people to "spoof" my use of the remailer. That would give me more credence to claim innocence. The more useless return addresses are, the less we even need remailers. > Suppose you were using the remailer net. Would you care to know that > someone was spoofing a node? I would. It would indicate that someone is > either hacking the system (probably no big deal), or that someone might be > shadowing a remailer. That is, the remailer is no longer secure. Spoofing > is a big deal on the net generally, and if we start being used a lot, we > will have to deal with it as well. Why not now? It's not my job to fix the damn Internet. So what if I get mail claiming to be from abc when it's actually from def? I of all people care the least, specifically because I throw away this data. Virtually everyone else on the net cares where their mail comes from, but I don't. My whole purpose is to discard the information about where it comes from. That is why I am so confused about your emphasis on checking signatures. > Maybe that was too harsh. I don't advocate holding people's hands. What I > _do_ want to do is to provide the best service that we can. Note that from > earlier and current work (thanks, guys!), we see that even if the remailer > net itself is completely secure, the sender and reciever can still be > traced with near-exponential speed. Although I agree with Wei Dai's mathematics, to my mind it points up the importance of successful countermeasures rather than implying that the remailer network is inherently insecure. For example, if you send one identical message every batch, Wei's math shows clearly that you can't be traced. Let's not get rumors started about how the remailers don't work. > So our systems provide a delay in tracking of a couple of months. Big > deal. The TLAs routinely take years to build a serious case. If we are > going to be any help to folks that _really_ need it, we have to extend the > black box all the way to people outside the net. As you said, not everyone > will be remailers anytime soon. Do you see your suggestion as protecting against Wei's in/out correlation attack? I don't see it. If fixed-sized packets are used, with chained encryption, I think you have as good a system as you do with all of your inter-node encryption and signing. Suppose one good encrypted message enters the net with 10 unencrypted ones. Won't the full path of each of the 10 be visible to an outsider? Even if the remailer helps out those 10 doltish users by encrypting them from there on out, the outsider already saw their whole paths! They will know how many unencrypted messages are going out to each destination, and from that determine where the encrypted message is going. > >Since the secret key d is effectively a random number from 0 to m, you > >would have to create, say, 1000 key pairs to have a good chance of > >finding a d that was as much as 10 bits shorter than m. Then o(d) might > >be 5 bits shorter. So you'd be done from 768+384 to 758+379 or about a > >1% reduction in time. And it will take a while to generate 1000 keys. > >To get a 2% reduction you would have to generate 1000000 keys. I hope > >you have a lot of time on your hands. > > > > Actually, I did make this error when I first considered this, also. We do > not hope for a short key. In fact, we know that the key will be long, when > viewed in parts, as I now believe that it is. We hope that the key will be > 0 rich. The chance of this just comes off of the binomial distribution, > which is not nearly so bad. Sorry. And a, say, 10% improvement above > expected allows a cooresponding length increase--which does something > _more_ than improve security by 10% ;) Yes, I see that you are right about this. It would be easy to generate e,d pairs and get a d which is significantly short on 1's by 10% or more. I did not quite follow your algorithm to do this (was n the modulus or was it phi, the sum of the modulus' divisors?). The one caveat is that if "high-zero" decryption exponents are widely used, it could conceivably reduce the search space somehow, although I don't see offhand how to exploit this. Hal

1 0

Six month mail processing delay :-)
by Robert A. Hayden 17 Dec '03

17 Dec '03

I just HAD to forward this message I received. About a 9 months ago I joined Adam Curry's "CyberSleaze" mailing list. About a month later I unsubscribed. The messages continued to come and I tried unsubscribing several more times. Finally I set up a filter rule to flush the message and sent some grumpy email to the postmaster of the site telling them to fix their software (this was about mid-June of 1994). This morning, I got the following message. Note the dates on it. Nothing like taking one's time. You'd begin to think the government was somehow involved. -----BEGIN INCLUDED MESSAGE----- >From MAILER-DAEMON(a)mtv.comSun Jan 29 16:25:27 1995 Date: Sun, 29 Jan 1995 16:46:32 -0500 From: Mail Delivery Subsystem <MAILER-DAEMON(a)mtv.com> To: hayden(a)krypton.mankato.msus.edu Subject: Returned mail: unknown mailer error 1 The original message was received at Tue, 24 May 1994 09:49:16 -0500 from root@localhost ----- The following addresses had delivery problems ----- "|/home/server/catmail -f -L CYBER-SLEAZE" (unrecoverable error) (expanded from: daemon) ----- Transcript of session follows ----- 554 "|/home/server/catmail -f -L CYBER-SLEAZE"... unknown mailer error 1 ----- Original message follows ----- [ Part 2: "Included Message" ] Date: Tue, 24 May 1994 08:54:59 -0500 (CDT) From: "Robert A. Hayden" <hayden(a)krypton.mankato.msus.edu> To: cyber-sleaze(a)mtv.com unsubscribe ------END INCLUDED MESSAGE-----

2 1

Telnet Acrobatics
by ghio＠myriad.pc.cc.cmu.edu 17 Dec '03

17 Dec '03

What follows are two small programs which I thought might be of interest to cypherpunks. The first (socket.c) is a simple daemon which binds a port and accepts connections, and then forks child processes for each one. The second (relay.c) is a simple telnet program which opens a connection to the specified remote host and port number. Put together they can be used as a telnet relay ("proxy server") that works like the term redir command. This in itself is useful, if you want to hide where you're coming in from, bypass a broken router or get through a firewall. But, take a look at the loop at the end of the second program. It simply reads input from one socket and writes it to another. It would seem to me very easy to add an encryptor/decryptor to this process and encrypt your telnet sessions. You'd just need to exchange a key (via PGP) with the remote system, and decide on a port number, then run crypt/dec daemons on both systems. The socket.c program might also be useful for socket-based remailing. (Tho you can set it up in your inetd.conf instead, if you have root access.) However, I'm having a bit of trouble compiling these on some platforms. I do not know who the original author is. (These came out of a toolkit for breaking system security and the author did not want to be known.) After including a few additional libraries, I was able to compile both under Linux, and it seems to work reasonably well. They'll also compile under SunOS, if you include <sys/termios.h>, but it won't handle non-blocking I/O correctly, and can hang. I can't get relay.c to compile under Ultrix, though socket.c seems to work. socket.c also has a tendency to leave zombie processes hanging under Linux. Anyone want to take a shot at debugging/porting it on other platforms or adding crypto? begin 644 socket.c M(VEN8VQU9&4@/'-Y<R]T>7!E<RYH/@HC:6YC;'5D92`\<WES+W-I9VYA;"YH M/@HC:6YC;'5D92`\<WES+W-O8VME="YH/@HC:6YC;'5D92`\;F5T:6YE="]I M;BYH/@HC:6YC;'5D92`\;F5T9&(N:#X*(VEN8VQU9&4@/'-Y<R]T:6UE+F@^ M("\J(%)E<75I<F5D(&9O<B!,:6YU>"`H8G5T(&YO="!3=6Y/4RD@*B\*(VEN M8VQU9&4@/'5N:7-T9"YH/B`O*B!297%U:7)E9"!F;W(@3&EN=7@@*&)U="!N M;W0@4W5N3U,I("HO"B`@("`@("`@("`@("`@(`IR96%P*"E["B`@("`@("`@ M:6YT(',["B`@("`@("`@=VAI;&4H=V%I="@F<RDA/2TQ*3L*?0IM86EN*&%C M+&%V*6EN="!A8SL*:6YT("HJ878["GL*("`@("`@("!S=')U8W0@<V]C:V%D M9')?:6X@;7EA.PH@("`@("`@('-T<G5C="!S97)V96YT("IS<`H@("`@("`@ M(#L*("`@("`@("!F9%]S970@;75F.PH@("`@("`@(&EN="!M>69D+&YE=RQX M+&UA>&9D/6=E=&1T86)L97-I>F4H*3L*("`@("`@("!S:6=N86PH4TE'0TQ$ M+')E87`I.PH@("`@("`@(&EF*"AM>69D/7-O8VME="A!1E])3D54+%-/0TM? M4U1214%-+`H@("`@("`@("`@("`P*2D\,"EE>&ET*#$I.PH@("`@("`@(&UY M82YS:6Y?9F%M:6QY/4%&7TE.150["B`@("`@("`@8GIE<F\H)FUY82YS:6Y? M861D<BP*("`@("`@("`@("`@<VEZ96]F*&UY82YS:6Y?861D<BDI.PH@("`@ M("`@(&EF*"AS<#UG971S97)V8GEN86UE*&%V6S%=+")T8W`B*2D*("`@("`@ M("`@("`@/3TH<W1R=6-T('-E<G9E;G0@*BDP*7L*("`@("`@("`@("`@("`@ M(&EF*&%T;VDH879;,5TI/#TP*65X:70H,2D["B`@("`@("`@("`@("`@("!M M>6$N<VEN7W!O<G0*("`@("`@("`@("`@("`@("`@("`]:'1O;G,H871O:2AA M=ELQ72DI.PH@("`@("`@('T@96QS92!M>6$N<VEN7W!O<G0]<W`M/G-?<&]R M=#L*("`@("`@("!I9BAB:6YD*&UY9F0L"B`@("`@("`@("`@("AS=')U8W0@ M<V]C:V%D9'(@*BDF;7EA+'-I>F5O9BAM>6$I*2EE>&ET*#$I.PH@("`@("`@ M(&EF*&QI<W1E;BAM>69D+`H@("`@("`@("`@("`Q*3PP*65X:70H,2D["FQO M;W`Z(`H@("`@("`@($9$7UI%4D\H)FUU9BD["B`@("`@("`@1D1?4T54*&UY M9F0L)FUU9BD["B`@("`@("`@:68*("`@("`@("`H<V5L96-T*&UY9F0K,2PF M;75F+#`L,"PP*2$],7Q\(49$7TE34T54*&UY9F0L)FUU9BDI9V]T;PH@("`@ M("`@("`@("!L;V]P.PH@("`@("`@(&EF*"AN97<]86-C97!T*&UY9F0L,"PP M*2D\,"EG;W1O(&QO;W`["B`@("`@("`@:68H9F]R:R@I"B`@("`@("`@("`@ M(#T],"E["B`@("`@("`@("`@("`@("!F;W(H>#TR.W@\;6%X9F0[>"LK*6EF M*'@A/6YE=REC;&]S92AX*3L*("`@("`@("`@("`@("`@(&9O<BAX/3`[>#P* M("`@("`@("`@("`@("`@("`@("!.4TE'.W@K*RES:6=N86PH>"Q324=?1$9, M*3L*("`@("`@("`@("`@("`@(&1U<#(H;F5W+#`I.PH@("`@("`@("`@("`@ M("`@8VQO<V4H;F5W*3L*("`@("`@("`@("`@("`@(&1U<#(*("`@("`@("`@ M("`@("`@("`@("`H,"PQ*3L*("`@("`@("`@("`@("`@(&1U<#(H,"PR*3L* M("`@("`@("`@("`@("`@(&5X96-V*&%V6S)=+&%V*S(I.PH@("`@("`@("`@ M("`@("`@97AI="@Q*3L*("`@("`@("!]"B`@("`@("`@8VQO<V4H;F5W*3L* 5("`@("`@("!G;W1O(&QO;W`["GT* ` end begin 644 relay.c M(VEN8VQU9&4@/'-T9&EO+F@^"B-I;F-L=61E(#QN971D8BYH/@HC:6YC;'5D M92`\<WES+W1Y<&5S+F@^"B-I;F-L=61E(#QS>7,O9FEL92YH/@HC:6YC;'5D M92`\;F5T:6YE="]I;BYH/@HC:6YC;'5D92`\<WES+W-O8VME="YH/@HC:6YC M;'5D92`\97)R;F\N:#X*(VEN8VQU9&4@/&9C;G1L+F@^"B-I;F-L=61E(#QS M>7,O:6]C=&PN:#X*(VEN8VQU9&4@/'5N:7-T9"YH/@HC:6YC;'5D92`\<WES M+W1I;64N:#X*+RHC:6YC;'5D92`\<WES+W1E<FUI;W,N:#XJ+R`@+RH@4F5Q M=6ER960@9F]R(%-U;D]3("AB=70@;F]T($QI;G5X*2`J+PH*=F]I9"!M86EN M*&EN="!A<F=C+&-H87(@*BIA<F=V*0I["B`@<F5G:7-T97(@8VAA<B`@("`@ M("`J<#L*("!R96=I<W1E<B!C:&%R("`@("`@("ID97-T.PH@(')E9VES=&5R M(&EN="!X.PH@(&-H87(@:&]S=&YA;65;,C4V73L*("!I;G0@861D<CL*("!I M;G0@8V]N;F5C=&EO;E]O:SL*("!S=')U8W0@:&]S=&5N="`J:&]S=#L*("!I M;G0@<F5M;W1E9F0["B`@:6YT(&9D.PH@('-T<G5C="!S;V-K861D<E]I;B!R M96UO=&5S97)V97(["B`@=6YS:6=N960@8VAA<B!C.PH@(&9D7W-E="!R96%D M9F1S.PH@(&9D7W-E="!W<FET969D<SL*("!F9%]S970@97AC97!T9F1S.PH@ M('-T<G5C="!T97)M:6]S('1I;W-T<CL*("!I;G0@<CTQ.PH@(&EN="!W/3$[ M"B`@8VAA<B!B=69F97);,3`R-%T["B`@:6YT(&\["B`@"B`@<W1R8W!Y*&AO M<W1N86UE+&%R9W9;,5TI.PH@(&AO<W0@/2!G971H;W-T8GEN86UE("AH;W-T M;F%M92D["B`@:68@*"%H;W-T*2!P<FEN=&8H(B5S.B!U;FMN;W=N(&AO<W1< M;B(L(&AO<W1N86UE*3L*("!B8V]P>2`H:&]S="T^:%]A9&1R+"`F861D<BP@ M-"D["B`@<F5M;W1E<V5R=F5R+G-I;E]F86UI;'D@/2!H;W-T+3YH7V%D9')T M>7!E.PH@(')E;6]T97-E<G9E<BYS:6Y?<&]R="`](&AT;VYS*&%T;VDH87)G M=ELR72DI.PH@(`H@('`@/2`H8VAA<B`J*2HH:&]S="T^:%]A9&1R7VQI<W0I M.PH@(&9O<B`H9&5S="`]("AC:&%R("HI)G)E;6]T97-E<G9E<BYS:6Y?861D M<BP@>"`](&AO<W0M/FA?;&5N9W1H.R`M+7@@/CT@,#L@*0H@("`@*F1E<W0K M*R`]("IP*RL["B`@"B`@<F5M;W1E9F0@/2!S;V-K970H:&]S="T^:%]A9&1R M='EP92P(a)4T]#2U]35%)%04TL(#`I.PH*("!C;VYN96-T:6]N7V]K(#T@8V]N M;F5C="`H<F5M;W1E9F0L("AS=')U8W0@<V]C:V%D9'(@*BDF<F5M;W1E<V5R M=F5R+"!S:7IE;V8H<F5M;W1E<V5R=F5R*2D["@H@(&EF("AC;VYN96-T:6]N M7V]K(#P@,"D*("`@('L*("`@("`@<')I;G1F("@B0V]N;F5C=&EO;B!%<G)O M<EQN(BD["B`@("`@(&9F;'5S:"`H<W1D;W5T*3L*("`@('T*"B`@+RH@3VMA M>2P@8V]N;F5C=&EO;B!E<W1A8FQI<VAE9"X@*B\*"B`@9F-N=&PH<F5M;W1E M9F0L($]?3D].0DQ/0TLI.PH@(&9D/3`["B`(a)9F-N=&PH9F0L($]?3D].0DQ/ M0TLI.PH*("!I;V-T;"AF9"P@1DE/3D))3RP@*&EN="`J*3$I.R`O*B!.;VXM M0FQO8VMI;F<@22]/("HO"B`@:6]C=&PH<F5M;W1E9F0L($9)3TY"24\L("AI M;G0@*BDQ*3L*("`*("!I;V-T;"AF9"P@5$-'1513+"`F=&EO<W1R*3L*("!T M:6]S='(N8U]L9FQA9STP.R`O*B!$:7-A8FQE(&%L;"!P<F]C97-S:6YG.R!U M;F%L=&5R960@."UB:70@8VAA;FYE;"`J+PH@('1I;W-T<BYC7VEF;&%G/3`[ M"B`@=&EO<W1R+F-?;V9L86<],#L*("!T:6]S='(N8U]C8UM624Y44ET],#L* M("!T:6]S='(N8U]C8UM6455)5%T],#L*("!T:6]S='(N8U]C8UM614]&73TP M.PH@(&EO8W1L*&9D+"!40U-%5%,L("9T:6]S='(I.PH*("!I;V-T;"AR96UO M=&5F9"P@5$-'1513+"`F=&EO<W1R*3L*("!T:6]S='(N8U]L9FQA9STP.R`O M*B!$:7-A8FQE(&%L;"!P<F]C97-S:6YG.R!U;F%L=&5R960@."UB:70@8VAA M;FYE;"`J+PH@('1I;W-T<BYC7VEF;&%G/3`["B`@=&EO<W1R+F-?;V9L86<] M,#L*("!I;V-T;"AR96UO=&5F9"P@5$-31513+"`F=&EO<W1R*3L*("`*("!& M1%]:15)/*"9W<FET969D<RD["B`@1D1?6D523R@F97AC97!T9F1S*3L*("`* M("!W:&EL92AR(3TP)B9W(3TP*2!["B`@("!&1%]:15)/*"9R96%D9F1S*3L* M("`@($9$7U-%5"AF9"P@)G)E861F9',I.PH@("`@1D1?4T54*')E;6]T969D M+"`F<F5A9&9D<RD["B`@("!S96QE8W0H,38L("9R96%D9F1S+"`F=W)I=&5F M9',L("9E>&-E<'1F9',L*'-T<G5C="!T:6UE=F%L("HI,"D["B`@("`O*B!4 M:&ES('=O<FMS(&)U="!I<R!W87D@=&]O('-L;W<N+BX@*B\*("`@("\J=SUR M96%D*&9D+"9C+#$I.VEF("AW/C`I('=R:71E*')E;6]T969D+"9C+#$I.RHO M"B`@("`O*G(]<F5A9"AR96UO=&5F9"PF8RPQ*3MI9B`H<CXP*2!W<FET92AF M9"PF8RPQ*3LJ+PH@("`@=SUR96%D*&9D+&)U9F9E<BPQ,#(T*3MI9B`H=SXP M*0H@("`@>PH@("`@("!O/3`["B`@("`@('=H:6QE*&\\=RD@;SUW<FET92AR M96UO=&5F9"QB=69F97(K;RQW+6\I.PH@("`@?0H@("`@<CUR96%D*')E;6]T M969D+&)U9F9E<BPQ,#(T*3MI9B`H<CXP*0H@("`@>PH@("`@("!O/3`["B`@ M("`@('=H:6QE*&\\<BD@;SUW<FET92AF9"QB=69F97(K;RQR+6\I.PH@("`@ L?0H@('T*"B`@8VQO<V4H<F5M;W1E9F0I.PH@(&-L;W-E*&9D*3L*("`*?0H@ ` end

3 2

Telnet Acrobatics
by ghio＠myriad.pc.cc.cmu.edu 17 Dec '03

17 Dec '03

BTW, usage is socket <portnumber> command relay <hostname> <postnumber> You can combine them to make a telnet relay/forwarded with: socket <localport> relay <hostname> <remoteport>

1 0

null What's Killing My Remailed Posts?
by nobody＠rebma.rebma.mn.org 17 Dec '03

17 Dec '03

[Please Reply-To: an105(a)vox.xs4all.nl as I am not receiving the group or list on which this message _hopefully_ appears. Thanks!] Though I have been vigorously using the various remailers for a long time, I am stumped by my sudden inability to get a post to a newsgroup by any remailed means. Example: For a long time I have used the following boilerplate form with usura(a)replay.com with flawless results: :: Encrypted: PGP :: Anon-To: my.anon.address(a)somewhere.org Cutmarks: * | Message Successfully Remailed, # 999 * :: Anon-To: mail2news(a)demon.co.uk Cutmarks: ___ Latent-Time: +6:00r ## Newsgroups: alt.some.group,misc.another.group Subject: Furballs in Wolverines My wolverine has nasty furballs... [...] My wolverine thanks you all for suggestions... ___ The current status of this is that I get the remailed receipt, but the message never shows in the group. Is mail2news(a)demon.co.uk down? I tried using the Usura Anon-Post-To: feature, but it fails as well. I've tried using _other_ remailers with the simple form... Anon-To: alt.some.group(a)comlab.ox.ac.uk Anon-To: alt.some.group.usenet(a)decwrl.dec.com Anon-To: alt.some.group(a)bull.com I've also tried Request-Remailing-To: with the same address form. Nada. I have been unable to make any of the usual remailers get through to the groups by any means for about three weeks, though evidence shows that the remailers are certainly getting the messages, as I can send anon netmail messages - - - the _posts_ just never show. I periodically suspect that someone somewhere is running a program to sweep all posts with "remail," "nobody" or "anon" anywhere in the header. Any thoughts on this...assuming it shows here? ___ Blue Wave/QWK v2.12

2 1

Re: CERN Web Proxy
by Johnathan Corgan 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >> CERN = http://www.cern.ch:911 > >Error 403 > >Forbidden - by rule > > >CERN httpd 3.0 This is what you get if you interpret the above as a URL...which makes sense since that was how it was posted. What it really is is the host name and port name to configure your Web browser so that all your HTTP traffic is funnelled through CERN first, and then relayed from there to the destination. I don't know how Mosaic supports this, but under Netscape for Windows, it is under Options | Preferences | Mail and Proxies | HTTP Proxy. While this doesn't provide complete anonymity, it does prevent your email address, site name, etc. from appearing in the log files of the HTTP server you are connecting to. I'm not sure why CERN has this running, but it is pretty usefull nonetheless. == Johnathan Corgan "Violence is the last refuge of the incompetent." jcorgan(a)aeinet.com -Isaac Asimov -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLywpCk1Diok8GKihAQHH+AQA4EG9IPrwZ76iLggvbyjaBRLiDETzTjyz ljz87cOeAZ/sXevexPRD3RDzkSzOGRfbsFHEEV6gNI1q+35saJYCCVMdxCZUggeO xIIkCg+lTC6vMjj4JLQ5nLH2yZX2na3DjeR5/vidaSw2oEEUM0n06e6XnXS19mZ9 /ggmzfYtt1U= =hxmC -----END PGP SIGNATURE-----

1 0

ESP -> ESM
by Matt Blaze 17 Dec '03

17 Dec '03

I've just been informed that there's a reasonably confusing name collision between my ESP and a working name for IPSP. Grumble. I'm easy. ESP is now called ESM (encrypting session manager). Everything else is the same. -matt

1 0

Data Bank Protocols
by norm＠netcom.com 17 Dec '03

17 Dec '03

See ftp://ftp.netcom.com/pub/Si/Silk/DataBank.txt for updated proposal for DataBank protocols. I have addressed, to a degree, points made by Eric, and corrected the blunders pointed out by jpp(a)markv.com. I am glad to e-mail this to anyone for whom ftp is awkward. Thanks all.

1 0