[ale] How Do I Do This PGP/GPG Thing?

Sean C. McCord scmlist at cycoresys.com
Sat Jan 17 00:59:08 EST 2009


On Fri, Jan 16, 2009 at 11:12:16PM -0500, Marc Ferguson wrote:
> 2009/1/16 Michael B. Trausch <mike at trausch.us>
> Awesome, thanks a lot fellas.  I'm using GNOME and my email client is
> Evolution.  I'll certain try your suggestions.  Thanks.  Is there a need for
> a "howto" article or I'm guessing it's pretty straight forward?

It is straight-forward as long as you are looking in the right
direction. :)

If you are familiar with public-private key schemes, such as SSH, you
can grasp the concept, but the viewpoint is slightly different.
Moreover, it is turned backwards when you are talking about signing
versus encrypting.

First, let me say pardon if you are not looking for a theoretical
overview but, rather, want a practical step-by-step.  I couldn't really
tell from your previous emails which you want, and I can't provide any
help with Evolution in any case.  Mutt, after all, is the only email
client for me, since it's the best one.  ;)

To start simply, let's take a look at what you do to simply sign your
email using GPG (or PGP).  You take your email and perform a
cryptographic hash on it using your private key, and tack the resulting
"signature" onto the end of the email.

This signature does two things:
1)  Provides a hash (like an MD5 sum, or SHA, or what have you) which is
used to verify what the other person reads is really what you sent.
2)  Provides a signature that, when paired with the sender's public key,
verifies that who says they sent it _actually_ sent it.

Obviously, in order for this to do any good, the recipient must have
your public key so that he can read the signature.  Further, he must
have obtained that key in a way that he can be assured that it is really
your key.  This is done outside the scope of GPG/PGP.  For instance, you
can put it on your website, or you could have sent it to him in a
previous email that he could verify.  Or, you could have posted your key
and other information to one of the many public key servers.

In any case, the bottom line is that, for signatures to be effective,
the recipient needs a copy of the sender's public key.


Now, let's take a look at encryption.

For encryption, the need is exactly the opposite.  The _sender_ needs
the public key of the _recipient_.  This is because the sender wants the
email to only be read by the intended recipient.  Therefore, he encrypts
the email with the recipient's public key before sending it.  When the
recipient receives the email, he decrypts it using his private key
(which only he should have).


Nothing, of course, precludes you from doing both... sign and encrypt.
Just keep in mind that to do that, both parties need each other's public
keys.


Sorry this email has no particulars.  I was always irritated when I got
into GPG that no one told me _how_ the system worked; they only told me
_what_ to do.


One other design-wise comment of significant import (to me):  gpg is not designed around a hierarchical model.  The trust relationship, unlike the SSL certs of the web world, is not a top-down, government-or-megabusiness-controlled system.  It is, essentially, a one-to-one trust, with an (optional) web of interconnecting inheritance.


So, now that you know what you are doing when you use GnuPG/PGP, the
actual practice is nothing but vocabulary.  Of course, the [G]UIs do all 
of this for you, but it is still good to know what is happening underneath.

gpg --import  --> load a key into your keyring so you can use it

gpg -e  -r joe at nowhere.org  --> encrypt something to joe at nowhere.org's
private key

gpg -s --> sign something (as yourself)


For email, you will need the -a option, as well, which makes everything
in nice, plain ASCII so it can be transmitted in the plain old SMTP
system.


--
Sean C. McCord
scmlist at cycoresys.com



More information about the Ale mailing list