Obfuscating traffic flow (Re: : Pornographic stories)

[Eric Ziegast <ziegast@va.pubnix.com>]

>>   So:
>>           What is the "real" reason for opposition to     
>>           strong crypto?  Who "really" benefits?  (and please
>>           don't mention the LE types 'cause I don't believe it).

A company may not want their employees to use crypto because they
want to be able to monitor their traffic.  When a company becomes
paranoid about trade secret protecion or corperate espionage,
worker's privacy is one of the first things to go.  It's the
company' choice though.  They may or may not know the legal can of
worms they'd be opening.

I can understand why LE types might be against strong crypto traffic,
but I'm not allowed to mention them here. ;^)

I would think that ISPs (and even commercial online services) would
prefer that their customers use strong crypto because it's less for
them to worry about ("Are they really sending pornography or death
threats though our network?").

The current protection for some service providers (at least the ones
with Internet-savvy lawyers) is primarlily contractual.  They have
their users agree to service agreements before their users allowed
to use their service.  Search your ISP service agreement for phrases
like ("customer holds harmless and indemnifies Company" or "does not
monitor traffic in any way" or "not responsible for data transmitted").

>>   and:
>>           Anyone else want to participate in the great '90's
>>           uucp revival?  I'm in Santa Clara and could use
>>           some feeds and some help with the setup.
>
> I'm all for it. My site is connected to the rest of the world via dial-up
> UUCP, I haven't touched the setup in 5 years, and am not planning to.
> 
> It might be interesting to have a variation of dial-up UUCP where site 1
> passes encrypted stuff to site 2 and doesn't quite know what site 3 they're
> supposed to go on to. Sort of like the remailers with encryption.

Mail flow obfuscation...

UUCP is only a store-and-forward transport mechanism.  The functionality
you're looking for just depends on the command you execute on the far
end.  People currently use something similar to:

	uux -p -r -z site1!rmail site2!sites3!user
     or
	uux -p -r -z site1!rmail site3!user	(if it's known that site1
						 can figure out how forward
						 mail to site3)

You'd basically be looking for another type of remailer that decrypts
a message to find out how to send it along tothe next hop.

On the sender's system, one could:

	cat message \
		| pgp -feast user \
		| encapsulate site3 \
		| encapsulate site2 \
		| encapsulate site1 \
		| uux -p -r -z site1!decap_remail

At site1, decap_remail would look into the message, decrypt it,
and know to forward it to site2...

	cat message \
		| uux -p -r -z site2!decap_remail

When it forwards the message, and information about where it got the
message from would be stripped (i.e. strip "Received:" or "From "
information it forwarded).  Bounces go to /dev/null.  The removal
of return path informaiton is the most important part of this
process.

At site2, we decrypt and forward to site3:

	cat message \
		| uux -p -r -z site3!decap_remail

At site3, we decrypt and find no message to forward, so it gets
sent to the local mailer for the user (message still encrypted).

Pros: At any point during the transmission, a site only knows the
      previous hop, and the next hop, and the rest is garbage.

      The message is encrypted throughout delivery in such a way
      that to trace a message, you need cooperation from all
      system administrators along the way (use long hop paths
      for more security!).

Cons: Debugging message routing problems is nearly impossible.
      One could possibly get around this by having the recipient
      confirm that the message was received.

      CPU utilization on the mailers would be more than the
      normal bit-shuffling.

      The sender needs to know the explicit path to get from point
      A to point X, to point Y, to point Z.  Either the user has
      to have key exchanges with each mailer down the path, or a
      public key system (can you say "UUCP maps"?) needs to exist
      so that any user withtl the maps can encrypt for any other
      mailer out there.

To optimize the process, one would only encrypt the envelope
information and leave the message intact (leaving it to the
user to encrypt).

Note: You don't need UUCP for this.  Any smart mailer like Sendmail
      or Smail can be configured for something like this.  You
      just need 10-20 sites in the Internet willing to provide this
      remailing service (for example, anon.penet.fi might be one.
      The goal is to make it administratively hard for people to
      compute traffic flow.  One would still use end-end encryption
      to protect message content.

--
Eric Ziegast

PS:  I don't read cypherpunks.  Someone forwarded this to me because
     they thought I'd be interested in the "UUCP" aspect.  If you
     respond and want me in on the discussion, feel free to CC: me.

PPS: Disclaimer: I'm not a crypto newbie.  Don't assume I know what
     I'm talking about.