textfiles/bbs/FIDONET/JENNINGS/STANDARDS/publicke.art.txt

* 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)