Re: My anonymous remailer
: Still, though, I think this would do more harm than good. I get about : 20 to 40 messages a day through my remailer, and only 5 or 10 of those are : encrypted. Switching to a policy that would require chaining and encrypt- : ing to make it useful would make it a lot harder to use the remailer. If Agreed, but it would also force us to get off our butts and make integrated remailer-aware mailers work properly, as opposed to the broken kludges we have at the moment. In the long term it would be for the better. (Every single time I've tried anything fancy with chaining and encryption, it hasn't been delivered. And I don't consider myself incompetant.) : The other problem I see with Graham's idea is that I'm not sure the : technology is there to provide good security in the face of this much : information. Not many of the remailers add delay, and a lot of people don't : like it when they do. In that case it may be easy to figure out what Again, fixing this up would be for the better good. You can just imagine that the FBI is already watching all remailers closely under arm-twisting from the Software Publishers Association, not to mention the NSA doing likewise for their own reasons. I think we *should* force ourseles to make traffic analysis visibly impossible. If we can crack an anon posting path with the same information available to an attacker who can monitor all the lines, our system is broken. We should put it up for peer-group testing just like a new encryption algorithm. I believe the security of current remailers is a joke against a real attack. It's *only* good enough to hide identity from other usenet readers. We might as well all use only one-hop remailers and stop kidding ourselves that the multi-hop stuff does any good at all. (I don't believe the anti-traffic analysis support of the current remailers is any good, which is why any postings I've made through remailers have been single-hop in clear. I just don't post anything that would get me in legal trouble. OK, maybe a couple of posts I've made would be personally embarrassing if I were outed, but I wouldn't be by any LEAs that were watching. They'd just be able to use logged postings in criminal cases) : path even a chained encrypted message took. Even the delaying remailers, : if they published message sizes, would usually reveal their in-to-out : correspondance. So I think it is premature to do this. Until we have : remailers which can support cryptographically strong message padding : with standard message sizes, running on un-hackable systems with delays : and batching to confuse the in-out relationships, it would be counter- : productive to do what Graham suggests. Precisely my point. Except I see it the other way - as long as we're not forced to implement these measures properly, they'll never happen. : service it's hard to know what features to provide. In particular, if : cleartext output is prevented, how much does that impair the usefulness of : the network? My instinct is that it hurts a lot, although it would be nice : for the operators since it would eliminate most sources of complaints. I meant that cleartext *input* should be prevented. Cleartext output however can be 'outed' in accordance with policy, even if it's personal mail. Also it can be silently dropped on the floor by the last-hop admin without any comeback, for whatever egregious reason he chooses, or even randomly. It's up to the sender to pick a route that works. If some remailer admin (like JGdeA, or was it John Stanley?) choses to allow M.M.F postings, then he can take the heat for them personally. It's impossible to tell an email recipient apart from a mail to news gateway, so we can't enforce encrypted output only, if we allow posting. However, the 'outing' policy makes it in people's best interests to encrypt to the destination user if they can. Unencrypted *mail* as well as news is also fair game for the last-hop remailer admin to delete on his personal whim. G PS When I say we should out all information, I'm only talking about information that's visible going in and out. If we ever get my earlier idea of chained encrypted reply-addresses to work, with time-sensitive keys that are deleted after a few days, I'm not suggesting publishing those keys. Certainly, we should assume that a few sites will be broken into, or even many sites, but as long as one site remains uncompromised, there's a strong link in the chain that holds up the entire chain.
Again, the best way to build a secure remailer is to have one that sends a fixed "remailer-packet" to other mailers for internal communication with other remailers on the "network" These packets should all be super-encrypted and of a fixed size. This size should be as small as possible. Say around 200K or so. Why? Because this serves to prevent email spamming by severly delaying a message. Also if there is some quota of say, no more than 100 messages a day from a user, it serves to limit spamming quite a bit. Basically all incoming mail is spooled on the remailer's hard drive in encrypted form by the remailer. When a new message is sent to the remailer, the remailer will go through all the received messages and look for duplicate messages and also count the number of messages sent by the user who just submitted another one. At the end of the day, at a certain hour agreed upon by the remailer operators, the remailer will split up its cached messages and split them among several remailers with a RANDOM number of hops set in the message. These packets will then be randomly padded inbetween messages with null messages which would be eaten by the receiving remailer. The padding serves to limit traffic analysis and the automatic hop number helps idiot users from being caught. The packets will then be compressed and then would be encrypted with the respective public key of the target remailer and sent as a fixed sized block again with rand padding at the end... perhaps via ftp or some other protocol, but not necessarily via sendmail. Having them as binary makes them easier to handle than by sendmail... When the packet is received by a remailer it would first decrypt it, then decompress it, then remove null messages, then decrement the number of hops and if it's zero, it would invoke sendmail to send them. I strongly suggest that the remailer packet protocol be openly published so that users can build their own packets to forward to remailers in encrypted form rather than using sendmail. I suppose that using sendmail to a remail should still be allowed, but slowly phased out so as to force users to encrypt their email. Client software can be written for Windoze and Macs to use TCP/IP or even Zmodem a packet into a remailer. You may think that spamming can still occur by allowing users to send packets themselves, however if the recepient remailer will limit the size of a packet it will receive to a very small size (especially if it's coming from an unknown site,) and refuse to receive more than one packet per day from that site, it would prevent a lot of spamming and creeping detweilerism. Perhaps remailers can work out a set of special private keys which they share between them to speed up mail, or the size of the packet can be increased for remailer-remailer transfers. Anyhow, the system has to be balanced so that mail gets there in at most a day or so, at best only a few hours depending on how often remailers talk to each other. If traffic at a remailer should suddenly increase, the remailer should issue instructions to the other remailers that it'll send larger packets or send more often. But only after it receives permissions from the other remailers should it send. Perhaps if a remailer is too filled it should bounce a message to the sender (if it knows his/her address...) or perhaps they can be polled to see if they're busy, or better yet, the message can be forwarded to another remailer in the old fashioned way (losing some security I guess)
participants (2)
-
gtoal＠an-teallach.com -
rarachel＠prism.poly.edu