There's a conference in FidoNet called PUBLIC_KEYS, devoted to PGP and surrounding issues. Most evreyone is enthusiastic but without security experience. As always, we find that the prevailing "right ways to do things" don't fit. FidoNet's main need is "privacy", not "Security". What would be considered very low "security" in traditional circles would be more than adequate. (And of course the usual ways work just fine with a for "real" security needs.) Follows is an article I ran in FidoNews, the weekly FidoNet newsletter. I hoep it makes sense. The FidoNet environment is a little different than other nets. * Security and authentication using PGP in FidoNet THOUGHTS ON SECURITY AND AUTHENTICATION FOR EMAIL SYSTEMS Tom Jennings (1:125/111) Some ideas on public key security systems. To sum up ahead of time, I assert that the public broadcasting of public keys is more than enough security and authentication for casual, privacy needs in the FidoNet or other email network. All of this article assumes the use of PGP version 2.0, the RSA double-key encryption system implemented as freeware. This is all new to most of us, this security/privacy thing. Both technologically and socially. What privacy we have we take for granted without much thought; letters in envelopes, "who is it?" to knocks on the door, etc. When we try to break down these things into their underlying assumptions, well, it's hard. We shouldn't get upset with ourselves or others if "we don't get it" right away. And we'll find some obvious things aren't, and vice versa. I will assume that if you really, really need utter absolute security, you can achieve that with PGP or whatever. If it's that sensitive, sending it over an electronic medium probably isn't recommended. This article isn't about how to achieve bank-vault security. Within the FidoNet, the most common use we all seem to talk about is PRIVACY, rather than SECURITY. I can only speak for myself, but, my netmail (not echomail) traffic is probably a reasonable example. I read about 100 messages a week, and send out about 50. There's a dozen or so people I talk with regularly, and about 50 per week that I do not know. Most of it is of the "Oh yeah, so and so said this. How's your mother. Did you get that file OK...". Even if an eavesdropper read this stuff, I would barely care. There are some times though when revealed message contents could be... personally compromising. Embarrassing. A real life example: a long time ago, a sysop in a net was having trouble with their net host. Some messages critical of that net host were intercepted by the host, some passed on, and some we each got replies to! Not Good. What *I* want is a way to ensure that sometimes, only the addressee can read a given message. I am willing to pay some penalty for this, but I won't live with a system that restrains me like a stone castle and moat. My needs and risks just aren't that great. With that as a background assumption, let's look at two separate issues that look at first to be the same -- SECURITY and AUTHENTICATION. SECURITY -- given an encrypted message, how likely is it that someone can ascertain what's inside it (assuming you're not the addressor or addressee)? As an operating assumption, I will take it for granted that PGP produces files that are secure in themselves (barring bugs, etc). Like the docs say, a frontal cryptological assault is hard, and in our casual privacy case, probably not what we've got to worry about. There are other ways to figure out what's going on. Imagine you're that net host. You've had trouble with this particular sysop before. You notice he's just sent a flurry of messages to the local RC, then the ZC. Hmmm!! Do you really need to know what's in those messages?! (This is called traffic analysis. In pre-WWII Germany, the Nazis tracked down "Jew sympathizers" with traffic analysis of telephone billing information; Europeans don't get itemized phone bills any longer... like here in the US. So I was told, the information is no longer kept. (Do I really believe that...:-)) Anyways, security is more than cryptographic strength. Turns out, there's a way around this: anonymous remailers. In a private Internet mailing list Eric Hughes came up with a trick to anonymously remail messages; you send mail destined for system X to the remailer instead; it strips off the header info and mails it to system X. Anonymity isn't really needed though in the case above, simple remailing will do. Again, our *general* FidoNet needs are modest. AUTHENTICATION is the sticky one for us. Authentication is determining: is this person really the person they say they are? But I think you'll see it isn't the fatal problem it appears to be at first. Let's get the obvious case out of the way first again: if you need utter and absolute security, you better damn well know the person ahead of time, you should get a key delivered by hand, and you should think about if you really want to conduct business over an electronic link in the first place. Authentication in this case isn't -- or shouldn't be! -- a problem. For our relatively-casual privacy use, authentication is almost moot. Some people I have already exchanged keys with, *I've never met face to face in my life* and may never. In spite of this I feel I know them. I trust or assume that they are who they say they are. This is the environment we need to work in. This, plus the fact that we've got (at the moment) some 16,000 potential keys, means we simply can't do the full-blast security thing. How much "security" can I expect, or need, with someone I've never met? Consider again the utter-security case again. But the bottom line is in fact already taken care of, PGP or not -- how do you know that "the real Tom Jennings" wrote this article? Our underlying social system, so frequently overlooked, takes care of it. You can assume I, and many people who have been in the net, are verifiable. You have a number of ways to determine if I really wrote this article. Simply asking via FidoNet will uncover most fakes. Looking at old nodelists to see what info on my name has changed. Ask people who might know me. And so on. If our public keys are scattered to the wind like plants scatter pollen, it is certainly possible that I could fake "your" public key, and gain access through all the methods discussed in detail in the literature. However, assuming the real person and the fake person(s) are both generating keys (and using them to sign and send messages), the more keyrings were passed around the chances of detecting the incompatible keys becomes almost certain. At that point, even a casual effort would be able to track it down, to at least determine that there *was* a fake. Example: Mary has been using PGP for a few months, and conversing with friends and acquaintances. Her public key is filerequestable, and probably appears on a hundred keyrings. Over the next few months, other people get messages from "Mary" making increasingly odd claims, via encrypted mail. The impostors fake key, in order to be useful at all, would also have to be widely distributed. Curious, someone sends Mary a message encrypted with what appears to be her public key, and a plaintext one telling her that the cyphertext was encrypted with her public key, and that he suggests if she can't decipher it someone may have faked her key. What Mary actually does depends on many things. If she has indeed been creating the crazy messages, well, the problem's elsewhere. If she finds she can't read the message, her recourse depends on what is available to her: if there are public key repositories, she would be advised to contact them and notify them of the alleged faked key(s), and follow whatever process is setup to generate a new key. The very knowledge of key collision would be enough to flag to users that there's a potential problem. There are more practical issues that limit our need for traditional security measures on keys. Even if you stored your private key on disk, it would take physical access of your machine to get it. This is not what I'm worried about in private FidoNet mail. If a FidoNet member tries to break into my house or system to get at my key, I've got other troubles! Practically speaking, it might even be a good idea to have two keys; a small (256 bit) one for casual, email privacy, and a big one (1024 bits) that you give to people by hand on diskette. The small key will mean better performance, more important on bulk casual email, and certainly adequate against eavesdropping. For high-security needs, which most people don't have (I certainly don't), the performance penalty probably won't matter as much. The worst part of security systems is that people will *rely* on them as absolutes. This is the only thing that makes a faked, encrypted message worse than a faked, plaintext message. Again, it's important to remember the goal (as if we could ever possibly agree to a *single* goal...) -- if it's privacy, the ability to stop eavesdroppers, then a broadcast public key system is more than adequate, and public key repositories even better. If you want a maximum-security vault, you take added precautions. No one system will solve all problems. I'm a firm believer in a broadcast public key system for email. PRACTICAL SUGGESTIONS FOR PGP USE IN FIDONET PRIVACY: * Use small (256 bit) keys for routine, low-security use, such as netmail privacy with people you don't know personally (and don't get keys from physically). * Public key encryption is most useful for email, ie. FidoNet netmail, especially when it flows through multiple hosts on its way to its destination. * The current password scheme for echomail links is proven to be adequate to safeguard what is basically a public forum, anyways. Further security doesn't seem to be needed on these links. * When adding keys received via FidoNet to your public keyring, answer "do you want to certify this key yourself" with NO, unless you received the key by hand. It doesn't hurt the usefulness of the key itself; however, if someone later uses your public keyring they won't be lulled into a false security. (Certification of keys can be done at any time.) * Passing keyrings around willy-nilly, though counter to "good security practice" in traditional uses is actually a good thing for us. "Key Repositories" scattered throughout the net (each exchanging keyrings as well as posting lists of "trouble keys") is a better idea. * Reserve large (1024 bit) keys for people who you know, and can ensure security in traditional ways (some pointed out in the PGP documentation). * As seems to be developing, have your public key filerequestable as magicname "PGPKEY" (your own public key only), and your keyring as "KEYRING" (all of your public keys). These should be ASCII-armor files (PGP -kxa) * Origin: World Power Systems / FidoNews / San Francisco CA (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings@f111.n125.z1.FIDONET.ORG