Eternity Uncensorable?
Seems to me there's a fundamental flaw with the current Eternity server; as I understand it the messages are identified by a subject which is the SHA of their URL, so all that a government need do to censor a particular site is to scan for those messages and issue cancels. Sure, your site and those upstream may not accept such messages, but potentially they can still wipe out a large fraction of the system or at least force users to change their eternity URLs on a regular basis. It also doesn't provide true security, since when someone sets up an illegal site the gubment can find the messages on Usenet, decrypt them, and then threaten the remailer operator who posted them. I understand that this is just an alpha release, but I don't see any obvious way to fix these problems with a Usenet-based system. Mark
These comments are useful, as eternity needs some documentation, and I'm supposed to be writing an article for Phrack on this for deadline of this sunday, and arguing with people is a good way to get motivation to write explanations etc. This dual purpose is why this is a longish post. Mark Grant <mark@unicorn.com> writes:
Seems to me there's a fundamental flaw with the current Eternity server; as I understand it the messages are identified by a subject which is the SHA of their URL,
yup.
so all that a government need do to censor a particular site is to scan for those messages and issue cancels. Sure, your site and those upstream may not accept such messages, but potentially they can still wipe out a large fraction of the system or at least force users to change their eternity URLs on a regular basis.
Two comments on this: - I understand cancels are ignored a lot of places, due to problems with censorous people, and pranksters issuing tons of forged cancels. These censorous people are actually doing us a big favour because it is their actions which has led to the widespread policy of ignoring cancels. However this is going on other peoples information. I don't have any figures for how widespread the practice of configuring news to ignore cancels is. Perhaps we could do a little experiment here, you (or someone who has the tools/knowhow handy try cancelling the dozen or so eternity articles in alt.anonymous.messages, and we'll have a little survey amongst list readers as to how well the cancels work. - Comment #2. The eternity servers have caches. They cache documents. (This is configurable). There is currently no cache replacement policy because I haven't got around to it yet. So currently once viewed the docs stay there forever. (When I do get around to cache a replacement policy it will be either least accessed, and/or lowest ecash payment). I'm however not so keen to promote the idea that actually the docs you are looking at are coming off the servers cache because it's nicer to leave them presuming it was just read off the NNTP server right then (which it can be at the moment). It's a two stage process at the moment: - server reads news at some chosen internval and creates database of article number, subject field, and message-id field for subject fields which look like eternity documents. - some user comes along and types a URL which matches the chosen hash. Server fetches document from NNTP or local news spool using the article number as looked up in the database. Depending on the eternity.conf setting for cacheing (on/off/encrypted) and the document setting (on/off/encrypted) the document will be either not cached, cached in clear, or cached in encrypted form (with sha1( 1<url> ) where <url> is the url of the document). I could change it to a single stage process so that eternity documents are immediately cached. This is something easy to change, which could be done if people got trigger happy with cancels and it was affecting things. Then you would be left with cancel wars :-) The eternity server would grab the article at first opportunity though. Later versions of the software will have to exchange documents somehow, so then as long as one server saw the document before someone cancelled it you'd be ok. Clearly you could have an email submission channel where you just email the article to a server, but that gets away from the idea of pointing the finger at USENET. (Cacheing is somewhat protected in legislation even, because it's just a USENET document, and all you're doing is cacheing it according to some cache replacement policy). Some more technical explanations of what's going on encryption wise, is that articles in the news spool have an outer encryption layer which encrypts in one of these two ways: 1) with pgp -c and password "eternity" 2) with pgp -c and password of sha1( "1<url>" ) where url is the document url Inside this encryption layer is the document options (document url, per document cacheing policy, and a marker of whether the document is exdirectory or not (exdirectory docs not listed on document list). Plus an optional pgp key, and the ascii armored, optionally signed document. There is an optional inner layer of encryption, the ascii armored signed document can optionally be encrypted: 3) using a user selected passphrase Option 1) provides little more protection than rot-13. But should be of some use in that it prevents the less clued from reading the documents out of USENET directly. Option 2) means that you need to know the URL before you can access the document. Without the URL, you're hosed. Perhaps the URL is easy to guess, perhaps it's not: http://warez.eternity/safuwerqwkesadfiqwerdsf/ Option 3) means that you need the passphrase to read the document in addition to the URL. This has similar effect to having a garbled URL, choose a hard to guess passphrase. You can turn on SSL at the eternity server, but that means you're still trusting the operator, and root on the system. To do it properly, you'll need a local eternity server if you want to good security of encrypted documents. Easy enough to run a local eternity server if you're using linux on a ppp or permanently connected machine. My development machine is a ppp connected linux machine. However I'm not sure having passphrases is that good of an idea, because it'll be furtively passed around amongst the community of the person who submitted the documents, but that can always leak out. And people using non-local eternity servers will be revealing the shared passphrase to the server admin, (and to the snooping world, if the server isn't running with SSL turned on).
It also doesn't provide true security, since when someone sets up an illegal site the gubment can find the messages on Usenet, decrypt them, and then threaten the remailer operator who posted them.
Turn of logs, and introduce forward secrecy into mixmaster. Easy to do. Why don't we have it yet? (Ulf? Lance?) Then you have as true security as you can get from a digital mix with the parameters mixmaster has. Don't do too many regular updates of your eternty web pages for very high risk situations. Engineered network outages could show you up quickly even if you were using a DC-net covering 1 million users.
I understand that this is just an alpha release, but I don't see any obvious way to fix these problems with a Usenet-based system.
Does the above answer your concerns about security? Medium term software development-wise the eternity servers are going to have to exchange documents between themselves. At that point USENET will be functioning mostly as hard to tamper with distribution channel. The rest will be a distributed USENET caching system, with cache policy determined by popularity of document (hit count), and by ecash payment. Longer term perhaps some of Ross Anderson's more advanced ideas can be added, as discussed by Ryan Lackey in the thread entitled "distributed data store, a la eternity". Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
On Wed, 6 Aug 1997, Adam Back wrote:
However this is going on other peoples information. I don't have any figures for how widespread the practice of configuring news to ignore cancels is.
Ditto. We'd have to assume that it's pretty widespread to avoid these problems.
To do it properly, you'll need a local eternity server if you want to good security of encrypted documents.
I'd assume that in the end this is what most people would do; get a Usenet feed and run a server locally so that noone knows which URLs you're accessing.
Turn of logs, and introduce forward secrecy into mixmaster. Easy to do. Why don't we have it yet? (Ulf? Lance?)
Then you have as true security as you can get from a digital mix with the parameters mixmaster has.
That's not what I meant; I'm assuming that the mixmaster chain is pretty secure. The problem is that when the government find 'nuclear terrorist money-laundering kiddie drug porn' on the Eternity server they can trace it back to the original Usenet message and then go after the remailer operator who posted it. Making the remailers disposable or setting them up in free countries would work, but I'd prefer a technical solution. Mark
Mark Grant <mark@unicorn.com> writes:
On Wed, 6 Aug 1997, Adam Back wrote:
To do it properly, you'll need a local eternity server if you want to good security of encrypted documents.
I'd assume that in the end this is what most people would do; get a Usenet feed and run a server locally so that noone knows which URLs you're accessing.
Indeed. Similar perhaps to web based remailer interfaces, you can turn on SSL, but you're still trusting the server, relying on no hackers being able to crack it, and relying on your estimate of the authenticity of it's certificate If there got to be a _lot_ of eternity documents this might get impractical. You wouldn't have the disk space for them all. The distributed USENET cacheing setup could use cope with a big archive because the content could also be distributed, and forwarded on request. So the complexities of doing something clever to allow digital mixes to obscure your reading habits might come in again. Incidentally, I think you could use the same methods to obscure reading the virtual eternity web as you would use to obscure reading the real web. Eg. crowds, www.anonymizer.com. http://*.eternity/ just happens to be likely to end up hosting a load of "hot" stuff which you might not want to be caught reading in some countries.
Turn of logs, and introduce forward secrecy into mixmaster.
That's not what I meant; I'm assuming that the mixmaster chain is pretty secure. The problem is that when the government find 'nuclear terrorist money-laundering kiddie drug porn' on the Eternity server they can trace it back to the original Usenet message and then go after the remailer operator who posted it.
They might have a go at that yes.
Making the remailers disposable or setting them up in free countries would work, but I'd prefer a technical solution.
That _is_ the technical solution! (Disposable remailers). Here's a repost of something I posted to remailer-ops on this topic at around the time a few remailer operators felt the heat. Nothing new proposed, but this kind of argument was being hashed out here on cypherpunks years ago, and we still don't have any disposable remailers. As close as we've got that I know is perhaps some psuedo-anonymous remailer operators running off of cyberpass (Lance offers anon shell accounts for ecash). Adam remailer-ops repost: ====================================================================== From: Adam Back <aba@dcs.ex.ac.uk> To: mail2news@anon.lcs.mit.edu Cc: remailer-operators@anon.lcs.mit.edu Subject: disposable camouflaged tents (was Re: Balls remailer under attack.) In-reply-to: <199706291539.RAA15722@basement.replay.com> (nobody@REPLAY.COM) Date: Sun, 29 Jun 1997 23:45:40 +0100 Anonymous writes:
I'm not sure that's a wise precedent to set. Once you put the self-appointed censors and netcops in the driver's seat, who's to say where they might take us?
Agreed.
[description of censors tatics]
Maybe it's time that the censors were told to keep their noses out of our tents, for, like a camel, once you let it put its nose under the side of your tent, you soon have the entire camel taking over your tent! Maybe it's time to bop a few intruding noses!
The solution is to have disposable tents, lots of. What about AOL disks? We need shorter lived, disposable remailers as exit remailers... Let them take the heat, while the real remailers walk. Lets see a series of "exitman" remailers. Exitman remailers are walking targets left to fend for themselves as long as they may. I propose that an exit remailer is replaceable, that is another remailer can instantly step into it's place and take traffic. The way to do this is to have a special automated reporting mechanism for exitman remailers. An easy way to do it is to have the exitman remailers send mail to a given mailing list. Other remailers which wish to use exitman remailers just subscribe to the chosen mailing list. We just need a remailer command indicating the creation of a new exitman remailer. I guess the exitman remailer just sends one message per day, or whatever, and if it stops, you write it off. Is there a military term for something sent in to get shot to bits, just to distract attention from other movement? A decoy? Also, what about camouflaging the disposable tent, so the camal can't find it to poke it's nose in? How about SMTP mail forgeries. Wouldn't addresses of remailer42@dev.null fool a lot of these censorous people? I wonder if system admins in general would be very interested in tracking down SMTP forgeries for censors? If it was obvious what the censorous shill was up to, or the large ISP sysadmin was just plain overloaded with work he may just shrug his shoulders and say sorry, can't be traced, get over it. Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
On Wed, 6 Aug 1997, Adam Back wrote:
Mark Grant <mark@unicorn.com> writes:
On Wed, 6 Aug 1997, Adam Back wrote:
To do it properly, you'll need a local eternity server if you want to good security of encrypted documents.
I'd assume that in the end this is what most people would do; get a Usenet feed and run a server locally so that noone knows which URLs you're accessing.
Indeed.
Similar perhaps to web based remailer interfaces, you can turn on SSL, but you're still trusting the server, relying on no hackers being able to crack it, and relying on your estimate of the authenticity of it's certificate
If there got to be a _lot_ of eternity documents this might get impractical. You wouldn't have the disk space for them all.
This is where I see a problem with eternity servers. If I were going to attack such a system, I would just start to have the eternity servers store my core files or some other junk. (Or maybe feed it the SIMTEL or funet.fi archives.) Enough crap so that you could not have enough space to store the real important stuff... And then, if anyone did delete it out of the Eternity server(s), I would yell "censorship" to the freedom knights and/or their fellow travelers... alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply Alan Olsen | to my mail, just hit the ctrl, alt and del keys.
Mark Grant <mark@unicorn.com> writes:
On Wed, 6 Aug 1997, Adam Back wrote: The solution is to have disposable tents, lots of.
What about AOL disks? We need shorter lived, disposable remailers as exit remailers... Let them take the heat, while the real remailers walk. Lets see a series of "exitman" remailers. Exitman remailers are walking targets left to fend for themselves as long as they may.
I propose that an exit remailer is replaceable, that is another remailer can instantly step into it's place and take traffic. The way to do this is to have a special automated reporting mechanism for exitman remailers. An easy way to do it is to have the exitman remailers send mail to a given mailing list. Other remailers which wish to use exitman remailers just subscribe to the chosen mailing list. We just need a remailer command indicating the creation of a new exitman remailer. I guess the exitman remailer just sends one message per day, or whatever, and if it stops, you write it off.
Is there a military term for something sent in to get shot to bits, just to distract attention from other movement? A decoy?
A possible problem is the motivation of those setting up decoys. If they're doing it to help thwart remailer abuse, fine. But what if their intent is to thwart remailers? Couldn't these dissidents set up black-hole remailers which are simply information sinks? When a email is chain-remailed and doesn't get delivered many, but not all, senders would simply assume one of the remailers are having delivery problems and resend. Will Raph's approach work to monitor decoys when their number and identity are constantly changing? Won't this significantly complicate remailer clients? --Steve
Uggh another post which turned out hugely long... I cc'd to remailer ops due to remailer operator relevance. Steve Schear <azur@netcom.com> writes:
On Wed, 6 Aug 1997, Adam Back wrote: I propose that an exit remailer is replaceable, that is another remailer can instantly step into it's place and take traffic. The way to do this is to have a special automated reporting mechanism for exitman remailers. An easy way to do it is to have the exitman remailers send mail to a given mailing list. Other remailers which wish to use exitman remailers just subscribe to the chosen mailing list. We just need a remailer command indicating the creation of a new exitman remailer. I guess the exitman remailer just sends one message per day, or whatever, and if it stops, you write it off.
A possible problem is the motivation of those setting up decoys. If they're doing it to help thwart remailer abuse, fine. But what if their intent is to thwart remailers? Couldn't these dissidents set up black-hole remailers which are simply information sinks?
Good point, they could indeed. There is another related problem which is a real thorny one: Being exit only, the attacker will by definition know the email address the messages it forwards are being sent to. The attacker is trying to maximise his ability to disrupt, so he will be trying extra hard to conceal from remailer operators and their community that he is disrupting. Clearly the clever attacker in this situation, trying to disrupt the exitman-using middleman remailers reliability will let through anything going to a public forum, or to an email address he suspects is anything to do with Raph's pinging service. (Eg any address on the cypherpunks list or remailer-ops list as possible collaborators in the remailer reliability pinging). If the attacker is a Fed or spook or whatever, he will have good resources and ability to correlate destination email addresses to cypherpunks list members. Eg you get an account somewhere, they can find out by looking at your credit card logs, or whatever. Counter-measures? 1) Counter measure #1 A sop I can offer to this difficulty of detecting denial of service attacks, is that perhaps you could have the last middleman remailer send to a bunch of different randomly selected exitman remailers. So when you get some anonymous mail you get 10 copies of it. That way you can work out some stats for how likely someone who is operating 10 of 20 exit man remailers is to stop a given mail getting through. 1a) Counter-counter measure to 1) However if some of these remailers are operating from cracked accounts, rather than from anonymously purchased accounts, the attacker has an easy job of increasing his percentage of exitman remailers: take out the existing ones. Simple just email the admin of the cracked account -- he'll remove it. 2) Counter measure #2 Another idea, but really quite manual, would be to pick people who have advertised PGP keys, send them mail via some exitman remailer, and ask them politely to forward it to you. (Clearly sending through requests to "let me know if you recieve this email" aren't going to be recognized by the attacker, and let through if we send mail to people who don't have encryption capability). 2a) Counter-counter measure to 2) Course then the attacker can counter by letting through any encrypted mail without question. Stuck there aren't we :-( 3) Counter measure #3 Scraping the barrel here: what if we enlist the help of exitman remailers to check up on other exitman remailers? So now lets say we don't release a list of exitman remailers, but rather each exitman remailer privately announces itself to one randomly selected remailer privately. This is better in general because there is now no publically known list of exitman remailers. It is now harder for someone to use the list to just email all the admins in the hope that they will revoke paid for accounts (attacker makes legal threats, claiming to have receiving illegal material from this account or whatever), or to remove hacked accounts (real easy this one). With this setup we can send mail to one exit man via another one, with some chance that the first exitman won't recognize the other exitman. (You wouldn't want to overdo it with repeated mail, or the corrupt exitman might start to suspect the mail was another exitman). 3a) counter-counter measure to 3) It might be relatively easy for the well funded attacker to work out which addresses of those it receives to forward to are accounts with exitman installed. Eg. Watch the traffic from the host, after sending a bunch messages through remailers. Or simply finger the account see if the user ever logs in. (If it was hacked, it could be an active account, the user might never look at the forward file with |/home/oliver/... , nor the exitman remailer installed as "..." in some directory -- if it's working properly they won't see the email, and if it's forging email well they see replies). Incidentally exitman remailer hidden in "..." would allow a user to install it himself and plausibly claim ignorance, a more subtle way to obtain "disposable" exitman remailers. Best run from clearly non-technical users accounts with the knowing assistance of a technical assitant. 4) counter measure #4 An exitman remailer pinging service would be easily feasible for the post to USENET aspect (or to known mailing list), as the exitman remailer would show itself up quickly in this case. However I'm not sure this is so useful as mail2news gateways, and public postings generally (*) generate a lots less agro for their operators than a remailer. This is because people don't have to read USENET, and don't feel nearly so threatened as when they receive an anonymous mail aimed at them. And also because the mail2news gateway puts the senders address in the From field, which points the finger at the exit remailer anway. mail2news seems to be viewed as more neutral. If any mail2news operators have experiences which suggest otherwise I'd be interested to hear. (*) I did read of one case on remailer-operators where someone got hit by a remailer hater who used a remailer to post a fake advertisement of a CD full of commercial warez. The remailer-hater then anonymously tipped off the SPA. Incidentally I say "remailer-hater" here, but I should probably use a more term "remailer-attacker" or something, there could also feasibly be someone who is actually on our side (in a Zen sort of way) and trying to get us to face and solve the DoS and operators liability issues with technical solutions by demonstrating the current weaknesses. Some of these attacks are interesting for ordinary remailers also. Perhaps there exist right now normal (non-middleman) remailers which will send to another remailer in case it is a ping message, and anything that looks like an attempt to deliver to Raph, but junk the rest. Would we know? Anyway, overall I think the difficulty in checking on exitman remailers overall probably means that this simplest practical compromise for mail delivery from exitman remailers is for the last middle man remailer to send the mail to multiple exitman remailers. I also think the that the idea of exitman remailers privately announcing themselves to selected remailers might mean that they last longer, otherwise remailer haters will contact the admins and cause hassle even if they can't correlate any particular message came from a given remailer due to good mail forgery on the part of the exitman remailer. And using exitman remailers to post to USENET might be useful at some point if open access mail2news gateways got scarce.
When a email is chain-remailed and doesn't get delivered many, but not all, senders would simply assume one of the remailers are having delivery problems and resend. Will Raph's approach work to monitor decoys when their number and identity are constantly changing?
In theory yes. Send it via a couple of exitman remailers to make sure if you like. However the smart DoS attack described above is much harder to counter.
Won't this significantly complicate remailer clients?
Nope. The client won't need to know. You're not expected to send directly to an exitman remailer. That is something for remailer operators to use. You know how middleman operators work... they always, always send mail via another remailer and never deliver mail to a user. (I'm not sure if they detect this by looking to see if the address is on the remailer list, or just always add an extra hop?) So if there are some exitman remailers, a remailer operator that gets sick of the heat can switch to a new kind of middleman mode, where he always posts everything through various exitman remailers. (Or normal middleman mode, and leave the hassle of installing software to keep up to date on current exitmen to other exitman-using middleman remailers). Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
-----BEGIN PGP SIGNED MESSAGE----- On Thu, 7 Aug 1997, Adam Back wrote:
You know how middleman operators work... they always, always send mail via another remailer and never deliver mail to a user. (I'm not sure if they detect this by looking to see if the address is on the remailer list, or just always add an extra hop?)
I think by definition a middleman always chains through one or more additional remailers. When I ran dustbin, it was a "smart middleman", i.e., if the recipient was a known remailer, it wouldn't bother to chain (remailers rarely complain), otherwise it would chain through a single remailer. I have a procmail script which does this as well using mixmaster only (some definitions are missing here): # Smart middle. If not to another remailer, send it through a random mixmaster. # Mixmaster 2.0.3 compatible. :0 f * MIDDLE ?? (on|yes) *! ? grep "$TO" $RLIST $TYPE2 | formail -bf -I"From:" -I"To:" -I"Comments:" -IMessage-ID: \ | $MIXPATH/mixmaster -f -to $TO -l 0 # We made it this far, so send out the mail. :0 | $SENDMAIL $SENDMAILFLAGS An even smarter middleman would detect PGP messages and deliver those directly to end recipients, since those people are unlikely to complain about anonymous mail, and chain if the message was plaintext. The risk involved with this type of middleman operation should be rather small. Andy Dustman / Computational Center for Molecular Structure and Design / UGA To get my PGP public key, send me mail with subject "send file key". For the ultimate anti-spam procmail recipe, send me mail with subject "spam" "Encryption is too important to leave to the government." -- Bruce Schneier http://www.ilinks.net/~dustman mailto:andy@CCMSD.chem.uga.edu <}+++< -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQEPAwUBM+ouuhOPBZTHLz8dAQFMaQfPYwBpG+f05Oq/gu4nZDacu+0DDg/v/EgI IOZa4GCrNlhfbl0mp0XFLbEWLi8SvwWhpo6nhOFDIda7wcmyo032TfbcajNPEcz7 qeRNBEY2wDwp9B9MaXZlFyThnmnqsfgeU0h/c+txPiV48HsiX2uvG1NEKumqxq+e R1nqBS6Ob5uP+1urfqAbrdeTPdRSwlx+C9SlxMLLYpoPq5OM8YZu08UOBVWRE2FD ia4DvHCWVBsj2rpgiDrpWyMHAEbkoy9FJm5qUa2FqZq62TrS0rVugdjsE4mvisjM ULoalmkRHsByl/qUICRqSpktQQtveq2I3MEIHYSk7tEVJQ== =0FkI -----END PGP SIGNATURE-----
Andy Dustman <andy@CCMSD.chem.uga.edu> writes:
On Thu, 7 Aug 1997, Adam Back wrote:
You know how middleman operators work... they always, always send mail via another remailer and never deliver mail to a user. (I'm not sure if they detect this by looking to see if the address is on the remailer list, or just always add an extra hop?)
I think by definition a middleman always chains through one or more additional remailers. When I ran dustbin, it was a "smart middleman", i.e., if the recipient was a known remailer, it wouldn't bother to chain (remailers rarely complain), otherwise it would chain through a single remailer.
OK, so as you're the first person to implement a smart middleman I guess that defines the terminology :-) middleman "always adds another hop through a random remailer" smart middleman "posts through remailer when asked to deliver to anybody other than a known remailer" Wasn't there for a time a hidden middleman. That is a middleman remailer who's published address was a nym account on a nymserver? That'd be a "hidden middleman".
An even smarter middleman would detect PGP messages and deliver those directly to end recipients, since those people are unlikely to complain about anonymous mail, and chain if the message was plaintext. The risk involved with this type of middleman operation should be rather small.
Yep. Dimitri suggested on cypherpunks in the last round of discussion of this sort of thing another variation on that -- that you could deliver the mail if the person had a PGP public key on the keyservers -- whether the email was encrypted or not. On the assumption that people who use PGP would be unlikley to complain of anonymous mail. He also suggested beefing up keyserver submission checks (there are none right now) so that you need a replyable address to submit a key, otherwise the remailer-baiter just posts a key generated with their "victim's" email address on it prior to sending to them. Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
-----BEGIN PGP SIGNED MESSAGE----- On Thu, 7 Aug 1997, Adam Back wrote:
Wasn't there for a time a hidden middleman. That is a middleman remailer who's published address was a nym account on a nymserver? That'd be a "hidden middleman".
There's some now. medusa@squirrel.owl.de is one. middleman@cyberpass.net (reno) might be another (not sure the account is anonymous, but could be).
Dimitri suggested on cypherpunks in the last round of discussion of this sort of thing another variation on that -- that you could deliver the mail if the person had a PGP public key on the keyservers -- whether the email was encrypted or not. On the assumption that people who use PGP would be unlikley to complain of anonymous mail.
The only problem with that is the denial-of-service attack you describe below. I figure if it's already encrypted, delivery is likely to be welcomed rather than irritating.
He also suggested beefing up keyserver submission checks (there are none right now) so that you need a replyable address to submit a key, otherwise the remailer-baiter just posts a key generated with their "victim's" email address on it prior to sending to them.
Yeah, I had in mind some kind of magic cookie exchange using the submitted key. Once the cookie gets returned, the keyserver signs the key with a special signing key which certifies that the key has at least passed the "cookie exchange" test. The remailer I was working on (I say "was" because I just have been too darn busy to finish it) would have implemented that very thing. It's essentially the same thing the nymservers do when configured to confirm reply blocks, which they always are. Back to the subject: Disposable remailers. It seems the juno remailer software would be good for this. I'm not sure what the sign-up requirement are, but it's free. I was also thinking about web-based free mail services, such as Hotmail and Rocketmail. Receiving mail means having to parse some HTML, which from the looks of things is do-able but not trivial. Sending mail might be easier to implement. Which brings up an interesting idea for an exitman/middleman remailer: Use a nym or commercial ISP to receive the mail, use throwaway free mail accounts for delivery (maybe even just plaintext delivery). Hotmail, at least, inserts an X-Originating-IP: header, though. I expect others do the same. So put your remailer output on a ZIP disk or floppy and run your delivery on whatever public or semi-public access machine you happen to get your hands on, once or twice a day. Andy Dustman / Computational Center for Molecular Structure and Design / UGA To get my PGP public key, send me mail with subject "send file key". For the ultimate anti-spam procmail recipe, send me mail with subject "spam" "Encryption is too important to leave to the government." -- Bruce Schneier http://www.ilinks.net/~dustman mailto:andy@CCMSD.chem.uga.edu <}+++< -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQEPAwUBM+pqRBOPBZTHLz8dAQHyvAfPddrITrYKYCB7gmWuMyJxwWkCi+8oaZPZ Q3EMlQ2+Jfhw0gSHKYwfVHok6ttU5pGy3epwVBXSYAfs5Tge++3q2ZmoUAPuLRgx 1jv3akJnNrgnxTXVRNdrJDRs3rK1/5Xz7+GunK/zbdyicjxBJzVNaJL17i1R/Xr+ /r36YiBcueQBaEdJI3uqF08rj/63CFVuX5n6lun0cBvPxNK2wJ0WBknQeZsPHAjQ jbzu0hAkWZ1WYXLtLanzbn7TQrgMkMnVoRvu6JSdtxYEywd2aYhS/F1N6SKk6FiE DVEnoPRE42U/utHrEX30heLrSbD/fbwTruR1f1H4lTWMOg== =en6+ -----END PGP SIGNATURE-----
Andy Dustman <andy@CCMSD.chem.uga.edu> writes:
Back to the subject: Disposable remailers. It seems the juno remailer software would be good for this. I'm not sure what the sign-up requirement are, but it's free. I was also thinking about web-based free mail services, such as Hotmail and Rocketmail. Receiving mail means having to parse some HTML, which from the looks of things is do-able but not trivial. Sending mail might be easier to implement.
Sending mail is your problem alright. It's where you get hit by spammers etc. Wasn't there an email forgery web page around for a while. The idea was that you filled in the details of who you wanted to send to, what address you wanted it to appear you had sent it from, and paste your message in this form box. It did some kind of crude sendmail forgery for you.
Which brings up an interesting idea for an exitman/middleman remailer: Use a nym or commercial ISP to receive the mail, use throwaway free mail accounts for delivery (maybe even just plaintext delivery). Hotmail, at least, inserts an X-Originating-IP: header, though.
No problem -- run it through www.anonymizer.com first :-)
I expect others do the same. So put your remailer output on a ZIP disk or floppy and run your delivery on whatever public or semi-public access machine you happen to get your hands on, once or twice a day.
You'd not want to use the same public access account regularly. I think the connecting to the web based interface of one of those free web gateways via www.anonymizer.com web based interface has potential. However I wonder how long it will last... I mean rocket mail or whatever admins are going to get complaints like you do as a remailer operator. If it gets bad, they'll do what? Not sure -- yank your account? You could get another one... Turn the whole thing off? Might last for a while. Really we could do with some more general distributed solution to the delivery problem. Email forgeries seem like an interesting solution, either via an exitman remailer which is basically just an email forging service, or perhaps we could add capability "forger" to the remailer code. How much trouble can you get in with ISPs for forging email? Do they care? Would wide-spread practice of forging to avoid getting spammed in USENET would cover you well enough? How much extra security would it give you? Probably quite a lot -- the sorts of person who gets spam baited is clueless almost by definition, and won't have a clue where the mail came from. Unless they enlist some technical help, they'll be forced to just discard the email. Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
-----BEGIN PGP SIGNED MESSAGE----- On Fri, 8 Aug 1997, Adam Back wrote:
Andy Dustman <andy@CCMSD.chem.uga.edu> writes:
Back to the subject: Disposable remailers. It seems the juno remailer software would be good for this. I'm not sure what the sign-up requirement are, but it's free. I was also thinking about web-based free mail services, such as Hotmail and Rocketmail. Receiving mail means having to parse some HTML, which from the looks of things is do-able but not trivial. Sending mail might be easier to implement.
Sending mail is your problem alright. It's where you get hit by spammers etc.
Ah, but if you only send through the disposable address, who cares? The actually remailer address should never get seen (except on remailer lists, of course). You could probably get away with never reading any incoming mail, so spammers are not a problem.
Wasn't there an email forgery web page around for a while. The idea was that you filled in the details of who you wanted to send to, what address you wanted it to appear you had sent it from, and paste your message in this form box. It did some kind of crude sendmail forgery for you.
Hmmm. Someone has recently been forging mail to appear to be from cracker through something like this (very bad forgery, headers are all wrong).
Which brings up an interesting idea for an exitman/middleman remailer: Use a nym or commercial ISP to receive the mail, use throwaway free mail accounts for delivery (maybe even just plaintext delivery). Hotmail, at least, inserts an X-Originating-IP: header, though.
No problem -- run it through www.anonymizer.com first :-)
Sure, Lance won't mind, right? At least, not if we subscribe... ;) Maybe we need a network of anonymizing web proxy servers...
I expect others do the same. So put your remailer output on a ZIP disk or floppy and run your delivery on whatever public or semi-public access machine you happen to get your hands on, once or twice a day.
You'd not want to use the same public access account regularly.
I'm not thinking of an account so much as maybe a PC in a university computer cluster. Pick one and go. At a big university there should be several clusters around campus.
I think the connecting to the web based interface of one of those free web gateways via www.anonymizer.com web based interface has potential.
It does, but I know The Anonymizer blocks some sites, at their request.
How much trouble can you get in with ISPs for forging email? Do they care?
Mindspring cares. My ISP was absorbed by them about two weeks after I signed up. They say in their terms of service that impersonating someone else is forbidden, but they specifically allow the use of anonymous remailers and nicknames. I assume this means forging is frowned upon, unless you are impersonating someone who doesn't exist, I guess. Andy Dustman / Computational Center for Molecular Structure and Design / UGA To get my PGP public key, send me mail with subject "send file key". For the ultimate anti-spam procmail recipe, send me mail with subject "spam" "Encryption is too important to leave to the government." -- Bruce Schneier http://www.ilinks.net/~dustman mailto:andy@CCMSD.chem.uga.edu <}+++< -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQEPAwUBM+qADROPBZTHLz8dAQHJBwfQim/nARDmP1GQq/hV9duWoO+lRF4bE+D5 RoAibhsZUpyR1vBu754PX2OOAPIjVq+i0UkdFm17bn40zZz9FnJRo/RRead0JdYm GVO0KSll1AkJsZCtCIWLwIrrwlFKfRehhBJsfLqSat0XF9sI5L8V8npg4bng4hOm zmTLtbgaRM7wd25hm6Ld4EdCNRyz9BK/2jt1VBemo1X8mKMDgAbk9APn4V4t5u0A KgN6Btpl+aYs5IUgPRz1D7gFPCcsNWz1JmB/hbdS+r4NL5+/6i/+f/0v7kwmlNMa P7fQjiIa+/fq8ZMdKfUAwPN0R0VxYT09kC0gtPQU5pkxHQ== =jH4c -----END PGP SIGNATURE-----
Andy Dustman <andy@CCMSD.chem.uga.edu>
Wasn't there an email forgery web page around for a while. The idea was that you filled in the details of who you wanted to send to, what address you wanted it to appear you had sent it from, and paste your message in this form box. It did some kind of crude sendmail forgery for you.
Hmmm. Someone has recently been forging mail to appear to be from cracker through something like this (very bad forgery, headers are all wrong).
I said "wasn't there", as in past tense. It got nuked years ago now (literally) because of complaints. When I looked at the page it still had the text but a note that it was disabled, and why. Just wandering if anyone knew if anyone else had set up something more recently that still worked.
You'd not want to use the same public access account regularly.
I'm not thinking of an account so much as maybe a PC in a university computer cluster. Pick one and go. At a big university there should be several clusters around campus.
You might get away with that for a pretty long time, I guess.
I think the connecting to the web based interface of one of those free web gateways via www.anonymizer.com web based interface has potential.
It does, but I know The Anonymizer blocks some sites, at their request.
Right. So there is one anonymizer, and if we make a big game of using this method, Lance will get threats, and at best be asked to block them. We need something more distributed. That network of anonymizers isn't here yet.
How much trouble can you get in with ISPs for forging email? Do they care?
Mindspring cares. My ISP was absorbed by them about two weeks after I signed up. They say in their terms of service that impersonating someone else is forbidden, but they specifically allow the use of anonymous remailers and nicknames. I assume this means forging is frowned upon, unless you are impersonating someone who doesn't exist, I guess.
Well I was thinking along the lines of: bubba@dev.null type addresses yes. You ain't imitating anyone there. I wonder if they frown on generating non-replyable email addresses though. Non-existant domains. I speculated in the previous post that perhaps the habit of using: gizmo@netcom.com.NOSPAM might make ISPs accustomed to having people use non-replyable email address all the time. Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
On Wed, 6 Aug 1997, Mark Grant wrote:
That's not what I meant; I'm assuming that the mixmaster chain is pretty secure. The problem is that when the government find 'nuclear terrorist money-laundering kiddie drug porn' on the Eternity server they can trace it back to the original Usenet message and then go after the remailer operator who posted it. Making the remailers disposable or setting them up in free countries would work, but I'd prefer a technical solution.
I suggest using information dispersal to spread risk amongst remailer operators. Use Rabin's information dispersal technique to divide up a document into n shares such that k of them can reconstruct the original, and post each share via a seperate remailer. It would be hard for the government to single out an operator to go after since an individual share by itself is useless. If n>k this also increases reliability and resilience of the eternity service against technical attacks.
To follow up to my own post briefly, I said: : Clearly you could have an email submission channel where you just : email the article to a server, but that gets away from the idea of : pointing the finger at USENET. If the machine hosting the eternity server also has a mail2news gateway (eg replay has mail2news@replay.com), then modify the mail2news program to forward a copy to eternity@replay.com for newsgroups that the eternity server is interested in. That way it's still a USENET post. Just you're stacking the odds against the cancel forger :-) The cancel forger can't get there before you unless he can read your mind (or your email), but it wouldn't matter if he could, because eternity would see the document anyway. http://www.replay.com/aba/eternity/ is reading it's news from nntp:news.xs4all.nl, but I don't know what their cancel settings are for their news spool. Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
-----BEGIN PGP SIGNED MESSAGE----- On Wed, 6 Aug 1997, Adam Back wrote:
Mark Grant <mark@unicorn.com> writes:
[...]
so all that a government need do to censor a particular site is to scan for those messages and issue cancels.
- I understand cancels are ignored a lot of places, due to problems with censorous people, and pranksters issuing tons of forged cancels.
And alot like to use canceles. If censorus groups (not neccery the goverment) starts canceling we may be able to create a resector like that used in news.admin.net-abuse.* [...]
I don't have any figures for how widespread the practice of configuring news to ignore cancels is.
Most sites still hounder cancels, a growing number ignore them (often for preformence resons). - -- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. ex-net.scum and proud You Say To People "Throw Off Your Chains" And They Make New Chains For Themselves? --Terry Pratchett -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBM+ifYqQK0ynCmdStAQEhzwQAnw82Mk6XNlvQRUGVDVsBW63vOkFBZDV/ oLz3BUFTnrn4mHZxwuU2s+j1O2s7aLZP/ImD69XePILqKJDYiMJ6A6nc0reirNZ0 6WlkPl6jgpqWL8SKNidisjDWmwMXoYdkE6HSUB2rGoLgrtzvw4RXc6XcnQcG2Zb0 b8andhqfeTs= =POHl -----END PGP SIGNATURE-----
? the Platypus {aka David Formosa} <dformosa@st.nepean.uws.edu.au> writes:
On Wed, 6 Aug 1997, Adam Back wrote:
Mark Grant <mark@unicorn.com> writes:
[...]
so all that a government need do to censor a particular site is to scan for those messages and issue cancels.
- I understand cancels are ignored a lot of places, due to problems with censorous people, and pranksters issuing tons of forged cancels.
And alot like to use canceles. If censorus groups (not neccery the goverment) starts canceling we may be able to create a resector like that used in news.admin.net-abuse.*
A clarification is in order: The "resurrector" in news.admin.net-abuse.* is run by none other than the child-molesting pedophile Chris Lewis. It does NOT repost cancelled articles when the author is someone Lewis doesn't like - such as myself. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
Adam Back <aba@dcs.ex.ac.uk> writes:
Mark Grant <mark@unicorn.com> writes:
so all that a government need do to censor a particular site is to scan for those messages and issue cancels. Sure, your site and those upstream may not accept such messages, but potentially they can still wipe out a large fraction of the system or at least force users to change their eternity URLs on a regular basis.
Two comments on this:
- I understand cancels are ignored a lot of places, due to problems with censorous people, and pranksters issuing tons of forged cancels. These censorous people are actually doing us a big favour because it is their actions which has led to the widespread policy of ignoring cancels.
Yep. (I hope my making available an easy-to-use program for foring cancels helped a little too, he he he.)
However this is going on other peoples information. I don't have any figures for how widespread the practice of configuring news to ignore cancels is.
Major ISPs (America Online, Netcom, Earthlink..) all ignore cancels. More precise numbers would be interesting.
However I'm not sure having passphrases is that good of an idea, because it'll be furtively passed around amongst the community of the person who submitted the documents, but that can always leak out.
I can't think of a clever way to use public keys (and don't think this is a good idea anyway)
Longer term perhaps some of Ross Anderson's more advanced ideas can be added, as discussed by Ryan Lackey in the thread entitled "distributed data store, a la eternity".
Adam, you're doing a great job. Can I buy you a dinner when I'm in London? --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
participants (9)
-
? the Platypus {aka David Formosa} -
Adam Back -
Alan -
Andy Dustman -
dlv＠bwalk.dm.com -
Mark Grant -
Steve Schear -
ulf＠fitug.de -
Wei Dai