Re: Pornographic stories

jadestar@netcom.com (JaDe) writes:
> >
> > Daniel Miskell <DMiskell@envirolink.org> writes:
> >>>I'm sure.
>
> > I too fail to see the cryptorelevance of this thread... Unless
> > alt.sex.stories is used for steganography... Alice wants to send a
> > secret message to Bob, so she posts a porn story to alt.sex.stories,
> > where the key phrase is "That was the best sex I've ever had", which
> > sounds like a mild hyperbole to most people;
>
> 	I like the stegonography angle.  However I'd encode the
> 	actual message contents into the typos.  Filter out the
> 	typos to retrieve your crypto-text.

Wouldn't text with a lot of typoes look suspicious? For ultimate silliness,
I've put together the following program to encode 8 bits at a time in an
R-rated sentence:

#include <stdio.h>

#define BIT(c,n) ((c>>n)&1)

const char*bits[]={
"Senator Exon",                         "L.Ron Hubbard",
"made passionate love to",              "had great sex with",
"Hillary Klinton",                      "J.D.Falk",
"experienced",                          "gave her",
"six",                                  "twelve",
"in",                                   "during",
"one",                                  "a single",
"night",                                "weekend"};

void stegaporn(int c)
{

printf("%s %s %s and %s %s orgasms %s %s %s.  ",
bits[BIT(c,7)], bits[2+BIT(c,6)], bits[4+BIT(c,5)], bits[6+BIT(c,4)],
bits[8+BIT(c,3)], bits[10+BIT(c,2)], bits[12+BIT(c,1)], bits[14+BIT(c,0)]);
}

int main(void)
{
int c;

while (EOF!=(c=getchar()))
 stegaporn(c);

return(0);
}

> 	Ultimately I think that the whole issue of legal cryptography
> 	actually boils down to this:
>
> 		If you illegalize strong crypto than criminals will
> 		simply resort to steganography and "hidden" channels
> 		of communication (in which they can also embed/tunnel
> 		the crypto-text of their strongly encrypted data).
>
> 		Therefore all you've done is create a lesser crime
> 		for the real criminals and make people with valid
> 		(non-criminal) uses of the technology into criminals.
>
> 	Unfortunately this reasoning doesn't help at all with our
> 	(U.S.) legislature.  There is some hidden aggenda as to
> 	why "they" really want strong cryptography to be difficult
> 	for the average user to obtain.  I have a uniquely hard time
> 	believing that "they" are merely concerned that "we" might
> 	be pursuing simple privacy (even if cryptography were already
> 	illegal I could use it for years and never get "caught."
> 	so long as I was using non-broadcast channels and communicating
> 	with "trusted" associates (fellow "crypto-criminals")
>
> 	In fact I've suggested to several people that we start
> 	a dial-up uucp revival for this and related reasons.  (If
> 	the number of users/webpages and the bandwidth usage continues
> 	to increase at the recent rates -- without a corresponding
> 	improvement in the infrastructure we'll probably all want to
> 	go back to uucp for mail and news anyway.  Old fashioned dial-up
> 	may be faster than T1 access in a few years and direct point-to-
> 	point uucp over ISDN is probably faster already.
>
> 	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).
>
> 	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.

---

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

>>   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.

On Thu, 14 Dec 1995, Dr. Dimitri Vulis wrote:

> > 	In fact I've suggested to several people that we start
> > 	a dial-up uucp revival for this and related reasons.  (If
> > 	the number of users/webpages and the bandwidth usage continues
> > 	to increase at the recent rates -- without a corresponding
> > 	improvement in the infrastructure we'll probably all want to
> > 	go back to uucp for mail and news anyway.  Old fashioned dial-up
> > 	may be faster than T1 access in a few years and direct point-to-
> > 	point uucp over ISDN is probably faster already.
[...]
> > 		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.

This definitely seems like a good idea to me, especially with the 
encrypted link.  Is the encrypted link software written, or need we hack 
a few perl scripts?

The mechanics seem simple enough....


------------------------------------------------------------------------------
JonJon Lasser                <jlasser@rwd.goucher.edu>            
(410)494-3072 
          Visit my home page at http://www.goucher.edu/~jlasser/
  You have a friend at the NSA: Big Brother is watching. Finger for PGP key.