re: Do not taunt happy-fun-court.
Black Unicorn said: There are a few cypherpunks probably listening to this who've been smacked with subpoenas for running remailers. I think you'll find that the government is pretty persuasive to third parties like these. The only defense (which one administrator of a remailer I won't name was clever enough to set himself up with) is to say (my paraphrasing) "I don't have access to those logs or any of that data. I don't keep such logs and I never have because it's too much overhead and work." -- I suspect I'm the remop being referred to here, so I'll comment: That defense is valid because it is true. It isn't a contrived excuse for not keeping logs that I conveniently pull out of the wings to protect the anonymity of my users. Keeping logs really is too much of a resource drain on my system. At some point I will probably begin keeping logs that expire after a period of several hours, so that I can identify and block spammers. I'm interested in your thoughts on this, Uni. Is the defense "I never retain logs longer than 2 hours; they are automatically deleted out of disk space considerations" as string as the first one? (This is how many remailers are configured. But even if the remailers all kept logs, if users are chaining their messages through multiple remailers, anonymity should still be preserved.) Regardless, I haven't had the time to implement such a system anyway. My point here is that, if you are going to be using the "off-shore attorney" system of preserving your data, I think it would be helpful if there was a legitimate reason for placing your information in the hands of this other entity (other than protection from the US courts.)
----- Original Message -----
From: "Anonymous"
Black Unicorn said:
There are a few cypherpunks probably listening to this who've been smacked with subpoenas for running remailers. I think you'll find that the government is pretty persuasive to third parties like these. The only defense (which one administrator of a remailer I won't name was clever enough to set himself up with) is to say (my paraphrasing) "I don't have access to those logs or any of that data. I don't keep such logs and I never have because it's too much overhead and work."
--
I suspect I'm the remop being referred to here, so I'll comment:
That defense is valid because it is true. It isn't a contrived excuse for not keeping logs that I conveniently pull out of the wings to protect the anonymity of my users. Keeping logs really is too much of a resource drain on my system.
Oh, I didn't mean to suggest that it was artifice in this particular case, apologies if I implied or stated it was.
At some point I will probably begin keeping logs that expire after a period of several hours, so that I can identify and block spammers. I'm interested in your thoughts on this, Uni. Is the defense "I never retain logs longer than 2 hours; they are automatically deleted out of disk space considerations" as string as the first one? (This is how many remailers are configured. But even if the remailers all kept logs, if users are chaining their messages through multiple remailers, anonymity should still be preserved.)
See my (huge) posting on this, but I would suspect that this isn't great. Were I operating one, which I am admittedly not, I'd want there to be no data of evidentiary value ever hitting my memory or media. To some degree that's not possible. In the alternative, actually _disabling_ logging is the best policy, in my view. The evidence never existed in the first place then. It suddenly becomes a challenge to show some kind of conspiracy on your part since the actual spoliation claim is harder to make. Showing conspiracy for anything with respect to either probably starts hard and gets marginally less hard in this order: a) A middle remailer in a multiple chain that knows nothing (little) about original sender, content or recipient. The only evidence of value here would be: Time of message traversing the mailer (only useful if the specific message can be linked to the sender which- if mixmaster works- isn't feasible). Size of message (only useful if the specific message can be linked to the sender and only useful in so far as the message can be constituted and be said to be "at least size X" which- if mixmaster works- isn't feasible b) A back end remailer in a multiple chain that knows nothing (little) about content or original sender. Evidence here in addition to the above: Recipient address. Recipient public key (if content is encrypted before mixmaster). Time of actual delivery to recipients SMTP server. c) A front end remailer in a multiple chain that knows nothing (little) about content or recipient. Evidence here in addition to a) : Sender address. d) A "one hop" remailer. Evidence available: All of the above. Given that even d) doesn't provide much (and less than not much if you're never allowing logs to be written in the first place) you can probably make some guesses about the likelihood of being vulnerable here.
Regardless, I haven't had the time to implement such a system anyway.
My point here is that, if you are going to be using the "off-shore attorney" system of preserving your data, I think it would be helpful if there was a legitimate reason for placing your information in the hands of this other entity (other than protection from the US courts.)
I really suggest that. Remember that you're going to have to convince people, not code, or automated rule sets, that you're a decent and non-criminal person if you do get called to the mat. Specious sounding arguments about "document destruction policies" and the like, while perhaps totally technically correct, aren't necessarily going to help you much- as the mountain of case crap I just typed in earlier should show. Since this has become a loud and argumentative issue perhaps it's time for one of the "what remains to be done" postings I used to do with a long section on what the next set of remailers should be incorporating. Advice that will be ignored or regarded, depending on the moods of the listeners perhaps.
On Wed, 1 Aug 2001, Black Unicorn wrote:
See my (huge) posting on this, but I would suspect that this isn't great. Were I operating one, which I am admittedly not, I'd want there to be no data of evidentiary value ever hitting my memory or media. To some degree that's not possible. In the alternative, actually _disabling_ logging is the best policy, in my view. The evidence never existed in the first place then. It suddenly becomes a challenge to show some kind of conspiracy on your part since the actual spoliation claim is harder to make. Showing conspiracy for anything with respect to either probably starts hard and gets marginally less hard in this order:
a) A middle remailer in a multiple chain that knows nothing (little) about original sender, content or recipient.
The only evidence of value here would be: Time of message traversing the mailer (only useful if the specific message can be linked to the sender which- if mixmaster works- isn't feasible). Size of message (only useful if the specific message can be linked to the sender and only useful in so far as the message can be constituted and be said to be "at least size X" which- if mixmaster works- isn't feasible
b) A back end remailer in a multiple chain that knows nothing (little) about content or original sender.
Evidence here in addition to the above: Recipient address. Recipient public key (if content is encrypted before mixmaster). Time of actual delivery to recipients SMTP server.
c) A front end remailer in a multiple chain that knows nothing (little) about content or recipient.
Evidence here in addition to a) : Sender address.
d) A "one hop" remailer.
Evidence available: All of the above.
Given that even d) doesn't provide much (and less than not much if you're never allowing logs to be written in the first place) you can probably make some guesses about the likelihood of being vulnerable here.
Regardless, I haven't had the time to implement such a system anyway.
My point here is that, if you are going to be using the "off-shore attorney" system of preserving your data, I think it would be helpful if there was a legitimate reason for placing your information in the hands of this other entity (other than protection from the US courts.)
I really suggest that. Remember that you're going to have to convince people, not code, or automated rule sets, that you're a decent and non-criminal person if you do get called to the mat. Specious sounding arguments about "document destruction policies" and the like, while perhaps totally technically correct, aren't necessarily going to help you much- as the mountain of case crap I just typed in earlier should show.
Since this has become a loud and argumentative issue perhaps it's time for one of the "what remains to be done" postings I used to do with a long section on what the next set of remailers should be incorporating.
Advice that will be ignored or regarded, depending on the moods of the listeners perhaps.
igor (v 0.1) 4-11-01 A remailer for Plan 9 by James Choate ravage@ssz.com http://einstein.ssz.com/hangar18 One of the primary values of the Internet is email. It provides a reliable and consistent link across time and space. It is the proto-typical killer app. However, to use email effectively there should be two additional features. We don't promise more don't exist. The first feature is the ability to reflect or remail a single email to many recipients. The second is to strip identifying header information from the sender prior to the subscriber getting it. igor does not use 'embedded routing commands' like many other anonymous remailer packages. We believe that tampering or altering the body of the email is simply wrong. We offer two way to input data into igor. The first is through Subject: line escaped commands and the second is through additional header files. An example of each is, Subject: Some title or other [igor: some_commands, must_come_last] or, X-igor: some_commands This allows the first remailer to strip the command data out and then process the email as if igor had never been involved. igor supports limited routing selection, which is intended to make traffic analysis harder. igor sends individual emails embedded in igor-specific header info to eliminate as much interaction with the email itself. All inter-igor traffic is encrypted with PK's managed by the Evil Geniuses. With respect to key management, I am not a big believer in current schemes. I don't believe the 'PGP Ring of Trust' is workable because of scaling problems. What I intend is for each remailer to 'know' only a small group of other remailers (limited to three for testing, but the design will support an unlimited number technicaly). So, when igor_1 hands off to igor_2, all igor_2 knows is that he's k in a n-length chain. He subtracts one and randomly selects another igor other than igor_1 to send it to. The remailer igor_2 sends it to, igor_3, will NOT know about igor_1 so it is completely possible that igor_3 may send an email right back to igor_1 for delivery to the recipient. Provided of course that igor_1 and igor_3 have had prior communications. The intent, at least in simple principle, was to allow each key to be 'authorized' to the standards of each operator. I felt this offered a reasonably strong approach and should handle scaling well. On the flip sice, if igor_2 sends covor traffic he won't send it to igor_1 for that mail. I felt that sending igor_1 any sort of traffic was counter productive unless you always sent traffic back to the initiator remailer. This seems 'evil' to me. It's a start... My current problem is deciding what encryption scheme to use for inter-igor relays...? Plan 9 is an operating system developed by the fathers of *nix to 'fix' the problem of *nix. The system has integrated and fully scalable I/O-authorization kernels, process kernels, and file system kernels. Each kernel is connected through a authorization mechanism that doesn't send keys over the network. The low level network layer, Plan 9, is currently implimented with DES. At some point this should be replaced with something a tad more stout. It also needs a mechanism to anonymize file and process space access. Strong crypto is clearly a pre-requisite for this. Once those features are in place a true 'Data Haven' could be easily implimented. Plan 9 is open source and can be obtained from, http://plan9.bell-labs.com The only transvestite operating system in existence, and so what if the bunny is ugly? Route Commands (ie igor: * * ...): strip Strip the From: header zombie Strip the From: header and replace with From: Walking Dead (dead@ssz.com) Traffic TO dead@ssz.com would go to /dev/null. route# Route the message through # other igor nodes, not selectable by the user, where # is from 1 to 3. route0 is assumed and means send to recipient directly cover Provide cover traffic for each outbound email by sending all know igors a single bogus email. This provides n-copy cover traffic. subscribe $ Subscribe to mailing list $ Example: To: igor@ssz.com Subject: [igor: subscribe {some user@place} cypherpunks] If no user, use From:@ who $ Who is subscribed to list $? info $ Provide info on list $ help Request an info-help file igor Configuration Parameters (igor.conf): MyPubKey This remailers public key, non-traffic related encryption key. Used for encrypting traffic or data. MyOwnKey This remailers private key, non-traffic related de-cryption key. Used for decrypting traffic or data. MyPubRing My public key ring, this contains a mapping of each 'authorized' igor remailer we will operate with. We use this key to encrypt traffic TO the listed remailers. There are no line length limits. e.g. igor@foo.bar#242ds032fdsasetewdvdsasdfewwere... igor@bar.org#2303210343203828353234898324397... cypherpunks@ssz.com#23XD24398dDWSc35K2)3C2#d... ... MyOwnRing My private key ring, this contains a mapping of each 'authorized' igor remailer we will operate with. We use this key to decrypt traffic FROM the listed remailers. GHeader: $ Place this at the beginning of all emails through this remailer GFooter: $ Place this at the foot of all emails through this remailer Open: *, *, *, ... These mailing lists will provide all info to any reqeustor List: *, *, *, ... These mailing lists will provide info only to a current subscriber Close: *, *, *, ... These mailing lists will not provide any info Verify: *, *, *, ... These mailing lists always verify each operation through the Evil Geniuses. ArchDir $ The archive files should go in the $ directory Archive: *, *, *, ... These mailing lists will create an archive file, #.arc User Accounts: Evil Genius - self explanatory igor - remailer contact account (mail address that executes program) master - owner of remailer (a person who receives status and such) dead - the 'anonymizer' account undead - another trusted 'igor' remailer Standard Accounts: master:"Evil Genius #1":{other Evil Genius'} igor:master:{list of other users} dead:igor:{nothing here} list_name:igor:{lot of subscribers, a file} Copyright 2001 All rights reserved Permission to use for non-commercial purposes only is granted. -- ____________________________________________________________________ Nature and Nature's laws lay hid in night: God said, "Let Tesla be", and all was light. B.A. Behrend The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
On Wed, 1 Aug 2001, Black Unicorn wrote:
See my (huge) posting on this, but I would suspect that this isn't great. Were I operating one, which I am admittedly not, I'd want there to be no data of evidentiary value ever hitting my memory or media. To some degree that's not possible. In the alternative, actually _disabling_ logging is the best policy, in my view. The evidence never existed in the first place then. It suddenly becomes a challenge to show some kind of conspiracy on your part since the actual spoliation claim is harder to make. Showing conspiracy for anything with respect to either probably starts hard and gets marginally less hard in this order:
Sure the evidence existed, it just wasn't written to another file, you routinely spoliate the primary source data UNLESS you turn logging on. Intentionaly turning off logging certainly shows 'intent' which is all that the cites you've provided require. Now 'conspiracy' would require a second (or more) parties to be involved to be relevent. Watch that rock, there's a hard place on the other side... -- ____________________________________________________________________ Nature and Nature's laws lay hid in night: God said, "Let Tesla be", and all was light. B.A. Behrend The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
participants (4)
-
Anonymous -
Black Unicorn -
Jim Choate -
Jim Choate