PGP Keys and Public Key-Servers

    PGP Keys and Public Key-Servers

    Keys & Servers

    ……………………………………

    PGP Keys and Public Key-Servers

    On this page…

    Keys? I don’t need no stinkin’ keys!

    There are two types of keys, and each requires a different procedure be followed before the first message exchange between two people.

    Secret key systems, also known as symetric systems, have each user using the same key. This key must be exchanged in some secure method, such as a face-to-face meeting, verifying the identity of the other party. This provides a logistic headache when communicating those geographically distant, or when communicating with several people (each of whom needs their own key). This is a severe limitation in a networked planet; it also effectively prevents spontaneous secure communications between parties. (It also limits secret speech to those who have the funds to arrange such secure key hand-offs.) The secret key must remain secret from others; once the key is compromised then the encrypted traffic is no longer secure. (The greatest threat is not knowing your key has been compromised.)

    A solution to work around this fundamental limitation to secret key systems is the use of a centralized key authority. Examples are the U.S. government’s attempt to be a central Clipper key escrow, or by the use of a key database in the Kerberos security system.

    Public-key systems, also known as asymetric systems, have no such inherent restrictions. Instead of using a single key for both encryption and decryption, public-key encryption uses a public key/private key pair. To communicate with me, you first get my public key from one of the many

    around the planet. You then encrypt the message with your secret key and my public key. When I recieve your message, I get your public key from the key-server, and decrypt it with a combination of your public key and my secret key.

    It is this asymetric public/private key tango that assures me that you’re the only person able encrypt the message (because you’re the only person to know your secret key). You know I’m the only one who can decrypt the message (because I’m the only one to know my secret key). Another layer of security, the use of a “pass phrase”, provides protection should my secret key be somehow acquired by the black hats.

    How can you trust my key?

    This public-key stuff is all well and good, but how can you be sure that what you get from a

    belongs to me? Since we haven’t exchanged keys in a face-to-face manner, at first glance it seems you can’t be sure the public key belongs to a real and legitimate person, or an organization. What we need is some way to “certify” the validity of the key. There are currently two certification methods in use.

    Institutional certification authorities (CA) – as bureaucratic as the name implies – are the digital equivalent of state-issued drivers licenses (in the USA), government-issued ID cards (in Germany), or employee ID cards. Apple Computer is a CA, and will certify your PowerTalk RSA key for free at the MacWorld Expositions. (At least it’s been free so far.) These certification certificates expire after a fixed amount of time, guaranteeing a source of income for commercial CAs.

    The web of trust, a grass-roots alternative to institutional certification authorities, works through what could be called “personal certification”. People who can vouch for you identity (not your likeability, as is often misunderstood) “sign” your key. For example, if you were to pull my PGP public key from a key-server, and examined it, you would see:

    Type bits/keyID

    Date

    User ID

    pub

    1024/E4A76B99 1994/08/01 Michael ‘Mickey’ Sattler

    sig

    93D1B0CD

    Raph Levien

    sig

    C7A966DD

    Philip R. Zimmermann

    sig

    E4A76B99

    Michael ‘Mickey’ Sattler

    My key is signed by three people, including me. The first thing I did after creating my key-pair was to sign my own key. This is a very important security consideration, not to be overlooked when you create your key-pair. Who else but you can sign your own key?

    I asked two people who could certify my identity to sign my key. I chose them because (1) they are well known through the cryptography community and (2) they are each deemed trustworthy. (Philip signed my key while we working together on a project. Please don’t send Philip email asking him to sign your key. He doesn’t know you, so he won’t.)

    Choose people who are well-known in the circles you travel. It does no good to have Raph Levien’s signature on your public key if you’re working with graphic designers who don’t know anything about , and have no idea who Raph is. It’s not uncommon to have a “signing party” whenever people in our far-flung net community get together, typically at a computer show.

    Key-servers

    Key-servers are computers that perform a service analogous to that of the telephone directory. If you want to call me on the telephone, you must first consult a directory to obtain my telephone number. If you want to send me PGP-encrypted email, you must first consult a key-server to obtain my PGP public key.

    Some key-servers are properly networked. A public key submitted to one is quickly propagated through the network to them all. Some key-servers are in a poor state of isolated neglect. They don’t propagate keys submitted to them, and probably don’t update their key directories at any reasonable interval.

    Brian A. LaMacchia of MIT operates what I believe to be the best-run “PGP key-server” around. It allows you to submit your key and obtain the PGP public keys of others.

    Have you found errors nontrivial or marginal, factual, analytical and illogical, arithmetical, temporal, or even typographical? Please let me know; drop me . Thanks!

    |

    |

    |

    |

    |

    |

    |

    |

    This page

    is

    1993-2006 by ,

    via the Creative Commons License. Questions and comments? Send

    to the Geek Times Webmaster. (Domain and web content hosting at .)

    Leave a Reply

    Your email address will not be published.