Re: remailer spam throttle
Adam Back
Dimitri Vulis
writes: Adam Back
writes: [encrypt the message and send the recipient the key, discard the key, when they request the message they supply the key]
That's a good idea, but it'll take up a lot of disk space at the machine running the remailer. Right now, remailers that provide latency don't keep an e-mail for more than about 12 hours. Once you start keeping them around for a few days (a reasonable grace period for a first-time user), it's a lot more disk space.
"Disk is cheap." I just bought a 3.8Gb quantum for $300. That's 4 times cheaper Gb/$ ratio than last disk I bought a year ago.
I paid over $700 for a 2GB disk about 18 mos ago. Yes, disk prices are falling through floor - giving the lie to the scum that tries to control Usenet "spam" - but is it really worth it to have to maintain a huge spool space to support a remailer? If you really think you can afford a few GB of extra disk storage, start up a Usenet site of virtue.
1Gb encrypted message pool? No problem.
Don't have the resources for the 1Gb disk? Your ISP will be charging you many times that for your leased line.
If it's an issue charge postage to cover your storage and transmission costs.
However, I suppose if you're using an ISP shell account, and have no leased line, you may have more space restrictions.
It should be possible to run a remailer on an average $19.95/mo shell account. Most of them come with a disk quota of a couple of megabytes. I do think that keeping a lot of mail in the queue (more than is kept by the remailers that use latency now) would make such accounts unsuitable for remailers.
A better idea, (for both ISP shell account and leased line version) would to send the recipient the encrypted data, you keep the key :-)
(View it as a secret split where the parts happen to be different size, you keep the small one).
They send you the data and you decrypt, send it back and discard the key. You could store 16 million keys on your 1Gb remailer spool partition. That 16 million keys would represent 16 Gb of delivered encrypted email.
You could still cope with a fair number of messages in 1Mb remailer key spool in your home file space on an ISP based shell account.
I think this solves remailer resource objections.
yes, this sort of solves the storage problem. Thinking how this might work... Alice's remailer gets an e-mail for Bob. Alice's remailer generates 2 pseudo-random numbers, K and L, and uses K to encrypt the message with a symmetric cryptoscheme. Alice's remailer sends the encrypted message and L to Bob with the following note: if you want to receive the key to decrypt this message, send back L and acknowledge the disclaimer. Alice's remailer retains the triple (K,L,Bob). Because it's small, it can be kept for a long time. If Bob sends back L, the remailer sends Bob K so he can read his message. I see a few problems with this. I'm sure it can be improved. 1. What if Bob is another remailer, unknown to Alice? 2. What if Bob doesn't have the program to decode his message? (It's fair to assume that everyone can fine PGP. It's not fair to assume that everyone can find e.g. triple DES.) 3. What if the LEA's decide that the collection of triples on Alice's computer is worth looking at, for instance, for the list of addresses. (OK, they could be encrypted probably.) 4. What if the LEA's decide to find out how K, L are generated?
You still have the problem of saturation of your network bandwidth. You can probably encrypt (it's symmetric key, say IDEA) fast enough for encryption overhead to be less of a problem than the saturation of the bandwidth of your leased line.
I think IDEA or triple DES would be fast enough for this.
Your other problem is user acceptance -- your average user may still object to receiving Mb's of junk which while the contents don't offend him (he can't read it), the sheer volume may annoy him.
Given how some people react very negatively to what they consider "unsolicited e-mail", I think it might be a bad idea to send them large encrypted messages w/o confirming that they want them. But it's also a bad idea to keep an unknown's e-mail on the remailer. The only way out, IMO, is to *discard* an unknown's e-mail and to tell him what positive action he can take so future e-mails don't get discarded. And by the way: a remailer should probably keep a list of people who have been told about the need for a positive action, so they won't get duplicate notices more than every week or so. If X sends Y 10 e-mails and the remailer sends Y 10 identical notifications with the instructions how to enable receipt, Y might get justifiable upset. When Alice's remailer gets an e-mail for Bob, it should do something like: try to fetch Bob's public key from a well-run key server / \ success failure | | encrypt the e-mail discard the with bob's key and e-mail! pass it to Bob | was the form letter sent to Bob in the last 7 days? \ / no yes \ / exit send bob the form letter Wow, isn't that a perry flow chart. :-) ...
Suppose a LEA wants to search the computer hosting the remailer. They come across a bunch of encrypted files. The operator has to convince the LEA that they don't have the means to decrypt the e-mails or even to figure out who they're from.
Well you can't can you?
It may be hard to prove a negative to a LEO who doesn't know what the hell you're talking about. You have a file in your spool that was encrypted with a key that your program generated, but now you no longer have the key? Well, tell us how the key was generated. ...
I agree with what you're saying that technological aptitude can provide some metric of cluefullness. And that cluefullness usually correlates with good net citizenly behaviour (eg understanding what a remailer is, and not legally threatening, or setting the Feds on to the human owner of a bot.
However there exist quite a few counter examples: cluefull people who do not use PGP, or consider it to be too much hassle (quite a lot of them hang out on cypherpunks, and will actually object if you send them encrypted email, even though spending most of their time on cpunks arguing about the usefulness and essentiality of these tools for privacy).
Well - if generating and publishing a PGP key were a requirement to be able to receive anonymous e-mail, I'm sure they'd do it. Some people (like Dale) legitimately question certain uses of PGP, but I think in this case it's worth encouraging its use.
Also some journalists are pretty clueful (or useful to be able to send information too, shall we say, journalists as a group having a bad rep), and not many can handle PGP.
Hmm - I'm sure John Markoff and even Declan can handle PGP. If, for example, Jon Schwartz can't handle PGP (and I don't know whether he can :-), then he doesn't deserve any anonymous tips. Free market in action. Later - thanks a lot for the extensive comments. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
Dimitri Vulis
Adam Back
writes: [remailer encrypts data, sends recipient encrypted data, and keeps the key the recipient requests decryption if he wishes]
I think this solves remailer resource objections.
yes, this sort of solves the storage problem.
Thinking how this might work...
Alice's remailer gets an e-mail for Bob.
Alice's remailer generates 2 pseudo-random numbers, K and L, and uses K to encrypt the message with a symmetric cryptoscheme.
Alice's remailer sends the encrypted message and L to Bob with the following note: if you want to receive the key to decrypt this message, send back L and acknowledge the disclaimer.
Alice's remailer retains the triple (K,L,Bob). Because it's small, it can be kept for a long time.
I think you don't need to keep Bob .. just lookup K with L. Less email addresses is a good thing. The counter argument I suppose is that the Feds, or anyone else who reads Bobs email can then ask for the key. But if they can read his email, they can already read it once he requests the key. It would allow an eavesdropper to do a DoS attack against Bob, request all his emails before he can.
If Bob sends back L, the remailer sends Bob K so he can read his message.
I see a few problems with this. I'm sure it can be improved.
1. What if Bob is another remailer, unknown to Alice?
Why is this a problem? You have accept lists for remailers between themselves. A private remailer (one not advertising itself on these lists) just mimics Alice in retreiving the email ... waits a while then requests the key.
2. What if Bob doesn't have the program to decode his message? (It's fair to assume that everyone can fine PGP. It's not fair to assume that everyone can find e.g. triple DES.)
You can provide a web interface to do it for him. Or, you can offer the option that if he includes the encrypted message in his request you will decrypt it for him, by return of email.
3. What if the LEA's decide that the collection of triples on Alice's computer is worth looking at, for instance, for the list of addresses. (OK, they could be encrypted probably.)
Don't keep the addresses as above -- treat the nonce L as the identitiy.
4. What if the LEA's decide to find out how K, L are generated?
Random pool like PGP, it's one way and the pool has more bits than the key material the Feds have anyway. /dev/urandom is nice.
When Alice's remailer gets an e-mail for Bob, it should do something like:
try to fetch Bob's public key from a well-run key server / \ success failure | | encrypt the e-mail discard the with bob's key and e-mail! pass it to Bob | was the form letter sent to Bob in the last 7 days? \ / no yes \ / exit send bob the form letter
Wow, isn't that a perry flow chart. :-)
Yes. A good solution also. Perhaps we can write a nice remailer which has a web forms interface for configuration, lots of radio buttons etc to allow the proud new remailer in a box owner to configure his remailer, and pretty stats graphs. [o] discard / keep if keep how long for [...] etc. Then let the remailer operator play with settings and see which works out best for him.
It may be hard to prove a negative to a LEO who doesn't know what the hell you're talking about. You have a file in your spool that was encrypted with a key that your program generated, but now you no longer have the key? Well, tell us how the key was generated.
I think you're arguing for your discard all policy :-)
btw if you're interested to fix the keyserver so that it requires an
ack to a ping with a nonce, someone at MIT has a fast PGP key database
/ web key server which isn't using PGPs linear lookup. You can find a
link to it from Brian LaMachia's keyserver page.
Another snazzy thing to do to the keyserver would be to have it obtain
a timestamp signature on your key (from a third party time stamping
service, of which there are several) and include that too.
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
(I'm behing in responding to e-mail)
4. What if the LEA's decide to find out how K, L are generated?
Random pool like PGP, it's one way and the pool has more bits than the key material the Feds have anyway. /dev/urandom is nice.
Not sure how LEA's work in the U.K., but here in the U.S. they just might be interested in figruing out the state of the machine when /dev/whatever was read. Besides, someone might just use the lc rand in the C library and init it with srand(time(NULL)*pid()) - making it worth the while to figure out what the pid might be like. (Wasn't that the basis of one of thw early attacks on Netscape?) I say, eschew any protocol that involves generating a pesudo-radom key, and then discarding it. What if the LEAs want to examine your hard disk to see how thoroughly it's been discarded?
It may be hard to prove a negative to a LEO who doesn't know what the hell you're talking about. You have a file in your spool that was encrypted with a key that your program generated, but now you no longer have the key? Well, tell us how the key was generated.
I think you're arguing for your discard all policy :-)
Yes. You don't have your own domain, so you can't possibly imagine the kind of idiots that have been getting on the 'net in the last few years. By the way: if Alice sends Carol an e-mail via Bob's remailer, and Bob's remailer uses a third party database to see if Carol accepts e-mail (such as a key server) then Alice can determine whether Carol accepts anonymous e-mail. Say, Carol is a journalist and Alice is a whistleblower. Alice first sends a ping, which causes Bob's remailer to send Carol a form letter explaining how to unblock herself. Alice checks the database until (hopefully) she sees that Carol accepts e-mail, then she sends her whatever.
btw if you're interested to fix the keyserver so that it requires an ack to a ping with a nonce, someone at MIT has a fast PGP key database / web key server which isn't using PGPs linear lookup. You can find a link to it from Brian LaMachia's keyserver page.
Another snazzy thing to do to the keyserver would be to have it obtain a timestamp signature on your key (from a third party time stamping service, of which there are several) and include that too.
Sigh - I wish. I'm behind on a bunch of projects, including the great spambot. Thanks for the info anyway. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
participants (2)
-
Adam Back
-
dlv@bwalk.dm.com