Re: remailer spam throttle
Hal Finney <hal@rain.org> writes:
For example, one idea is to have a list of people who are willing to receive anonymous mail without questions. It could be that the remailer is set up to ask before sending mail normally, but to people on such a list it doesn't have to ask, it just sends it, because they have given permission.
Some people have objected to this proposal because the existence of the list might give a hint about which people send mail through the remailers. Even though the list is of people willing to *receive* anonymous mail, it could well be that there is a strong correlation with people who want to send such mail.
Instead of keeping this list in cleartext, one could keep 1-way hashes of the addresses. Thus a remailer (or anyone) can check whether a given address is on the list, but they can't just go through the list and "investigate" the addresses on it. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
Dr.Dimitri Vulis KOTM wrote:
Hal Finney <hal@rain.org> writes:
For example, one idea is to have a list of people who are willing to receive anonymous mail without questions. It could be that the remailer is set up to ask before sending mail normally, but to people on such a list it doesn't have to ask, it just sends it, because they have given permission.
Some people have objected to this proposal because the existence of the list might give a hint about which people send mail through the remailers. Even though the list is of people willing to *receive* anonymous mail, it could well be that there is a strong correlation with people who want to send such mail.
Instead of keeping this list in cleartext, one could keep 1-way hashes of the addresses. Thus a remailer (or anyone) can check whether a given address is on the list, but they can't just go through the list and "investigate" the addresses on it.
Well, they can compile the list of addresses off of USENET postings and such and then compute the hashes of the compiled names and identify those that are on the anon acceptance list. Not that it completely invalidates the idea, but certainly it is a problem. - Igor.
ichudov@algebra.com (Igor Chudov @ home) writes:
Dr.Dimitri Vulis KOTM wrote:
Hal Finney <hal@rain.org> writes:
For example, one idea is to have a list of people who are willing to receive anonymous mail without questions. It could be that the remailer is set up to ask before sending mail normally, but to people on such a list it doesn't have to ask, it just sends it, because they have given permission.
Some people have objected to this proposal because the existence of the list might give a hint about which people send mail through the remailers Even though the list is of people willing to *receive* anonymous mail, it could well be that there is a strong correlation with people who want to send such mail.
Instead of keeping this list in cleartext, one could keep 1-way hashes of the addresses. Thus a remailer (or anyone) can check whether a given address is on the list, but they can't just go through the list and "investigate" the addresses on it.
Well, they can compile the list of addresses off of USENET postings and such and then compute the hashes of the compiled names and identify those that are on the anon acceptance list. Not that it completely invalidates the idea, but certainly it is a problem.
- Igor.
That's a valid point. One can obtain a list of "suspected" addreses, say, from the subscribers to the cp list(s), and run that against the hashed lists. Another feature I really don't like about asking the first-time recipients to agree to accept e-mail while it's on the reamailer is: With the present scheme, if a remailer is "raided", it has precious little interesting stuff on it at any one time. Now consider the scenario: X sends 1000 copies of child porn/seditious libel to 100 people believed not to be using remailers right now. The remailer keeps the 100 e-mails onits hard disk and e-mails each receipient a ping, inviting them to agree to the disclaimer terms and to retrieve their anonymous e-mail. The first recipient to retrieve the e-mail gets upset and contacts the feds. The feds figure, the remailer still has the 99 other e-mails and the information on who's supposed to receive them in its queue; why not seize it and take a look. I just came up with another idea which definitely has some holes in it, but perhaps someone wants to improve on it. There's a big distributed database of pgp keys on the several keyservers. Add a bit to the database specifying whether the key owner wants to receive anonymous e-mail. By default set it to true for the existing addresses. When the final remailer in the chain wants to send someone an anonymous message, it attempts to retrieve a key from the keyservers. If it fails to find a key, it junks the mail (you don't want to keep it around, it's baiting the LEAs!) and instead sends a notification to the recipient that some anon e-mail was addressed to it, but it was junked; and if they want to receive anon e-mail, they need to give a pgp key to one of the key servers this remailer uses. If it finds a key, it looks at the anon mail bit; if it's on, it encrypts the e-mail with the recipient's key and sends it; otherwise it junks it. Obviously, the key servers would need to be modified to allow users to specify whether they want anon e-mail when then store their keys, and to change this setting any time. Right now, there's a very large number of addresses in the key servers. Instantly making them into a list of addresses that accept anon mail will make it hard (hopefully infeasible) for the LEAs to investigate everyone willing to accept anon e-mail as a suspect in sending it. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
Dimitri Vulis <dlv@bwalk.dm.com> writes:
Igor Chudov <ichudov@algebra.com> writes:
[uses list of hashes of email addreses to reduce value of the database to the attacker]
Well, they can compile the list of addresses off of USENET postings and such and then compute the hashes of the compiled names and identify those that are on the anon acceptance list. Not that it completely invalidates the idea, but certainly it is a problem.
Another feature I really don't like about asking the first-time recipients to agree to accept e-mail while it's on the reamailer is:
With the present scheme, if a remailer is "raided", it has precious little interesting stuff on it at any one time. Now consider the scenario:
X sends 1000 copies of child porn/seditious libel to 100 people believed not to be using remailers right now. The remailer keeps the 100 e-mails onits hard disk and e-mails each receipient a ping, inviting them to agree to the disclaimer terms and to retrieve their anonymous e-mail. The first recipient to retrieve the e-mail gets upset and contacts the feds. The feds figure, the remailer still has the 99 other e-mails and the information on who's supposed to receive them in its queue; why not seize it and take a look.
Here's a partial solution to that: in the ping email informing the recipient there is mail waiting, you include a key, encrypt the message body that you are retaining data with the key and then discard the key. Give a deadline: "your message will be deleted in 5 days". They re-supply the key when they request the message. You immediately decrypt and send it back to them, discarding all knowledge of them (email, encrypted message, encryption key). One snag is that you still have addresses for recipients on your machine so they can go harass people and ask them for the keys to the as yet uncollected messages. Refinement to solution (I like this one), get rid of the intended recipients address immediately after sending the ping, just keep the encrypted body of the message. Include in the ping something which reliably selects a message (say first encrypted line, SHA1 hash of encrypted message, whatever, to save you having to try to decrypt all of your messages).
[keyserver with I-accept-anon-email bit consulted by remailer, no key in remailer => instant trash of message and ping message explaining how to accept anon email]
This sounds a lot like the distributed block and accept list idea which has been discussed a bit. I like your treatment of the remailed material as a `hot potato', instantly pass it on or burn it.
Right now, there's a very large number of addresses in the key servers. Instantly making them into a list of addresses that accept anon mail will make it hard (hopefully infeasible) for the LEAs to investigate everyone willing to accept anon e-mail as a suspect in sending it.
The per remailer block list system kind of does this at the moment, only the list of people initially marked down as willing to accept anon email is the world. Everyone can recieve email, but people get blocked when they complain. Incidentally, it has occurred to me for a while now that the reverse problem also exists: if I suspect you (Dimitri) use remailers, I can forge a message from you to all the remailer operators requesting that I (ie you) be blocked. I can include some exceedingly dire legal threats to the remailer operator, and dig up some vile messages from some dark corner of usenet which I falsely claim came through that operators remailer. As the remailer operator doesn't keep logs he won't be able to recognize the falsehood of the accusation. To solve this problem you need to do a ping message, "please reply with this nonce to be blocked". 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`
Adam Back <aba@dcs.ex.ac.uk> writes:
X sends 1000 copies of child porn/seditious libel to 100 people believed not to be using remailers right now. The remailer keeps the 100 e-mails onits hard disk and e-mails each receipient a ping, inviting them to agree to the disclaimer terms and to retrieve their anonymous e-mail. The first recipient to retrieve the e-mail gets upset and contacts the feds. The feds figure, the remailer still has the 99 other e-mails and the information on who's supposed to receive them in its queue; why not seize it and take a look.
Here's a partial solution to that: in the ping email informing the recipient there is mail waiting, you include a key, encrypt the message body that you are retaining data with the key and then discard the key. Give a deadline: "your message will be deleted in 5 days". They re-supply the key when they request the message. You immediately decrypt and send it back to them, discarding all knowledge of them (email, encrypted message, encryption 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.
One snag is that you still have addresses for recipients on your machine so they can go harass people and ask them for the keys to the as yet uncollected messages.
Refinement to solution (I like this one), get rid of the intended recipients address immediately after sending the ping, just keep the encrypted body of the message. Include in the ping something which reliably selects a message (say first encrypted line, SHA1 hash of encrypted message, whatever, to save you having to try to decrypt all of your messages).
That's a good refinement, but it's still not enough, IMO. 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. That just may be close to contempt of court. Say, you might be asked to explain how you generate the "random" keys so they can be recreated. IMO, the 'net has changed from what it used to be a few years ago. One can no longer send e-mail to an unknown recipient and hope that they're willing to accept anonymous e-mail. I'm not 100% sure what needs to be done, but I firmly believe that in today's climate unless the remailer knows that the recipient took some positive action to indicate that s/he has a clue (such as, added a key to a keyserver), their anon mail should be immediately discarded and they should instead get a note: Someone tried to send you anonymous e-mail; because we don't know whether you want to receive anon e-mail, it's been discarded and can't be recovered; anon e-mail can be bad; disclaimer dislciamer disclaimer; and here's what you need to do to receive future e-mail if you want it.
[keyserver with I-accept-anon-email bit consulted by remailer, no key in remailer => instant trash of message and ping message explaining how to accept anon email]
This sounds a lot like the distributed block and accept list idea which has been discussed a bit.
Yes - nothing really new.
I like your treatment of the remailed material as a `hot potato', instantly pass it on or burn it.
Yes - 5 days worth of anon mail, even if it's encrypted and the recipient is stripped, is an attractive target for LEA's looking for child porn and the like.
Right now, there's a very large number of addresses in the key servers. Instantly making them into a list of addresses that accept anon mail will make it hard (hopefully infeasible) for the LEAs to investigate everyone willing to accept anon e-mail as a suspect in sending it.
The per remailer block list system kind of does this at the moment, only the list of people initially marked down as willing to accept anon email is the world.
Everyone can recieve email, but people get blocked when they complain.
Unfortunately this model is based on assumptions that are no longer true. I've been on the 'net since the early 80s. I used to prozelityze(sp?) everyone I knew that the 'net is a great tool and that we all should use it. Well, now the 'net is full of assholes and you can no longer assume that just because someone has access to the 'net, they have a clue. However I think it's a safe assumption that someone who put their key in a key server has enough of a clue to be able to handle an anon e-mail; and if they don't, they should be able to turn it off easily.
Incidentally, it has occurred to me for a while now that the reverse problem also exists: if I suspect you (Dimitri) use remailers, I can forge a message from you to all the remailer operators requesting that I (ie you) be blocked. I can include some exceedingly dire legal threats to the remailer operator, and dig up some vile messages from some dark corner of usenet which I falsely claim came through that operators remailer. As the remailer operator doesn't keep logs he won't be able to recognize the falsehood of the accusation.
To solve this problem you need to do a ping message, "please reply with this nonce to be blocked".
Yes, that's a possibility. E-mail from has has been forged in the past, as Igor can attest. :-) Again, the 'net has changed. As some folks are aware, I run 3 mailing lists at another site. 2 are near-dead, but one has been up since '89 and is pretty active. Recently I had to institute the policy of confirming subscriptions because of the several forged subscription requests. Such things were unthinkable even 4 or 5 years ago. A key server presumably has some mechanisms for checking that someone who wants to store or update a key for a@b appears to be a@b. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
At 06:46 PM 3/28/97 EST, Dimitri wrote:
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.
Typical remailers carry maybe 100-500 messages/day; typical messages run 1-20KB unless they're pictures or warez. (Yes, I'm making these numbers up....) That's about 1-10MB/day of traffic. If you keep it 7 days, that's up to 70 MB storage, which you'd probably keep in /tmp to avoid backups and maybe avoid disk quotas. If you're running it on your own desktop machine, that's small; it's a bit large for a laptop, and whether it's reasonable for an ISP shell account depends a lot on your ISP's policies and disk quotas (and /tmp clearing policies.)
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. That just may be close to contempt of court.
But you don't have to explain it to the LEA - you may have to explain it to a court, but you get to bring along a lawyer. It's not contempt if you're telling the truth (that you can't decrypt it.) On the other hand, if you're using a two-part key (one sent to the recipient, one kept in transient memory on your machine plus in your head), you _do_ get to explain to the judge why you're refusing to testify, and why the ECPA protects the privacy of all the messages that may be revealed if you release your half of the key, and why you need sworn testimony from the LEAs about exactly which messages they've eavesdropped besides the ones addressed to their target, and about why giving them the key would violate the privacy of the recipients of those other messages so they can't have it, but you also refuse to decrypt the ones for the victim yourself, at least without a direct court order (as opposed to a mere warrant) - _then_ you'll have the opportunity to get close to contempt of court :-)
Say, you might be asked to explain how you generate the "random" keys so they can be recreated.
IMO, the 'net has changed from what it used to be a few years ago. One can no longer send e-mail to an unknown recipient and hope that they're willing to accept anonymous e-mail. I'd agree, but from the first anonymous remailers open to the public
If the "random" key includes a part you know as well as a part the user knows, and the user's part not only includes a hash of the message (so you need to know the contents of the message to recreate the session key) but also the usual things like the system clock to the microsecond and the contents of the rand pool, and maybe a few hits from /dev/random - then it's perfectly fine to tell them. there were people who didn't like receiving anonymous mail :-)
unless the remailer knows that the recipient took some positive action to indicate that s/he has a clue (such as, added a key to a keyserver), their anon mail should be immediately discarded and they should instead get a note:
That's an interesting approach - a bit extreme, but the main cypherpunks applications for anonymous remailers are things like whistleblowing (which can be posted to the net or emailed to people like Foo Inspectors who _ought_ to be willing to accept anonymous mail) and potential co-conspirators (who _ought_ to be willing to accept it if they're interested in co-conspiring), and of course yourself under various aliases.
Right now, there's a very large number of addresses in the key servers. Instantly making them into a list of addresses that accept anon mail will make it hard (hopefully infeasible) for the LEAs to investigate everyone willing to accept anon e-mail as a suspect in sending it.
A nice touch.
To solve this problem you need to do a ping message, "please reply with this nonce to be blocked". Yep.
# Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If this is a mailing list, please Cc: me on replies. Thanks.)
Bill Stewart <stewarts@ix.netcom.com> writes:
At 06:46 PM 3/28/97 EST, Dimitri wrote:
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.
Typical remailers carry maybe 100-500 messages/day; typical messages run 1-20KB unless they're pictures or warez. (Yes, I'm making these numbers up....)
Let them send pictures and warez. A remailer operator shoudn't care. :-)
IMO, the 'net has changed from what it used to be a few years ago. One can no longer send e-mail to an unknown recipient and hope that they're willing to accept anonymous e-mail. I'd agree, but from the first anonymous remailers open to the public there were people who didn't like receiving anonymous mail :-)
Well... Let me quote the complaint that Jim Ray (himself a one-time remailer operator) sent to postmaster@dm.com because he didn't like the anonymous messages that he thought might be coming from me: ]Received: from miafl2-16.gate.net (miafl2-16.gate.net [199.227.2.143]) by osceola.gate.net (8.7.6/8.6.12) with SMTP id HAA187758; Wed, 16 Oct 1996 07:13:05 -0400 ]Date: Wed, 16 Oct 1996 07:13:05 -0400 ]Message-Id: <199610161113.HAA187758@osceola.gate.net> ]From: Jim Ray <liberty@gate.net> ]To: root@bwalk.dm.com, postmaster@bwalk.dm.com ]X-Priority: Normal ]Subject: Dr.Dimitri Vulis KOTM ]X-Mailer: Pronto Secure [Ver 1.10] ]X-Prontosecureinfo: T=signed, P=x-pgp ] ]-----BEGIN PGP SIGNED MESSAGE----- ] ]Mime-Version: 1.0 ]Content-Type: text/plain ]Content-Transfer-Encoding: 7bit ] ]To: root@bwalk.dm.com, postmaster@bwalk.dm.com ]Date: Wed Oct 16 07:10:45 1996 ]Can you folks somehow get Dr.Dimitri Vulis KOTM <dlv@bwalk.dm.com> to quit ]sending anonymous messages to cypherpunks? I have killfiled him, but he ]sends things with subject headers like "RSA" through the anonymous remailers ]and it is impossible to killfile them and still get interesting anonymous ]messages. ] ]He is evidently angry at another subscriber, Tim May, for showing the list ]how much of a fool he was regarding economics in the past, but now he shows ]how much of a fool he is. Below is an example, the subject was RSA, and it ]could only have come from him, I assure you. [BTW, this is not a threat of ]legal action on my part against you, it's just that you are lowering your ]reputations by letting him continue spewing garbage, and now that even ]killfiling him hasn't worked, I am trying to convince you to talk to him and ]encourage him to please take his lithium regularly.] ]JMR ] ]- -----Begin Included Message ----- ] ]Date: Tue, 15 Oct 1996 15:35:04 -0400 (EDT) ] From: amnesia@chardos.connix.com (Anonymous) ]To: cypherpunks@toad.com ]Cc: ] ]Timmy C. Mayflower was born when his mother was on the ]toilet. ] ] ] ]- ---- End of forwarded message ---- ]One of the "legitimate concerns of law enforcement" seems to be ]that I was born innocent until proven guilty and not the other ]way around. -- me ] ]Defeat the Duopoly! Vote Harry & Jo http://www.HarryBrowne96.org/ ]___________________________________________________________________ ]PGP id.E9BD6D35 51 5D A2 C3 92 2C 56 BE 53 2D 9C A1 B3 50 C9 C8 ]I will generate a new (and bigger) PGP key-pair on election night. ]<mailto:jmr@shopmiami.com> http://www.shopmiami.com/prs/jimray ]___________________________________________________________________ ] ]-----BEGIN PGP SIGNATURE----- ]Version: 2.6.2 ] ]iQCVAwUBMmTCum1lp8bpvW01AQHAugP/e/GTay0y778Ziy3JbWCGBb+tRxM8Q1Zi ]Z3aIP97hNYYoD7QKi9yP1gS3ZRbg/9ZXJonWTi+zmZ7yUjmWndczmXJ2IAC+Rgpx ]7MQmrhjU4htmiMCuawNmVLZRNZMl/+kNnX15taA8GdXTcuPXUsGN0y39oMbbqT5g ]do3B4yicgrY= ]=iix/ ]-----END PGP SIGNATURE----- Say, didn't this Mmmmm... Black Unicorn shmuck threaten to sue me for saying someone's on lithium?? :-)
unless the remailer knows that the recipient took some positive action to indicate that s/he has a clue (such as, added a key to a keyserver), their anon mail should be immediately discarded and they should instead get a note:
That's an interesting approach - a bit extreme, but the main cypherpunks applications for anonymous remailers are things like whistleblowing (which can be posted to the net or emailed to people like Foo Inspectors who _ought_ to be willing to accept anonymous mail) and potential co-conspirators (who _ought_ to be willing to accept it if they're interested in co-conspiring), and of course yourself under various aliases.
If the maintenance of destination blocking/unblocking is divorced from the remailer operators, then the whistleblower might be able to find out whether the recipient accepts anon e-mail. Under the scheme I sort of proposed, if I wanted to e-mail X, I might look up via the key servers whether X accepts anon e-mail. If he doesn't, I ping him, knowing that my ping will be discarded and instead he'll get a form letter telling him how to enable receipt. I can check (say) the key servers a few days later and see if he's ready to recieve anon e-mail; then I send the real message. Another advantage: there's no need to put the remailer's real address in the form line. Right now most operators say something like "e-mail foo@bar and/or remailer-operators to be dest-blocked". Under the scheme I'm not quite proposing yet, you can put any junk in the from: (it's irrelevant!) and put the instructions for dest-blocking via a 3rd party in a comment header. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
On Fri, 28 Mar 1997, Dr.Dimitri Vulis KOTM wrote: -> I just came up with another idea which definitely has some holes in it, -> but perhaps someone wants to improve on it. -> -> There's a big distributed database of pgp keys on the several keyservers. -> Add a bit to the database specifying whether the key owner wants to receive -> anonymous e-mail. By default set it to true for the existing addresses. -> -> When the final remailer in the chain wants to send someone an anonymous -> message, it attempts to retrieve a key from the keyservers. -> -> If it fails to find a key, it junks the mail (you don't want to keep it -> around, it's baiting the LEAs!) and instead sends a notification to the -> recipient that some anon e-mail was addressed to it, but it was junked; -> and if they want to receive anon e-mail, they need to give a pgp key -> to one of the key servers this remailer uses. -> -> If it finds a key, it looks at the anon mail bit; if it's on, it encrypts -> the e-mail with the recipient's key and sends it; otherwise it junks it. -> -> Obviously, the key servers would need to be modified to allow users to -> specify whether they want anon e-mail when then store their keys, and -> to change this setting any time. -> -> Right now, there's a very large number of addresses in the key servers. -> Instantly making them into a list of addresses that accept anon mail -> will make it hard (hopefully infeasible) for the LEAs to investigate -> everyone willing to accept anon e-mail as a suspect in sending it. Unfortunately, key servers can not be trusted. I'm sure you're aware that anyone can submit a key, and thus forgeries abound. If the above model is adopted, key servers will be the first target of the prospective spammer. ............................................................................ . Sergey Goldgaber <sergey@el.net> System Administrator el Net . ............................................................................ . To him who does not know the world is on fire, I have nothing to say . . - Bertholt Brecht . ............................................................................
Sergey Goldgaber <sergey@el.net> writes:
-> Right now, there's a very large number of addresses in the key servers. -> Instantly making them into a list of addresses that accept anon mail -> will make it hard (hopefully infeasible) for the LEAs to investigate -> everyone willing to accept anon e-mail as a suspect in sending it.
Unfortunately, key servers can not be trusted. I'm sure you're aware that anyone can submit a key, and thus forgeries abound.
If the above model is adopted, key servers will be the first target of the prospective spammer.
Why Sergey, you mean to tell me that there are key servers out there that accept a key from a purported address and don't send back a cookie to that address to see if it's not fake? :-) That's just terrible. Definitely no key coming from such a server should be trusted. :-) :-) Today is March 29, 1997 - almost April 1st. The Internet ain't what is used to was 15 or 10 or even 2 years ago. If you get an e-mail that purports to be from X, and it requests that you add X's public key to your key server, or (un)subscribe X to a mailing list, or block X from receiving anonymous e-mail - it may be a forgery. Never act on such requests without trying to authenticate them with a cookie. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps
On Sat, 29 Mar 1997, Dr.Dimitri Vulis KOTM wrote: -> Sergey Goldgaber <sergey@el.net> writes: -> > -> > Unfortunately, key servers can not be trusted. I'm sure you're aware that -> > anyone can submit a key, and thus forgeries abound. -> > -> > If the above model is adopted, key servers will be the first target of -> > the prospective spammer. -> -> Why Sergey, you mean to tell me that there are key servers out there that -> accept a key from a purported address and don't send back a cookie to that -> address to see if it's not fake? :-) That's just terrible. Definitely no -> key coming from such a server should be trusted. :-) :-) -> -> Today is March 29, 1997 - almost April 1st. The Internet ain't what is -> used to was 15 or 10 or even 2 years ago. If you get an e-mail that -> purports to be from X, and it requests that you add X's public key -> to your key server, or (un)subscribe X to a mailing list, or -> block X from receiving anonymous e-mail - it may be a forgery. -> Never act on such requests without trying to authenticate them -> with a cookie. DNS maps can easily be forged. Key servers run on machines with questionable physical and operating system security. Finally, key server ops themselves can mess with keys. This is why people who use keys off of keyservers are encouraged to verify the key via it's key fingerprint, or at via the web of trust. However, this can not be done via automation on a large scale for the purpose of address blocking, unless via a certification authority. The bottom line is that keyservers can not be trusted, despite any primitive security measures they supposedly have in place. ............................................................................ . Sergey Goldgaber <sergey@el.net> System Administrator el Net . ............................................................................ . To him who does not know the world is on fire, I have nothing to say . . - Bertholt Brecht . ............................................................................
participants (5)
-
Adam Back -
Bill Stewart -
dlv＠bwalk.dm.com -
ichudov＠algebra.com -
Sergey Goldgaber