Warm, fuzzy, misleading feelings
I've been following the dig sig fracas with great interest. While I can see merit in both sides, the pro-sig argument is weakened by their endorsement of sig spoofing. If the object is to heighten awareness of crypto and digital signatures, what possible Good can follow from setting the example that "cypherpunks simulate signatures"? The way I see it, either sign or don't sign, but attaching a bogus signature block to a message for the sole purpose of pacifying a mailing list requirement diminishes the significance of crypto and sullies the image of all who participate. If sigs are required, then valid sigs should be required. Make a new key pair that's used solely for the purpose of signing your list mailings. Any resulting damage to reputations or egos signed by a pilfered low security key would be no more significant than a forged message left unsigned. By the same token, I don't see how this proposal does much to spread the Good Word. Maybe the sole intent is for the participants to share in the warm, fuzzy feelings of "doing their part". Like flying a kite for peace or dumping red paint on an already-dead furry animal carcass, the primary goal of promoting the proper use of crypto seems less important here than the _perception_ of promoting it. Not everything that feels good is good for you. =D.C. Williams <dcwill@ee.unr.edu>
-----BEGIN PGP SIGNED MESSAGE----- In article <199412010119.RAA06900@python>, "Dr. D.C. Williams" <dcwill@python.ee.unr.edu> wrote:
I've been following the dig sig fracas with great interest. While I can see merit in both sides, the pro-sig argument is weakened by their endorsement of sig spoofing. If the object is to heighten
The way I see it, either sign or don't sign, but attaching a bogus signature block to a message for the sole purpose of pacifying a mailing list requirement diminishes the significance of crypto and sullies the image of all who participate.
I'm not entirely sure, but I thought that 90% of the "anti-sig" argument was that it was a pain in the ass because the tools did not exist on some machines to allow relatively seamless signing for some users (in a secure fashion). If thats the case.....isn't it an equal pain in the ass to go to the trouble of forging a sig? :> You would likely have to go through more key strokes and other routines to forge one. Why not just play by the rules and sign a message? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLt02ia+YbMzawbu5AQFzCQP7BTP5dyuQf8nmFIeEGeTzxjaTrWYbB9no ZHQIC2u86TbQX1EAiA8LMCWlk+CHhvMJSMXt7QpK6h+ylpYQxJuEwebQcPPdqYAb szD+AfeFMGEovGpt2LxQXnAT098uyIgSkf0ALGd7iTWDBsVJz74M59m8thqpHs92 W27FsPThttY= =Orub -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Mark Terka writes:
If thats the case.....isn't it an equal pain in the ass to go to the trouble of forging a sig? :> You would likely have to go through more key strokes and other routines to forge one. Why not just play by the rules and sign a message?
I imagine it would be a breeze to attach a forged PGP sig to every message using most mailers etc. The signature block is easy -- simply append it to the contents of the .sig autoappended by many mailers/newsreaders. All that remains is a macro or a bit of cutting & pasting to toss in the --- BEGIN PGP line at the top. Now that Eric has made it abundantly clear he envisions syntactic but not semantic checks of sigs, I am opposed to the proposition. I foresee a situation in which a large portion of the list traffic uses forged or meaningless signing-server-appended dig sigs. When I establish automatic signature validation for incoming mail here Real Soon Now, there will be plenty of noise generated by all the `false' negatives in the data to make a mockery of the authentication process. Encouraging cryptographically valid signatures was the first suggestion I'd seen in this entire debate which seemed to promise tangible benefits; encouraging cryptographically invalid signatures is the first notion which appears to offer tangible detriment. Disclaimer acronym of the day: ECDWHW. Eric Can Do Whatever He Wants. BTW, Tim, why do you seem so surprised by JD's style of discourse ? Just mention Chomsky and be done with the damn thing, it's not going to be productive anyway. - -L. Futplex McCarthy; PGP key by finger or server "Don't say my head was empty, when I had things to hide...." --Men at Work -----BEGIN PGP SIGNATURE----- Version: 2.6.1 iQCVAwUBLt1CSGf7YYibNzjpAQEquAP5Aa0aVKiWW39kxxZEkvYHRFJBEOkZSVE5 ZCjUABEx7hki2+uaGvIDJyGlb73mxMeiT1iM8N1BBzbztSWbRN4wUbLsaRD27gQz NY/g/eOvylZcphFzxLWRNWBnmGSgGgN+miMv0sVxSJkdq41fjSTW9ziH8mOrGRif ZfYlP21LOSc= =W8Wf -----END PGP SIGNATURE-----
From: "L. McCarthy" <lmccarth@ducie.cs.umass.edu> I foresee a situation in which a large portion of the list traffic uses forged or meaningless signing-server-appended dig sigs. When I establish automatic signature validation for incoming mail here Real Soon Now, there will be plenty of noise generated by all the `false' negatives in the data to make a mockery of the authentication process. Recall my comments on transaction failure in a different context last week. What is important there is what happens under failure, not under success. Sig checking requires an analysis of the pragmatics of failure, i.e. what happens. What seems abundantly clear, no matter what actions are taken, is that it will be actions plural rather than action singular. The decision process to decide what happens is much more significant architecturally that what actually does happen. An embedded action, i.e. a hardcoded policy, would be bad, and since sig failure handling is a relatively unexplored area, one can do it right the first time. Assuming such a failure recovery decision process, the actions are simple: ignore, flag, discard, bounce, get key, etc. None are particularly difficult; the decider is what is hard. Now, assuming both decider and actions, you can very simply ignore all sig failure for cypherpunks. Encouraging cryptographically valid signatures was the first suggestion I'd seen in this entire debate which seemed to promise tangible benefits; Syntactic checking also encourages valid signatures, just not as strongly. encouraging cryptographically invalid signatures is the first notion which appears to offer tangible detriment. It's a problem that won't go away that the existence of bogus signatures merely make the problem imminent and proximate. Eric
From: werewolf@io.org (Mark Terka) If thats the case.....isn't it an equal pain in the ass to go to the trouble of forging a sig? :> You would likely have to go through more key strokes and other routines to forge one. Why not just play by the rules and sign a message? This is a perfectly good rephrasing of one of the main rationales behind the proposal, namely, that the architectural issues are more important than the actual crypto use. (Not exclusively important, but more important.) Eric
-----BEGIN PGP SIGNED MESSAGE----- Dr. D.C. Williams writes
By the same token, I don't see how this proposal does much to spread the Good Word. Maybe the sole intent is for the participants to share in the warm, fuzzy feelings of "doing their part". Like flying a kite for peace
Actually it is even worse than that: It is like wearing red ribbons to protest AIDS. A checker that checked signatures for consistent ID would actually promote cryptography. A checker that merely checks if a signature looks like a signature merely makes cryptography look stupid, like a power ranger suit. I would entirely support a real checker, but not a toy checker. -----BEGIN PGP SIGNATURE----- Version: 7.9ui We have the right to defend ourselves and our property, because of the kind of animals that we James A. Donald are. True law derives from this right, not from the arbitrary power of the omnipotent state. jamesd@netcom.com -----END PGP SIGNATURE-----
From: jamesd@netcom.com (James A. Donald) -----BEGIN PGP SIGNED MESSAGE----- A checker that merely checks if a signature looks like a signature merely makes cryptography look stupid, like a power ranger suit. Well, the message you posted doesn't look like a PGP signature. It has similarities, but wouldn't pass the recognizer. As I've said before, there is partial benefit to an incomplete recognizer. I do not want to abandon this benefit merely because others are more difficult to obtain. I don't understand why a recognizer set up at a single location makes all cryptography look stupid. Eric
James A. Donald wrote: (the topic being using ersatz sigs to defeat the sig inspector)
Actually it is even worse than that: It is like wearing red ribbons to protest AIDS.
A checker that checked signatures for consistent ID would actually promote cryptography.
A checker that merely checks if a signature looks like a signature merely makes cryptography look stupid, like a power ranger suit.
I'm back in agreement with James Donald (Chomsky is spinning). More that just making crypto look stupid, a game to be played, this whole "toad will only check that the _form_ of crypto is sort of present" (caveat: this is short-hand for the case presented) defeats the whole purpose of user-to-user verfication. I'm interested in systems which actually allow me to _really verify_ sigs if I have to (not often, I hope, and expect), not get a casual comment from another system/user that it "appears" that a sig is attached. I wasn't kidding earlier today (apologies that I'm reading the later mail first, as I just got home) when I argued that toad messages ought to be signed. That is, all traffic from toad. If sigs are to be compelled (Note to Eric on a point he made earlier: a compelled sig is one which is compulsory if a post is not to be bounced, as per Eric's message about delaying and then eventually bouncing unsigned messages), which I consider unwise, then such sigs should *actually be checked*, with the resulting checked messages then signed by toad/Eric/Hugh/John/whatever. Anything less than this is actually counterproductive, as it fosters a non-Cypherpunkish view of placing trust in others to do what technology allows one to do directly. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. Cypherpunks list: majordomo@toad.com with body message of only: subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tcmay
From: tcmay@netcom.com (Timothy C. May) More that just making crypto look stupid, [... it] defeats the whole purpose of user-to-user verfication. Solutions that are bottom up are fine so long as they're not required to remain on the bottom. If a service (not the one I'm proposing) were to actually verify sigs, then some people might want to trust it and some might not, depending on their desires and abilities. I'm interested in systems which actually allow me to _really verify_ sigs if I have to [...] And so am I. There is less incentive, however, to set up a sig checker when there are few signatures to check. I don't think we need the whole crypto world to come into bloom at once. In fact, I don't that _could_ happen and that expecting that sort of parallel development is a positive hindrance to deployment. I wasn't kidding earlier today (apologies that I'm reading the later mail first, as I just got home) when I argued that toad messages ought to be signed. That is, all traffic from toad. I didn't think you were kidding, nor did I think that the PGP deficiency you pointed out was trivial. There have been major issues about trustability at toad.com and it is inappropriate at the current time to consider trusting signatures it might make. Again, I don't feel that this problem needs to be solved in order to encourage people to use digital signatures. If sigs are to be compelled [or bounced ...], then such sigs should *actually be checked*, with the resulting checked messages then signed by toad/Eric/Hugh/John/whatever. There is some merit to this idea, assuming that signatures are to be used as access control. The current proposal, however, does not include that and hence the argument above is premature. I'd like to examine it later at some point when it is more timely. In the interim, though, I leave with an open question: "What would such a server signature represent?" Anything less than this is actually counterproductive, as it fosters a non-Cypherpunkish view of placing trust in others to do what technology allows one to do directly. Another non-Cypherpunkish view is to prevent the creation of systems which allow you to use an agency relation to let someone else do something for you. For reading cypherpunks mail on a slow machine, or someone else's machine, I'd be glad to use an agent (the legal denotation here) to verify signatures. What is definitely non-Cypherpunkish is to promote systems that require trust relations that would not be entered into freely, like the first PEM certificate mechanism. Eric
From: "Dr. D.C. Williams" <dcwill@python.ee.unr.edu> While I can see merit in both sides, the pro-sig argument is weakened by their endorsement of sig spoofing. If the object is to heighten awareness of crypto and digital signatures, what possible Good can follow from setting the example that "cypherpunks simulate signatures"? To someone who doesn't know what a digital signature is at all, it doesn't matter if it's real or faked. Communication to these people is entirely from the odd-looking form of the appendages. The ability to spoof a signature is an artifact of incomplete notions and implementations about key distribution. Were these problems solved, I would consider actually verifying all signatures. These problems are not solved to my satisfaction, however. The inability to check a signature does not, however, render useless those other functions that still work. I advocate partial progress, and the lack of a benefit is not sufficient argument against things that actually work. The way I see it, either sign or don't sign, but attaching a bogus signature block to a message for the sole purpose of pacifying a mailing list requirement diminishes the significance of crypto and sullies the image of all who participate. If you don't have a public key, it doesn't matter if the signature was real or faked; you still can't verify it. One of the purposes of this proposal is to encourage people to change their software to automatically sign. The harder part of this is to change it to do anything automatically. The signature making part is fairly trivial by comparison. The benefit I want more, of the two, is the automaticity. If, for whatever reason, actual signing can't happen, I am content with the form of a signature. Make a new key pair that's used solely for the purpose of signing your list mailings. That's fine, and I agree with the idea as a solution to the insecurity of keys on a public machine. I do not, however, feel I need to insist that everyone do this. By the same token, I don't see how this proposal does much to spread the Good Word. 1. Crypto-unaware people will see the form and ask what it is. 2. Crypto-aware people will alter their software to do something automatically. 2a. Many, perhaps most, of these people will use real crypto once auto-something already set up. Eric
------------BEGIN DIGITALLY SIGNED MESSAGE------------------
From Eric Hughes:
To someone who doesn't know what a digital signature is at all, it doesn't matter if it's real or faked. Communication to these people is entirely from the odd-looking form of the appendages.
I would prefer to teach fewer of them to speak than teach a larger number of them to grunt.
I advocate partial progress, and the lack of a benefit is not sufficient argument against things that actually work.
I believe that your definition of what works and what doesn't may be very different from mine. Spoofing sigs doesn't qualify as something that "works" in my book. Maybe banks should start paying high quality forged checks because some effort has been expended in their creation.
If you don't have a public key, it doesn't matter if the signature was real or faked; you still can't verify it.
No, but if the message is sufficiently important to you, some genuine productive effort can be expended to acquire the public key and verify the message. I only bother to verify sigs on messages where authenticity matters, and I suspect that most others follow the same guideline. A bogus signature is, of course, unverifiable. Why waste effort requiring something as non-functional as a spoofed signature?
One of the purposes of this proposal is to encourage people to change their software to automatically sign.
Why? Even AOlers can make a bogus sig as a .sig file and attach it to every outgoing message. Does this even come close to teaching people how to use _real_ dig sigs? I don't think so. What's the benefit of teaching and encouraging people to do the wrong thing?
The benefit I want more, of the two, is the automaticity. If, for whatever reason, actual signing can't happen, I am content with the form of a signature.
Then the vast majority of grunters will put a spoof in their .sig files and be "done" with crypto. If you see that as serving some higher purpose, then you and I will never agree on this issue.
That's fine, and I agree with the idea as a solution to the insecurity of keys on a public machine. I do not, however, feel I need to insist that everyone do this.
Rather than insist that people be forced down any specific path, they should be encouraged to use proper forms of digital authentication. I thought that was your original goal, and I'm disappointed that your original objective has been compromised by an "automatic-spoof-is-good -enough" clause.
1. Crypto-unaware people will see the form and ask what it is.
"Aww, that some kind of gibberish I had to include so my post would go through without being delayed. It really doesn't mean or do anything. Last week, I didn't know nothin' about crypto . . ."
2. Crypto-aware people will alter their software to do something automatically.
In vi, type <ESC> :r .sig and suddenly, the following pops up: Beavis@butthead.biteme.edu --------BEGIN BFD SIGNATURE------- GyGYTv%c4u68998*7tvv5c4%$ex3xc$%ec^%^&tb*&b98&YN8(MN})]mn*&b87Tyv5r8 BN8&b987y*&%Rc5$X4523W5-9}]{)([]0NP89YB67&C$Ec4ex$#xw%^v90-*U-m9_0987V ---------END BFD SIGNATURE-------- Automagically! And much easier than actually bothering to learn something really useful.
2a. Many, perhaps most, of these people will use real crypto once auto-something already set up.
Not if they don't need to really get or use it. If your proposal required something more that a shoddy spoof, it _would_ have a lot of merit. But anyone can append a dig sig without even knowing how to spell PGP. That's where your good idea is derailed. I fail to see any good that can flow from compelling people to do something stupid. If you're committed to the Real Thing, herd the cats into the place they really belong instead of letting them decide where to go and later claiming that that was where you wanted them to go all along. =D.C. Williams <dcwill@ee.unr.edu> -------------HERE'S MY DIGITAL SIGNATURE:----------------------- ___ ___ __ , _ __ (| \ ,_ (| \ / () (| | |_/o |\ |\ o _, , /|/ \ / () _| |/ | _| || | | | | |/ |/ | / | /|/|/| / \_ |__/ >- (/\__/ |/o (/\__/o \__/o \/ \/ |/|_/|_/|/\/|_/ | | |_/\_/o | o\__/o --------------PRETTY COOL, HUH? -------------------------------
From: "Dr. D.C. Williams" <dcwill@python.ee.unr.edu> I would prefer to teach fewer of them to speak than teach a larger number of them to grunt. I would rather that the fewer speak and that the rest grunt rather than remain silent. A bogus signature is, of course, unverifiable. Why waste effort requiring something as non-functional as a spoofed signature? For the architectural changes that have to be made to do such a thing automatically. Why? Even AOlers can make a bogus sig as a .sig file and attach it to every outgoing message. But this doesn't create even a bogus signature. There's still a line at the top to add. This misunderstanding about what constitutes valid syntax colors your whole argument. Then the vast majority of grunters will put a spoof in their .sig files and be "done" with crypto. .sig spoofing won't work; it's only the bottom half. That's the whole point, is that some active action must be taken, be it once to set up something automatic or many times with each message. In the first case, the automaticity is obtained, a postive benefit of itself. In the second, a value is recalled to mind each time. I'm disappointed that your original objective has been compromised by an "automatic-spoof-is-good -enough" clause. It's not good enough, but it is partial progress. Merely because one technique doesn't accomplish everything is no reason to abandon it. Eric
From: "Dr. D.C. Williams" <dcwill@python.ee.unr.edu>
I would prefer to teach fewer of them to speak than teach a larger number of them to grunt.
From Eric Hughes:
I would rather that the fewer speak and that the rest grunt rather than remain silent.
It is far better that the silent become speakers rather than grunters. Grunters, and sig spoofers, add nothing to the cause they steadfastly refuse to participate in or join. It would be better for them to remain silent than erode the language of the speakers. Your proposal doesn't reward speaking. It merely allows grunting. Most parents know from first hand experience that very young children learn how to make complete sentences when their parents no longer accept pointing and grunting as acceptable behavior.
Why? Even AOlers can make a bogus sig as a .sig file and attach it to every outgoing message.
But this doesn't create even a bogus signature. There's still a line at the top to add. This misunderstanding about what constitutes valid syntax colors your whole argument.
Excuse me. Let's say that the smarter ones also learn how to add ---------------------BEGIN SILLY EXERCISE------------------------ at the top. Not a Herculean effort for most, and still a lot easier than even retrieving PGP from the MIT site, to say nothing of learning how to use it at the most basic level.
I'm disappointed that your original objective has been compromised by an "automatic-spoof-is-good -enough" clause.
It's not good enough, but it is partial progress. Merely because one technique doesn't accomplish everything is no reason to abandon it.
If it diverts the course of progress away from the desired objective, it deserves to be abandoned. If my goal is increasing my endurance to be able to swim across the lake, I'm not willing to say that making it half way across before developing cramps and drowning is any manner of "partial progress". My whole point is that the cause is noble and worthwhile, but this method of achieving it is flawed, ineffective, and will do more harm than good to the widespread of crypto. If you decide to require digital signatures, it would be far better to require real sigs than bogus sigs. I would urge you to set your sights higher than the goal you've defined so as to allow for the inevitable circumvention that accompanies any new set of requirements. There are plenty of examples of "lowest common denominators" in society today, and I think most people deserve (and prefer) something more than that. =D.C. Williams <dcwill@ee.unr.edu>
participants (6)
-
Dr. D.C. Williams -
eric＠remailer.net -
jamesd＠netcom.com -
L. McCarthy -
tcmay＠netcom.com -
werewolf＠io.org