pst@anise.acc.com (Paul Traina) (08/10/89)
Steve Hayman at iuvax.cs.indiana.edu brought up a valid point in a quick note discussing cancel messages. He said it's a shame that it is so easy to cancel messages. He's right, In about 15 minutes I wrote an awk/shell script that would cancel any message that was piped to it. It took about 1 minute of looking at a legitimate cancel message and another minute to figure out that things were based on the Sender field instead of the From field. So, with this in mind, I am begining to think that it wouldn't be a bad idea if every message that gets created has an additional field which is based upon some public key cryptography techniques. Here is something that I'm thinking up as I write it, so don't take it as my endorsement of "a good idea". Create a new version of postnews/Pnews/etc that looks for a file in the user's home directory ~/.postcrypt. If there, it takes that as 1/2 of an encryption key. If it's not there, it asks the user to enter a plaintext phrase which then gets reduced to a key and stored in ~/.postcrypt. When the user posts a message, an encrypted Authorize-Key: field is added which is based upon the .postcrypt key and the message id of the actual msg. If the user desires to cancel the message, we just go back to the .postcrypt key, mung things together, and the cancel message gets sent out with a "Control-Authorized:" field which contains the proper key to allow canceling of the message. By doing it this way, we add no more processing time on "relay" systems, and only a slightly additional amount of overhead on the initial post and cancelling of a message. For backwards compatibility, if a message doesn't have an Authorize-Key: field, then the old rules (i.e. no real rules) apply. Comments? Is this a good idea that can be expanded to deal with rmgroups et al too? Or is there no real need to bother with it? -- The Constitution isn't all that great, but it sure beats the hell out of what we're using now.