Eternity Uncensorable?

Seems to me there's a fundamental flaw with the current Eternity server;
as I understand it the messages are identified by a subject which is the
SHA of their URL, so all that a government need do to censor a particular
site is to scan for those messages and issue cancels. Sure, your site and
those upstream may not accept such messages, but potentially they can
still wipe out a large fraction of the system or at least force users to
change their eternity URLs on a regular basis.

It also doesn't provide true security, since when someone sets up an 
illegal site the gubment can find the messages on Usenet, decrypt them, 
and then threaten the remailer operator who posted them.

I understand that this is just an alpha release, but I don't see any
obvious way to fix these problems with a Usenet-based system. 

	Mark

These comments are useful, as eternity needs some documentation, and
I'm supposed to be writing an article for Phrack on this for deadline
of this sunday, and arguing with people is a good way to get
motivation to write explanations etc.  This dual purpose is why this
is a longish post.

Mark Grant <mark@unicorn.com> writes:
> Seems to me there's a fundamental flaw with the current Eternity
> server; as I understand it the messages are identified by a subject
> which is the SHA of their URL, 

yup.

> so all that a government need do to censor a particular site is to
> scan for those messages and issue cancels. Sure, your site and those
> upstream may not accept such messages, but potentially they can
> still wipe out a large fraction of the system or at least force
> users to change their eternity URLs on a regular basis.

Two comments on this:

- I understand cancels are ignored a lot of places, due to problems with
  censorous people, and pranksters issuing tons of forged cancels.
  These censorous people are actually doing us a big favour because it
  is their actions which has led to the widespread policy of ignoring
  cancels.

  However this is going on other peoples information.  I don't have
  any figures for how widespread the practice of configuring news to
  ignore cancels is.  

  Perhaps we could do a little experiment here, you (or someone who
  has the tools/knowhow handy try cancelling the dozen or so eternity
  articles in alt.anonymous.messages, and we'll have a little survey
  amongst list readers as to how well the cancels work.

- Comment #2.  The eternity servers have caches.  They cache
  documents. (This is configurable).  There is currently no cache
  replacement policy because I haven't got around to it yet.  So
  currently once viewed the docs stay there forever.  (When I do get
  around to cache a replacement policy it will be either least
  accessed, and/or lowest ecash payment).

I'm however not so keen to promote the idea that actually the docs you
are looking at are coming off the servers cache because it's nicer to
leave them presuming it was just read off the NNTP server right then
(which it can be at the moment).
   
It's a two stage process at the moment:

   - server reads news at some chosen internval and creates database
     of article number, subject field, and message-id field for
     subject fields which look like eternity documents.

   - some user comes along and types a URL which matches the chosen
     hash.  Server fetches document from NNTP or local news spool
     using the article number as looked up in the database.  Depending
     on the eternity.conf setting for cacheing (on/off/encrypted) and
     the document setting (on/off/encrypted) the document will be
     either not cached, cached in clear, or cached in encrypted form
     (with sha1( 1<url> ) where <url> is the url of the document).

I could change it to a single stage process so that eternity documents
are immediately cached.  This is something easy to change, which could
be done if people got trigger happy with cancels and it was affecting
things.  Then you would be left with cancel wars :-) The eternity
server would grab the article at first opportunity though.

Later versions of the software will have to exchange documents
somehow, so then as long as one server saw the document before someone
cancelled it you'd be ok.

Clearly you could have an email submission channel where you just
email the article to a server, but that gets away from the idea of
pointing the finger at USENET.  (Cacheing is somewhat protected in
legislation even, because it's just a USENET document, and all you're
doing is cacheing it according to some cache replacement policy).

Some more technical explanations of what's going on encryption wise,
is that articles in the news spool have an outer encryption layer
which encrypts in one of these two ways:

   1) with pgp -c and password "eternity"

   2) with pgp -c and password of sha1( "1<url>" ) 
      where url is the document url

Inside this encryption layer is the document options (document url,
per document cacheing policy, and a marker of whether the document is
exdirectory or not (exdirectory docs not listed on document list).
Plus an optional pgp key, and the ascii armored, optionally signed
document.

There is an optional inner layer of encryption, the ascii armored
signed document can optionally be encrypted:

   3) using a user selected passphrase

Option 1) provides little more protection than rot-13.  But should be
of some use in that it prevents the less clued from reading the
documents out of USENET directly.

Option 2) means that you need to know the URL before you can access
the document.  Without the URL, you're hosed.

Perhaps the URL is easy to guess, perhaps it's not:

	http://warez.eternity/safuwerqwkesadfiqwerdsf/

Option 3) means that you need the passphrase to read the document in
addition to the URL.  This has similar effect to having a garbled URL,
choose a hard to guess passphrase.

You can turn on SSL at the eternity server, but that means you're
still trusting the operator, and root on the system.

To do it properly, you'll need a local eternity server if you want to
good security of encrypted documents.  Easy enough to run a local
eternity server if you're using linux on a ppp or permanently
connected machine.  My development machine is a ppp connected linux
machine.

However I'm not sure having passphrases is that good of an idea,
because it'll be furtively passed around amongst the community of the
person who submitted the documents, but that can always leak out.

And people using non-local eternity servers will be revealing the
shared passphrase to the server admin, (and to the snooping world, if
the server isn't running with SSL turned on).

> It also doesn't provide true security, since when someone sets up an 
> illegal site the gubment can find the messages on Usenet, decrypt them, 
> and then threaten the remailer operator who posted them.

Turn of logs, and introduce forward secrecy into mixmaster.  Easy to
do.  Why don't we have it yet?  (Ulf?  Lance?)

Then you have as true security as you can get from a digital mix with
the parameters mixmaster has.

Don't do too many regular updates of your eternty web pages for very
high risk situations.  Engineered network outages could show you up
quickly even if you were using a DC-net covering 1 million users.

> I understand that this is just an alpha release, but I don't see any
> obvious way to fix these problems with a Usenet-based system. 

Does the above answer your concerns about security?

Medium term software development-wise the eternity servers are going
to have to exchange documents between themselves.  At that point
USENET will be functioning mostly as hard to tamper with distribution
channel.  The rest will be a distributed USENET caching system, with
cache policy determined by popularity of document (hit count), and by
ecash payment.

Longer term perhaps some of Ross Anderson's more advanced ideas can be
added, as discussed by Ryan Lackey in the thread entitled "distributed
data store, a la eternity".

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

To follow up to my own post briefly, I said:

: Clearly you could have an email submission channel where you just
: email the article to a server, but that gets away from the idea of
: pointing the finger at USENET.

If the machine hosting the eternity server also has a mail2news
gateway (eg replay has mail2news@replay.com), then modify the
mail2news program to forward a copy to eternity@replay.com for
newsgroups that the eternity server is interested in.

That way it's still a USENET post.  Just you're stacking the odds
against the cancel forger :-) The cancel forger can't get there before
you unless he can read your mind (or your email), but it wouldn't
matter if he could, because eternity would see the document anyway.

http://www.replay.com/aba/eternity/ is reading it's news from
nntp:news.xs4all.nl, but I don't know what their cancel settings are
for their news spool.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 6 Aug 1997, Adam Back wrote:

> Mark Grant <mark@unicorn.com> writes:

[...]

> > so all that a government need do to censor a particular site is to
> > scan for those messages and issue cancels.

> - I understand cancels are ignored a lot of places, due to problems with
>   censorous people, and pranksters issuing tons of forged cancels.

And alot like to use canceles.  If censorus groups (not neccery the
goverment) starts canceling we may be able to create a resector like that
used in news.admin.net-abuse.*

[...]

>   I don't have any figures for how widespread the practice of
>   configuring news to ignore cancels is.  

Most sites still hounder cancels,  a growing number ignore them (often for
preformence resons).

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBM+ifYqQK0ynCmdStAQEhzwQAnw82Mk6XNlvQRUGVDVsBW63vOkFBZDV/
oLz3BUFTnrn4mHZxwuU2s+j1O2s7aLZP/ImD69XePILqKJDYiMJ6A6nc0reirNZ0
6WlkPl6jgpqWL8SKNidisjDWmwMXoYdkE6HSUB2rGoLgrtzvw4RXc6XcnQcG2Zb0
b8andhqfeTs=
=POHl
-----END PGP SIGNATURE-----

? the Platypus {aka David Formosa} <dformosa@st.nepean.uws.edu.au> writes:

> On Wed, 6 Aug 1997, Adam Back wrote:
>
> > Mark Grant <mark@unicorn.com> writes:
>
> [...]
>
> > > so all that a government need do to censor a particular site is to
> > > scan for those messages and issue cancels.
>
> > - I understand cancels are ignored a lot of places, due to problems with
> >   censorous people, and pranksters issuing tons of forged cancels.
>
> And alot like to use canceles.  If censorus groups (not neccery the
> goverment) starts canceling we may be able to create a resector like that
> used in news.admin.net-abuse.*

A clarification is in order:

The "resurrector" in news.admin.net-abuse.* is run by none other than
the child-molesting pedophile Chris Lewis.  It does NOT repost
cancelled articles when the author is someone Lewis doesn't like
- such as myself.

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

>Turn of logs, and introduce forward secrecy into mixmaster.  Easy to
>do.  Why don't we have it yet?  (Ulf?  Lance?)

It will not be in 2.0.4 final (unless someone sends me the code :),
but is high priority for 2.0.5.

On Wed, 6 Aug 1997, Adam Back wrote:

>   However this is going on other peoples information.  I don't have
>   any figures for how widespread the practice of configuring news to
>   ignore cancels is.  

Ditto. We'd have to assume that it's pretty widespread to avoid these 
problems.
 
> To do it properly, you'll need a local eternity server if you want to
> good security of encrypted documents. 

I'd assume that in the end this is what most people would do; get a Usenet
feed and run a server locally so that noone knows which URLs you're
accessing. 

> Turn of logs, and introduce forward secrecy into mixmaster.  Easy to
> do.  Why don't we have it yet?  (Ulf?  Lance?)
> 
> Then you have as true security as you can get from a digital mix with
> the parameters mixmaster has.

That's not what I meant; I'm assuming that the mixmaster chain is pretty
secure. The problem is that when the government find 'nuclear terrorist
money-laundering kiddie drug porn' on the Eternity server they can trace
it back to the original Usenet message and then go after the remailer
operator who posted it. Making the remailers disposable or setting them up
in free countries would work, but I'd prefer a technical solution. 

	Mark

>Mark Grant <mark@unicorn.com> writes:
>> On Wed, 6 Aug 1997, Adam Back wrote:
>The solution is to have disposable tents, lots of.
>
>What about AOL disks?  We need shorter lived, disposable remailers as
>exit remailers...  Let them take the heat, while the real remailers
>walk.  Lets see a series of "exitman" remailers.  Exitman remailers
>are walking targets left to fend for themselves as long as they may.
>
>I propose that an exit remailer is replaceable, that is another
>remailer can instantly step into it's place and take traffic.  The way
>to do this is to have a special automated reporting mechanism for
>exitman remailers.  An easy way to do it is to have the exitman
>remailers send mail to a given mailing list.  Other remailers which
>wish to use exitman remailers just subscribe to the chosen mailing
>list.  We just need a remailer command indicating the creation of a
>new exitman remailer.  I guess the exitman remailer just sends one
>message per day, or whatever, and if it stops, you write it off.
>
>Is there a military term for something sent in to get shot to bits,
>just to distract attention from other movement?  A decoy?

A possible problem is the motivation of those setting up decoys.  If
they're doing it to help thwart remailer abuse, fine.  But what if their
intent is to thwart remailers?  Couldn't these dissidents set up black-hole
remailers which are simply information sinks?  When a email is
chain-remailed and doesn't get delivered many, but not all, senders would
simply assume one of the remailers are having delivery problems and resend.
Will Raph's approach work to monitor  decoys when their number and identity
are constantly changing?  Won't this significantly complicate remailer
clients?

--Steve

Uggh another post which turned out hugely long... I cc'd to remailer
ops due to remailer operator relevance.

Steve Schear <azur@netcom.com> writes:
> >> On Wed, 6 Aug 1997, Adam Back wrote:
> >I propose that an exit remailer is replaceable, that is another
> >remailer can instantly step into it's place and take traffic.  The way
> >to do this is to have a special automated reporting mechanism for
> >exitman remailers.  An easy way to do it is to have the exitman
> >remailers send mail to a given mailing list.  Other remailers which
> >wish to use exitman remailers just subscribe to the chosen mailing
> >list.  We just need a remailer command indicating the creation of a
> >new exitman remailer.  I guess the exitman remailer just sends one
> >message per day, or whatever, and if it stops, you write it off.
> 
> A possible problem is the motivation of those setting up decoys.  If
> they're doing it to help thwart remailer abuse, fine.  But what if
> their intent is to thwart remailers?  Couldn't these dissidents set
> up black-hole remailers which are simply information sinks?  

Good point, they could indeed.

There is another related problem which is a real thorny one:

  Being exit only, the attacker will by definition know the email
  address the messages it forwards are being sent to.  The attacker is
  trying to maximise his ability to disrupt, so he will be trying extra
  hard to conceal from remailer operators and their community that he is
  disrupting.

  Clearly the clever attacker in this situation, trying to disrupt the
  exitman-using middleman remailers reliability will let through
  anything going to a public forum, or to an email address he suspects
  is anything to do with Raph's pinging service.  (Eg any address on the
  cypherpunks list or remailer-ops list as possible collaborators in the
  remailer reliability pinging).

  If the attacker is a Fed or spook or whatever, he will have good
  resources and ability to correlate destination email addresses to
  cypherpunks list members.  Eg you get an account somewhere, they can
  find out by looking at your credit card logs, or whatever.

Counter-measures?

1) Counter measure #1

   A sop I can offer to this difficulty of detecting denial of
   service attacks, is that perhaps you could have the last middleman
   remailer send to a bunch of different randomly selected exitman
   remailers.  So when you get some anonymous mail you get 10 copies of
   it.

   That way you can work out some stats for how likely someone who is
   operating 10 of 20 exit man remailers is to stop a given mail
   getting through.

 1a) Counter-counter measure to 1)

     However if some of these remailers are operating from cracked
     accounts, rather than from anonymously purchased accounts, the
     attacker has an easy job of increasing his percentage of exitman
     remailers: take out the existing ones.  Simple just email the admin
     of the cracked account -- he'll remove it.

2) Counter measure #2

   Another idea, but really quite manual, would be to pick people who
   have advertised PGP keys, send them mail via some exitman remailer,
   and ask them politely to forward it to you.

   (Clearly sending through requests to "let me know if you recieve
   this email" aren't going to be recognized by the attacker, and let
   through if we send mail to people who don't have encryption
   capability).

 2a) Counter-counter measure to 2)

     Course then the attacker can counter by letting through any
     encrypted mail without question.  Stuck there aren't we :-(

3) Counter measure #3

   Scraping the barrel here: what if we enlist the help of exitman
   remailers to check up on other exitman remailers?

   So now lets say we don't release a list of exitman remailers, but
   rather each exitman remailer privately announces itself to one
   randomly selected remailer privately.

   This is better in general because there is now no publically known
   list of exitman remailers.  It is now harder for someone to
   use the list to just email all the admins in the hope that they
   will revoke paid for accounts (attacker makes legal threats,
   claiming to have receiving illegal material from this account or
   whatever), or to remove hacked accounts (real easy this one).

   With this setup we can send mail to one exit man via another one,
   with some chance that the first exitman won't recognize the other
   exitman.  (You wouldn't want to overdo it with repeated mail, or
   the corrupt exitman might start to suspect the mail was another
   exitman).

  3a) counter-counter measure to 3)

      It might be relatively easy for the well funded attacker to work
      out which addresses of those it receives to forward to are
      accounts with exitman installed.  Eg. Watch the traffic from the
      host, after sending a bunch messages through remailers.  Or
      simply finger the account see if the user ever logs in.  (If it
      was hacked, it could be an active account, the user might never
      look at the forward file with |/home/oliver/... , nor the
      exitman remailer installed as "..." in some directory -- if it's
      working properly they won't see the email, and if it's forging
      email well they see replies).  Incidentally exitman remailer
      hidden in "..." would allow a user to install it himself and
      plausibly claim ignorance, a more subtle way to obtain
      "disposable" exitman remailers.  Best run from clearly
      non-technical users accounts with the knowing assistance of a
      technical assitant.

4) counter measure #4

   An exitman remailer pinging service would be easily feasible for
   the post to USENET aspect (or to known mailing list), as the
   exitman remailer would show itself up quickly in this case.

   However I'm not sure this is so useful as mail2news gateways, and
   public postings generally (*) generate a lots less agro for their
   operators than a remailer.  This is because people don't have to
   read USENET, and don't feel nearly so threatened as when they
   receive an anonymous mail aimed at them.  And also because the
   mail2news gateway puts the senders address in the From field, which
   points the finger at the exit remailer anway.  mail2news seems to
   be viewed as more neutral.  If any mail2news operators have
   experiences which suggest otherwise I'd be interested to hear.

   (*) I did read of one case on remailer-operators where someone got
       hit by a remailer hater who used a remailer to post a fake
       advertisement of a CD full of commercial warez.  The
       remailer-hater then anonymously tipped off the SPA.

   Incidentally I say "remailer-hater" here, but I should probably use
   a more term "remailer-attacker" or something, there could also
   feasibly be someone who is actually on our side (in a Zen sort of
   way) and trying to get us to face and solve the DoS and operators
   liability issues with technical solutions by demonstrating the
   current weaknesses.


Some of these attacks are interesting for ordinary remailers also.
Perhaps there exist right now normal (non-middleman) remailers which
will send to another remailer in case it is a ping message, and
anything that looks like an attempt to deliver to Raph, but junk the
rest.

Would we know?


Anyway, overall I think the difficulty in checking on exitman
remailers overall probably means that this simplest practical
compromise for mail delivery from exitman remailers is for the last
middle man remailer to send the mail to multiple exitman remailers.

I also think the that the idea of exitman remailers privately
announcing themselves to selected remailers might mean that they last
longer, otherwise remailer haters will contact the admins and cause
hassle even if they can't correlate any particular message came from a
given remailer due to good mail forgery on the part of the exitman
remailer.

And using exitman remailers to post to USENET might be useful at some
point if open access mail2news gateways got scarce.

> When a email is chain-remailed and doesn't get delivered many, but
> not all, senders would simply assume one of the remailers are having
> delivery problems and resend.  Will Raph's approach work to monitor
> decoys when their number and identity are constantly changing?

In theory yes.  Send it via a couple of exitman remailers to make sure
if you like.  However the smart DoS attack described above is much
harder to counter.

> Won't this significantly complicate remailer clients?

Nope.  The client won't need to know.  You're not expected to send
directly to an exitman remailer.  That is something for remailer
operators to use.

You know how middleman operators work...  they always, always send
mail via another remailer and never deliver mail to a user.  (I'm not
sure if they detect this by looking to see if the address is on the
remailer list, or just always add an extra hop?)

So if there are some exitman remailers, a remailer operator that gets
sick of the heat can switch to a new kind of middleman mode, where he
always posts everything through various exitman remailers.  (Or normal
middleman mode, and leave the hassle of installing software to keep up
to date on current exitmen to other exitman-using middleman
remailers).

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 7 Aug 1997, Adam Back wrote:

> You know how middleman operators work...  they always, always send
> mail via another remailer and never deliver mail to a user.  (I'm not
> sure if they detect this by looking to see if the address is on the
> remailer list, or just always add an extra hop?)

I think by definition a middleman always chains through one or more
additional remailers. When I ran dustbin, it was a "smart middleman",
i.e., if the recipient was a known remailer, it wouldn't bother to chain
(remailers rarely complain), otherwise it would chain through a single
remailer. I have a procmail script which does this as well using mixmaster
only (some definitions are missing here): 

# Smart middle. If not to another remailer, send it through a random mixmaster.
# Mixmaster 2.0.3 compatible.

:0 f
* MIDDLE ?? (on|yes)
*! ? grep "$TO" $RLIST $TYPE2
| formail -bf -I"From:" -I"To:" -I"Comments:" -IMessage-ID: \
        | $MIXPATH/mixmaster -f -to $TO -l 0 

# We made it this far, so send out the mail.

:0
| $SENDMAIL $SENDMAILFLAGS 

An even smarter middleman would detect PGP messages and deliver those
directly to end recipients, since those people are unlikely to complain
about anonymous mail, and chain if the message was plaintext. The risk
involved with this type of middleman operation should be rather small.

Andy Dustman / Computational Center for Molecular Structure and Design / UGA
    To get my PGP public key, send me mail with subject "send file key".
For the ultimate anti-spam procmail recipe, send me mail with subject "spam"
"Encryption is too important to leave to the government."  -- Bruce Schneier
http://www.ilinks.net/~dustman    mailto:andy@CCMSD.chem.uga.edu      <}+++<


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQEPAwUBM+ouuhOPBZTHLz8dAQFMaQfPYwBpG+f05Oq/gu4nZDacu+0DDg/v/EgI
IOZa4GCrNlhfbl0mp0XFLbEWLi8SvwWhpo6nhOFDIda7wcmyo032TfbcajNPEcz7
qeRNBEY2wDwp9B9MaXZlFyThnmnqsfgeU0h/c+txPiV48HsiX2uvG1NEKumqxq+e
R1nqBS6Ob5uP+1urfqAbrdeTPdRSwlx+C9SlxMLLYpoPq5OM8YZu08UOBVWRE2FD
ia4DvHCWVBsj2rpgiDrpWyMHAEbkoy9FJm5qUa2FqZq62TrS0rVugdjsE4mvisjM
ULoalmkRHsByl/qUICRqSpktQQtveq2I3MEIHYSk7tEVJQ==
=0FkI
-----END PGP SIGNATURE-----

Andy Dustman <andy@CCMSD.chem.uga.edu> writes:
> On Thu, 7 Aug 1997, Adam Back wrote:
> 
> > You know how middleman operators work...  they always, always send
> > mail via another remailer and never deliver mail to a user.  (I'm not
> > sure if they detect this by looking to see if the address is on the
> > remailer list, or just always add an extra hop?)
> 
> I think by definition a middleman always chains through one or more
> additional remailers. When I ran dustbin, it was a "smart middleman",
> i.e., if the recipient was a known remailer, it wouldn't bother to chain
> (remailers rarely complain), otherwise it would chain through a single
> remailer. 

OK, so as you're the first person to implement a smart middleman I
guess that defines the terminology :-)

middleman
  "always adds another hop through a random remailer"

smart middleman
  "posts through remailer when asked to deliver to anybody other than
   a known remailer"

Wasn't there for a time a hidden middleman.  That is a middleman
remailer who's published address was a nym account on a nymserver?
That'd be a "hidden middleman".

> An even smarter middleman would detect PGP messages and deliver those
> directly to end recipients, since those people are unlikely to complain
> about anonymous mail, and chain if the message was plaintext. The risk
> involved with this type of middleman operation should be rather small.

Yep.

Dimitri suggested on cypherpunks in the last round of discussion of
this sort of thing another variation on that -- that you could deliver
the mail if the person had a PGP public key on the keyservers --
whether the email was encrypted or not.  On the assumption that people
who use PGP would be unlikley to complain of anonymous mail.

He also suggested beefing up keyserver submission checks (there are
none right now) so that you need a replyable address to submit a key,
otherwise the remailer-baiter just posts a key generated with their
"victim's" email address on it prior to sending to them.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 7 Aug 1997, Adam Back wrote:

> Wasn't there for a time a hidden middleman.  That is a middleman
> remailer who's published address was a nym account on a nymserver?
> That'd be a "hidden middleman".

There's some now. medusa@squirrel.owl.de is one.  middleman@cyberpass.net
(reno) might be another (not sure the account is anonymous, but could be).

> Dimitri suggested on cypherpunks in the last round of discussion of
> this sort of thing another variation on that -- that you could deliver
> the mail if the person had a PGP public key on the keyservers --
> whether the email was encrypted or not.  On the assumption that people
> who use PGP would be unlikley to complain of anonymous mail.

The only problem with that is the denial-of-service attack you describe
below. I figure if it's already encrypted, delivery is likely to be
welcomed rather than irritating.

> He also suggested beefing up keyserver submission checks (there are
> none right now) so that you need a replyable address to submit a key,
> otherwise the remailer-baiter just posts a key generated with their
> "victim's" email address on it prior to sending to them.

Yeah, I had in mind some kind of magic cookie exchange using the submitted
key. Once the cookie gets returned, the keyserver signs the key with a
special signing key which certifies that the key has at least passed the
"cookie exchange" test. The remailer I was working on (I say "was" because
I just have been too darn busy to finish it) would have implemented that
very thing. It's essentially the same thing the nymservers do when
configured to confirm reply blocks, which they always are. 

Back to the subject: Disposable remailers. It seems the juno remailer
software would be good for this. I'm not sure what the sign-up requirement
are, but it's free. I was also thinking about web-based free mail
services, such as Hotmail and Rocketmail. Receiving mail means having to
parse some HTML, which from the looks of things is do-able but not
trivial. Sending mail might be easier to implement.

Which brings up an interesting idea for an exitman/middleman remailer: Use
a nym or commercial ISP to receive the mail, use throwaway free mail
accounts for delivery (maybe even just plaintext delivery). Hotmail, at
least, inserts an X-Originating-IP:  header, though.  I expect others do
the same. So put your remailer output on a ZIP disk or floppy and run your
delivery on whatever public or semi-public access machine you happen to
get your hands on, once or twice a day.

Andy Dustman / Computational Center for Molecular Structure and Design / UGA
    To get my PGP public key, send me mail with subject "send file key".
For the ultimate anti-spam procmail recipe, send me mail with subject "spam"
"Encryption is too important to leave to the government."  -- Bruce Schneier
http://www.ilinks.net/~dustman    mailto:andy@CCMSD.chem.uga.edu      <}+++<



-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQEPAwUBM+pqRBOPBZTHLz8dAQHyvAfPddrITrYKYCB7gmWuMyJxwWkCi+8oaZPZ
Q3EMlQ2+Jfhw0gSHKYwfVHok6ttU5pGy3epwVBXSYAfs5Tge++3q2ZmoUAPuLRgx
1jv3akJnNrgnxTXVRNdrJDRs3rK1/5Xz7+GunK/zbdyicjxBJzVNaJL17i1R/Xr+
/r36YiBcueQBaEdJI3uqF08rj/63CFVuX5n6lun0cBvPxNK2wJ0WBknQeZsPHAjQ
jbzu0hAkWZ1WYXLtLanzbn7TQrgMkMnVoRvu6JSdtxYEywd2aYhS/F1N6SKk6FiE
DVEnoPRE42U/utHrEX30heLrSbD/fbwTruR1f1H4lTWMOg==
=en6+
-----END PGP SIGNATURE-----

Andy Dustman <andy@CCMSD.chem.uga.edu> writes:
> 
> Back to the subject: Disposable remailers. It seems the juno remailer
> software would be good for this. I'm not sure what the sign-up requirement
> are, but it's free. I was also thinking about web-based free mail
> services, such as Hotmail and Rocketmail. Receiving mail means having to
> parse some HTML, which from the looks of things is do-able but not
> trivial. Sending mail might be easier to implement.

Sending mail is your problem alright.  It's where you get hit by
spammers etc.

Wasn't there an email forgery web page around for a while.  The idea
was that you filled in the details of who you wanted to send to, what
address you wanted it to appear you had sent it from, and paste your
message in this form box.  It did some kind of crude sendmail forgery
for you.

> Which brings up an interesting idea for an exitman/middleman remailer: Use
> a nym or commercial ISP to receive the mail, use throwaway free mail
> accounts for delivery (maybe even just plaintext delivery). Hotmail, at
> least, inserts an X-Originating-IP:  header, though.  

No problem -- run it through www.anonymizer.com first :-)

> I expect others do the same. So put your remailer output on a ZIP
> disk or floppy and run your delivery on whatever public or
> semi-public access machine you happen to get your hands on, once or
> twice a day.

You'd not want to use the same public access account regularly.

I think the connecting to the web based interface of one of those free
web gateways via www.anonymizer.com web based interface has potential.

However I wonder how long it will last...  I mean rocket mail or
whatever admins are going to get complaints like you do as a remailer
operator.

If it gets bad, they'll do what?  Not sure -- yank your account?  You
could get another one...

Turn the whole thing off?

Might last for a while.

Really we could do with some more general distributed solution to the
delivery problem.

Email forgeries seem like an interesting solution, either via an
exitman remailer which is basically just an email forging service, or
perhaps we could add capability "forger" to the remailer code.

How much trouble can you get in with ISPs for forging email?  Do they
care?  Would wide-spread practice of forging to avoid getting spammed
in USENET would cover you well enough?  How much extra security would
it give you?  Probably quite a lot -- the sorts of person who gets
spam baited is clueless almost by definition, and won't have a clue
where the mail came from.  Unless they enlist some technical help,
they'll be forced to just discard the email.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 8 Aug 1997, Adam Back wrote:

> Andy Dustman <andy@CCMSD.chem.uga.edu> writes:
> > 
> > Back to the subject: Disposable remailers. It seems the juno remailer
> > software would be good for this. I'm not sure what the sign-up requirement
> > are, but it's free. I was also thinking about web-based free mail
> > services, such as Hotmail and Rocketmail. Receiving mail means having to
> > parse some HTML, which from the looks of things is do-able but not
> > trivial. Sending mail might be easier to implement.
> 
> Sending mail is your problem alright.  It's where you get hit by
> spammers etc.

Ah, but if you only send through the disposable address, who cares? The
actually remailer address should never get seen (except on remailer lists,
of course). You could probably get away with never reading any incoming
mail, so spammers are not a problem.

> Wasn't there an email forgery web page around for a while.  The idea
> was that you filled in the details of who you wanted to send to, what
> address you wanted it to appear you had sent it from, and paste your
> message in this form box.  It did some kind of crude sendmail forgery
> for you.

Hmmm. Someone has recently been forging mail to appear to be from cracker
through something like this (very bad forgery, headers are all wrong).

> > Which brings up an interesting idea for an exitman/middleman remailer: Use
> > a nym or commercial ISP to receive the mail, use throwaway free mail
> > accounts for delivery (maybe even just plaintext delivery). Hotmail, at
> > least, inserts an X-Originating-IP:  header, though.  
> 
> No problem -- run it through www.anonymizer.com first :-)

Sure, Lance won't mind, right? At least, not if we subscribe... ;) Maybe
we need a network of anonymizing web proxy servers... 

> > I expect others do the same. So put your remailer output on a ZIP
> > disk or floppy and run your delivery on whatever public or
> > semi-public access machine you happen to get your hands on, once or
> > twice a day.
> 
> You'd not want to use the same public access account regularly.

I'm not thinking of an account so much as maybe a PC in a university
computer cluster. Pick one and go. At a big university there should be
several clusters around campus.

> I think the connecting to the web based interface of one of those free
> web gateways via www.anonymizer.com web based interface has potential.

It does, but I know The Anonymizer blocks some sites, at their request.

> How much trouble can you get in with ISPs for forging email?  Do they
> care?

Mindspring cares. My ISP was absorbed by them about two weeks after I
signed up. They say in their terms of service that impersonating someone
else is forbidden, but they specifically allow the use of anonymous
remailers and nicknames. I assume this means forging is frowned upon,
unless you are impersonating someone who doesn't exist, I guess.

Andy Dustman / Computational Center for Molecular Structure and Design / UGA
    To get my PGP public key, send me mail with subject "send file key".
For the ultimate anti-spam procmail recipe, send me mail with subject "spam"
"Encryption is too important to leave to the government."  -- Bruce Schneier
http://www.ilinks.net/~dustman    mailto:andy@CCMSD.chem.uga.edu      <}+++<


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQEPAwUBM+qADROPBZTHLz8dAQHJBwfQim/nARDmP1GQq/hV9duWoO+lRF4bE+D5
RoAibhsZUpyR1vBu754PX2OOAPIjVq+i0UkdFm17bn40zZz9FnJRo/RRead0JdYm
GVO0KSll1AkJsZCtCIWLwIrrwlFKfRehhBJsfLqSat0XF9sI5L8V8npg4bng4hOm
zmTLtbgaRM7wd25hm6Ld4EdCNRyz9BK/2jt1VBemo1X8mKMDgAbk9APn4V4t5u0A
KgN6Btpl+aYs5IUgPRz1D7gFPCcsNWz1JmB/hbdS+r4NL5+/6i/+f/0v7kwmlNMa
P7fQjiIa+/fq8ZMdKfUAwPN0R0VxYT09kC0gtPQU5pkxHQ==
=jH4c
-----END PGP SIGNATURE-----

Andy Dustman <andy@CCMSD.chem.uga.edu>
> > Wasn't there an email forgery web page around for a while.  The idea
> > was that you filled in the details of who you wanted to send to, what
> > address you wanted it to appear you had sent it from, and paste your
> > message in this form box.  It did some kind of crude sendmail forgery
> > for you.
> 
> Hmmm. Someone has recently been forging mail to appear to be from cracker
> through something like this (very bad forgery, headers are all wrong).

I said "wasn't there", as in past tense.  It got nuked years ago now
(literally) because of complaints.  When I looked at the page it still
had the text but a note that it was disabled, and why.

Just wandering if anyone knew if anyone else had set up something more
recently that still worked.

> > You'd not want to use the same public access account regularly.
> 
> I'm not thinking of an account so much as maybe a PC in a university
> computer cluster. Pick one and go. At a big university there should be
> several clusters around campus.

You might get away with that for a pretty long time, I guess.

> > I think the connecting to the web based interface of one of those free
> > web gateways via www.anonymizer.com web based interface has potential.
> 
> It does, but I know The Anonymizer blocks some sites, at their request.

Right.  So there is one anonymizer, and if we make a big game of using
this method, Lance will get threats, and at best be asked to block
them.  We need something more distributed.

That network of anonymizers isn't here yet.

> > How much trouble can you get in with ISPs for forging email?  Do they
> > care?
> 
> Mindspring cares. My ISP was absorbed by them about two weeks after I
> signed up. They say in their terms of service that impersonating someone
> else is forbidden, but they specifically allow the use of anonymous
> remailers and nicknames. I assume this means forging is frowned upon,
> unless you are impersonating someone who doesn't exist, I guess.

Well I was thinking along the lines of:

	bubba@dev.null

type addresses yes.  You ain't imitating anyone there.  I wonder if
they frown on generating non-replyable email addresses though.
Non-existant domains.  I speculated in the previous post that perhaps
the habit of using: 

	gizmo@netcom.com.NOSPAM

might make ISPs accustomed to having people use non-replyable email
address all the time.

Adam

-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Mark Grant <mark@unicorn.com> writes:
> On Wed, 6 Aug 1997, Adam Back wrote:
> > To do it properly, you'll need a local eternity server if you want to
> > good security of encrypted documents. 
> 
> I'd assume that in the end this is what most people would do; get a Usenet
> feed and run a server locally so that noone knows which URLs you're
> accessing. 

Indeed.  

Similar perhaps to web based remailer interfaces, you can turn on SSL,
but you're still trusting the server, relying on no hackers being able
to crack it, and relying on your estimate of the authenticity of it's
certificate

If there got to be a _lot_ of eternity documents this might get
impractical.  You wouldn't have the disk space for them all.

The distributed USENET cacheing setup could use cope with a big
archive because the content could also be distributed, and forwarded
on request.  So the complexities of doing something clever to allow
digital mixes to obscure your reading habits might come in again.

Incidentally, I think you could use the same methods to obscure
reading the virtual eternity web as you would use to obscure reading
the real web.  Eg. crowds, www.anonymizer.com.  http://*.eternity/
just happens to be likely to end up hosting a load of "hot" stuff
which you might not want to be caught reading in some countries.

> > Turn of logs, and introduce forward secrecy into mixmaster.  
> 
> That's not what I meant; I'm assuming that the mixmaster chain is
> pretty secure. The problem is that when the government find 'nuclear
> terrorist money-laundering kiddie drug porn' on the Eternity server
> they can trace it back to the original Usenet message and then go
> after the remailer operator who posted it. 

They might have a go at that yes.

> Making the remailers disposable or setting them up in free countries
> would work, but I'd prefer a technical solution.

That _is_ the technical solution!  (Disposable remailers).

Here's a repost of something I posted to remailer-ops on this topic at
around the time a few remailer operators felt the heat.  Nothing new
proposed, but this kind of argument was being hashed out here on
cypherpunks years ago, and we still don't have any disposable
remailers.  As close as we've got that I know is perhaps some
psuedo-anonymous remailer operators running off of cyberpass (Lance
offers anon shell accounts for ecash).

Adam

remailer-ops repost:
======================================================================
From: Adam Back <aba@dcs.ex.ac.uk>
To: mail2news@anon.lcs.mit.edu
Cc: remailer-operators@anon.lcs.mit.edu
Subject: disposable camouflaged tents (was Re: Balls remailer under attack.)
In-reply-to: <199706291539.RAA15722@basement.replay.com> (nobody@REPLAY.COM)
Date: Sun, 29 Jun 1997 23:45:40 +0100


Anonymous writes:
> I'm not sure that's a wise precedent to set.  Once you put the
> self-appointed censors and netcops in the driver's seat, who's to say
> where they might take us?

Agreed.

> [description of censors tatics]
>
> Maybe it's time that the censors were told to keep their noses out
> of our tents, for, like a camel, once you let it put its nose under
> the side of your tent, you soon have the entire camel taking over
> your tent!  Maybe it's time to bop a few intruding noses!

The solution is to have disposable tents, lots of.

What about AOL disks?  We need shorter lived, disposable remailers as
exit remailers...  Let them take the heat, while the real remailers
walk.  Lets see a series of "exitman" remailers.  Exitman remailers
are walking targets left to fend for themselves as long as they may.

I propose that an exit remailer is replaceable, that is another
remailer can instantly step into it's place and take traffic.  The way
to do this is to have a special automated reporting mechanism for
exitman remailers.  An easy way to do it is to have the exitman
remailers send mail to a given mailing list.  Other remailers which
wish to use exitman remailers just subscribe to the chosen mailing
list.  We just need a remailer command indicating the creation of a
new exitman remailer.  I guess the exitman remailer just sends one
message per day, or whatever, and if it stops, you write it off.

Is there a military term for something sent in to get shot to bits,
just to distract attention from other movement?  A decoy?


Also, what about camouflaging the disposable tent, so the camal can't
find it to poke it's nose in?  How about SMTP mail forgeries.
Wouldn't addresses of remailer42@dev.null fool a lot of these censorous
people?

I wonder if system admins in general would be very interested in
tracking down SMTP forgeries for censors?  If it was obvious what the
censorous shill was up to, or the large ISP sysadmin was just plain
overloaded with work he may just shrug his shoulders and say sorry,
can't be traced, get over it.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

On Wed, 6 Aug 1997, Adam Back wrote:

> Mark Grant <mark@unicorn.com> writes:
> > On Wed, 6 Aug 1997, Adam Back wrote:
> > > To do it properly, you'll need a local eternity server if you want to
> > > good security of encrypted documents. 
> > 
> > I'd assume that in the end this is what most people would do; get a Usenet
> > feed and run a server locally so that noone knows which URLs you're
> > accessing. 
> 
> Indeed.  
> 
> Similar perhaps to web based remailer interfaces, you can turn on SSL,
> but you're still trusting the server, relying on no hackers being able
> to crack it, and relying on your estimate of the authenticity of it's
> certificate
> 
> If there got to be a _lot_ of eternity documents this might get
> impractical.  You wouldn't have the disk space for them all.

This is where I see a problem with eternity servers.

If I were going to attack such a system, I would just start to have the
eternity servers store my core files or some other junk.  (Or maybe feed
it the SIMTEL or funet.fi archives.) Enough crap so that you could not
have enough space to store the real important stuff...

And then, if anyone did delete it out of the Eternity server(s), I would
yell "censorship" to the freedom knights and/or their fellow travelers...

alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.

On Wed, 6 Aug 1997, Mark Grant wrote:

> That's not what I meant; I'm assuming that the mixmaster chain is pretty
> secure. The problem is that when the government find 'nuclear terrorist
> money-laundering kiddie drug porn' on the Eternity server they can trace
> it back to the original Usenet message and then go after the remailer
> operator who posted it. Making the remailers disposable or setting them up
> in free countries would work, but I'd prefer a technical solution. 

I suggest using information dispersal to spread risk amongst remailer
operators.  Use Rabin's information dispersal technique to divide up a
document into n shares such that k of them can reconstruct the original,
and post each share via a seperate remailer.  It would be hard for the
government to single out an operator to go after since an individual share
by itself is useless.

If n>k this also increases reliability and resilience of the eternity
service against technical attacks.

Adam Back <aba@dcs.ex.ac.uk> writes:

> Mark Grant <mark@unicorn.com> writes:
>
> > so all that a government need do to censor a particular site is to
> > scan for those messages and issue cancels. Sure, your site and those
> > upstream may not accept such messages, but potentially they can
> > still wipe out a large fraction of the system or at least force
> > users to change their eternity URLs on a regular basis.
>
> Two comments on this:
>
> - I understand cancels are ignored a lot of places, due to problems with
>   censorous people, and pranksters issuing tons of forged cancels.
>   These censorous people are actually doing us a big favour because it
>   is their actions which has led to the widespread policy of ignoring
>   cancels.

Yep. (I hope my making available an easy-to-use program for foring cancels
helped a little too, he he he.)

>   However this is going on other peoples information.  I don't have
>   any figures for how widespread the practice of configuring news to
>   ignore cancels is.

Major ISPs (America Online, Netcom, Earthlink..) all ignore cancels.
More precise numbers would be interesting.

> However I'm not sure having passphrases is that good of an idea,
> because it'll be furtively passed around amongst the community of the
> person who submitted the documents, but that can always leak out.

I can't think of a clever way to use public keys (and don't think this
is a good idea anyway)

> Longer term perhaps some of Ross Anderson's more advanced ideas can be
> added, as discussed by Ryan Lackey in the thread entitled "distributed
> data store, a la eternity".

Adam, you're doing a great job. Can I buy you a dinner when I'm in London?

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps