Re: MAIL: chained remailing strategy

[Hal <hfinney@shell.portal.com>]

Nobody writes:

>This mention of "DEATH TO BLACKNET" sounds intriguing.  Is this 
>some sort of abusive/harassing message you're trying to track 
>down?  With encrypted chaining available to hide the actual 
>subject until the last link, it would seem that the sender is 
>either naive, or else WANTS the Subject: line itself to send some 
>sort of "statement".  (What is "BLACKNET", BTW?)

Several months ago arch anti-cypherpunk Larry Detweiler, about to lose
his account, set up a daemon to post an edited version of Tim May's old
"Blacknet" spoof to random and inappropriate usenet groups.  ("Blacknet"
was Tim's hypothetical cryptographically anonymous black market for il-
legal information exchange.)  He happened to use my remailer as a single
hop to the net.  I logged in and found my mailbox full of people complaining
about this message which "I" had sent to sci.med.diabetes and such.  So
I added a line to the .maildelivery file so that any message with the
subject line Detweiler was using would be dumped to a file rather than
forwarded.  This is the only kind of logging I do, other than recording the
date and time at which the remailer sends each message, the source of my
previous posting.


>This brings up a related question, however.  How often, if at 
>all, are you asked to help trace down the source of a message 
>handled by your remailer?  Under what circumstances would you 
>cooperate with such a request?

In the year and a half that I have been running this remailer, I have
been asked probably a dozen times if I could tell where some abusive
message comes from.  I am not able to do so since after the message has
been sent the information is gone.  At best I could insert a log if it
looked like something really vicious was going on.  Even then, if the
sender used chaining then every remailer on the chain would have to
anticipate and log his messages (or all messages).  My general practice
is to add every person who complains about receiving an unwanted
message to my list of outgoing blocked addresses.


>I've noticed that you have a 510 bit public key for your 
>remailer.  Did you choose the shorter length to speed things up, 
>or what?  I tend to use a remailer with a longer key as my FIRST 
>link in the chain.  Maybe it's overkill, but why not?

I chose the ~512 bit key in recognition of the limited security provided
by my remailer.  Like every automated remailer, the decryption key has to
be on the system essentially in cleartext.  I don't come up and type in a
pass phrase for every message which goes through.  This means that anyone
who can hack Unix can learn my remailer secret key.  Under the circum-
stances, there would be no point in going with 1024 bits, and in fact it
would give an entirely false and unjustified sense of security.

>And, finally, as a chained remailer user, I've read the periodic 
>"status reports" by fingering "ghio@andrew.cmu.edu" and your 
>remailer must certainly rank as one of the promptest and most 
>reliable.  In fact, I think I'll include you *SOMEWHERE* on the 
>chain for this reply... <g>

I can't take any credit for either the promptness or reliability; that is
a function of my internet service provider, the Portal system.  Frankly,
I have not been too happy with the reliability and availability of the
system; mail and news seem to fail for 24 to 36 hour periods every month
or so, and the system seems to have unscheduled downtime a few hours a
week.  But I suppose almost everyone has complaints like this.  The one
thing I will give the Portal people high marks for is that they have never
said anything about my remailer.  I'm sure some of the nasty letters I have
received after inappropriate mail and news postings have been cc'd to the
sysops here, but I haven't heard one word.  I understand that at the
"Hackers' Conference" a couple of years ago the owner of the Portal system
endorsed the concept of remailers.  (This was reported by Tim May.)  Perhaps
he is silently offering me some sort of protection.  Whatever the reason,
I am pleased that I have been able to keep the service going this long.

Hal Finney
hfinney@shell.portal.com