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.
participants (3)
-
dlv＠bwalk.dm.com -
Eric Ziegast -
Jon Lasser