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.