The Internet has grown uncontrollably over the past 10 years, and with that has grown the ability to communicate with people that you have never met - and often will never meet.

This has resulted in a number of fundamental security issues:

In the virtual world, I may well claim to be John Cleese. The question is how can the recipients of my email verify whether I am John Cleese or not?

A not unrelated question is how the recipient knows this message really came from you. This is where GNU Privacy Guard comes into play. GPG is an open source implementation of PGP (Pretty Good Privacy). Since PGP is proprietary and not open to public scrutiny, it cannot, and should not, be used without purchasing it. In response to not being able to use PGP without having licensing issues, GPG was developed.

Transmitting a message from one mail server to another over thousands of kilometers to places I never even knew existed, poses the problem of whether someone or something in between the source and destination has intercepted the email, modified it and sent it on to the recipient. Neither I, nor the recipient, would have any idea that the email had been modified until I received a message in reply from the receiver.

Finally, given the nature of communication today, we all require some degree of privacy and knowing that someone could intercept your email's and read them (even if they don't wish to cause any damage) is a little disconcerting. I certainly would not like everyone to have access to every letter that arrived in my post box at home. We need some means of encrypting sensitive email's.

Data encryption can be categorized broadly into:

a) the use of symmetric keys and

b) public/private key infrastructure (PKI).

In this case, although you don't need to decrypt the email, you will want to check that it was me who sent it.

Signing is slightly different to encrypting. Put differently:

"A major benefit of public key cryptography is that it provides a method for employing digital signatures. Digital signatures enable the recipient of information to verify the authenticity of the information 's origin, and also verify that the information is intact. Thus, public key digital signatures provide authentication and data integrity. A digital signature also provides non-repudiation, which means that it prevents the sender from claiming that he or she did not actually send the information." - Introduction to Cryptography

In order the achieve this signature, I would sign an email or a document with my private key.

The recipient would merely receive the signed email and check it against my public key. If they match, bingo, the email could only have originated from me.

Setting up the PKI is slow sometimes waiting from 1 to 5 minutes while an email is signed.

Clearly, we need a faster mechanism.

Here we can introduce the concept of "one-way hashing", take a document, email or a piece of text. I hash it, and this produces a "short" number. If the original document is changed (even by a single letter), the resulting hash will be a completely different number.

Let 's bring this all back to a real-world application. Suppose I have an email that is of no real value to require that it be encrypted. For example, I may be wanting to send my family an email with my intended arrival time on an international flight. I do want them to know that the email was from me, so I wish to sign it. My email client will generate a one-way hash creating a unique string from the contents of this email. This string is known as a message digest. It ensures that the recipient knows the email has not been changed since it was sent.

However, we still need to encrypt the message digest.

Why? Well if you give this just a little thought, you will realize that an eavesdropper could easily intercept this email. Change the contents and re-hash it, attaching the new hash to the email. My family would receive it, check that the hashes match (which they do since the modified document was rehashed), and would assume that the document was the one sent by me. Of course this is not so, and so our signing did not work.

If I encrypt the hash using my private key, then the receiver could use my public key decrypt the hash, rehash to original plain text email and compare the hashes. If they match, there can be no doubt that

a) the message has not changed since I sent it, and

b) it was in fact me that sent it.

I hear you ask whether the attacker (eavesdropper) couldn't just use my public key to decrypt the hash, change the document and rehash as before, and then forward the modified document to the recipient?

They could indeed do that, but signing a document involves both the hash as well as encrypting the hash.

This is the part where they (the eavesdropper) would need my private key, which of course they don't have. So, the recipient would know the email was not from me and would therefore not trust it.

Again, in summary, while encryption is done using the recipient's public key (Ed:decryption is done by the recipient, using the public key that you have sent him which corresponds to your private key CHECK), signing is done using your private key.

Back to reality?

Let 's get down to some practical applications of keys.

GNU Privacy Guard or GPG, is the package that we will use to sign and encrypt data. Like any system, the efficacy of the system is as good as the people who manage it.

If your operating system is insecure and others can obtain your private key, then the system will break down.

If on the other hand, you never check a person 's public key - (i.e. That is really belongs to that person), then the system will break too.

So the system is as good as the people are vigilant.

We need to generate our public/private keys, and for this we will use the "apg" command.

The "gpg" utility has a number of switches, one of which is to generate the key:

gpg --gen-key

If you have not run this before, it will generate an error because the relevant working directories have not been created. Running the program the first time will create the directories.

You will need to run it again to begin key generation.

Now, it will ask what type of cipher you wish to use. In general, you can choose the default.

Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) ElGamal (sign and encrypt) (5) RSA (sign only)

Then, choose the number of bits for the DSA key. The default should be fine here too.

Naturally, the higher the number of bits, the more difficult is will be to crack, but for now, 1024 should be OK. ^[6]

I suggest that you never expire your GPG key (option 0 in the menu).

Now you're ready to enter your personal details - your name, a comment and your email address. Mine would be:

Real name: hambo Email address: hambo@QEDux.co.za Comment: Hambo the Sambo

Once you're happy with these details, choose OK.

Now comes the rub. You need to enter a pass phrase. This should be enough of a phrase that it is not easily crackable. Note that this is not a password. It wants a phrase. "The cat sat on the mat" would be such a phrase ummm, perhaps that 's more of a clause (-;

All the principles of a good passwords apply to a pass phrase. Remember that you will need to type this phrase each time you wish to sign, encrypt anything.

Generation of your public and private keys begins. Read the output as its happening, as sometimes it requires that you move the mouse around to generate more random numbers.

Finally, the keys are produced and you can sit back at this point and smirk at your ingenuity! I've included my output here.

gpg: /home/hamish/.gnupg/trustdb.gpg: trustdb created public and secret key created and signed. key marked as ultimately trusted. pub 1024D/A6B68161 2004-03-28 hambo (Hambo the Sambo) \ <hambo@QEDux.co.za> Key fingerprint = 6CAF EBE7 1299 CB3E B293 D729 20FA \ 26C7 A6B6 8161 sub 1024g/22CA1FAD 2004-03-28

	Note
	This is just an example. My real public key is available from my website www.QEDux.co.za

Now that you've generated your public/private key pair, ensure that the .gnupg directory is well and truly secured.

ls -ald .gnupg drwx------ 2 hamish users 4096 Mar 28 14:28 .gnupg

Notice that only the owner (hamish) has access to this entire directory.

ls -al .gnupg total 36 drwx------ 2 hamish users 4096 Mar 28 14:28 . drwx------ 41 hamish users 8192 Mar 28 13:59 .. -rw-r--r-- 1 hamish users 7793 Mar 28 13:59 options -rw-r--r-- 1 hamish users 909 Mar 28 14:28 pubring.gpg -rw-r--r-- 1 hamish users 0 Mar 28 14:01 pubring.gpg~ -rw------- 1 hamish users 600 Mar 28 14:28 random_seed -rw------- 1 hamish users 1367 Mar 28 14:28 secring.gpg -rw-r--r-- 1 hamish users 1240 Mar 28 14:28 trustdb.gpg

Here the secure (private key) is "secring.gpg". It has permissions of read and write, but only for the owner (hamish). The "pubring.gpg" (and that is not the ring for the last round either;-), is the public key.

You still need to "export" the public key so that others may download it and import it onto their keyring.

This can be done with:

gpg -a --export hambo > hambo.asc.pubkey
                

Take a look at the resulting output. This key can now be emailed to your friends, or put on your website or included in the NIS map for your site to make it available to others.

Now, since you will probably be working on a single machine when doing this and not in an environment that you can swap keys with others, you will need to create a second user on your machine and pretend that this user and yourself are swapping your keys.

Once you've exported and imported each other's keys, we can begin talking about signing each others keys. So, at this point, you need to complete the exercises.

Once you have the public key of someone else, import it using:

gpg -import hambo.asc.pubkey
                

It is no use obtaining someone 's key without first verifying that the key belongs to them.

There are many methods of doing this, but probably the easiest one (for now) is to check their fingerprint, call them up and verify it.

gpg -fingerprint hambo
gpg -fingerprint sam
                

These commands should do it. Ensure that you and Sam read your fingerprints out to one another.

If the fingerprints don't match, you can simply delete the key and begin again. If they do match, then you will want to sign their key.

That raises the last concept of this signing and encrypting section.

In an organization, you soon get to know those individuals that spread rumors. Can these people be trusted with a secret you want to share with them? There are others however that, no matter how important the secret is, they will simply never tell another soul without your permission.

So it is with public keys. Suppose I have exchanged public keys with Sam. I know Sam is a complete stickler for detail and checks and rechecks each key on his keyring before signing it. Now Mary sends me her key and this key has been signed by Sam. Sam trusts Mary ultimately (because Mary is also vigilant about her keys). Even though I don't know Mary (she happens to be a friend of Sam's), can I trust her key? Yes, because it has been signed by Sam.

Jakes on the other hand is a little less reliable. Sam has sent me Jake's key, but he's been known to sign keys without properly verifying the signatures. Can I trust signed documents from Jakes? Well, I may trust them partially, but in order to completely trust anything from Jakes, I would probably want to verify the key from another source too. If the other source verifies the signature is valid, only then can I trust it.

This process of trust is known as the web of trust. When listing a uid (a users ID) with "edit-key", there is a "trust" section that determines:

a)the level of trust you have in the person from whom you have received the key

b)the validity of the key - did you verify their fingerprint?

Examples may be:

trust m/f
                

Person XYZ is trusted marginally (m), but a full (f) verification of their fingerprint has been done.

From the gpg(1) man page, the following trusts are documented:

Signing keys is imperative since it increases the web of trust. ^[7]

This is a relatively involved subject and one that takes time to assimilate.

In sum then, digital signatures, hashing and public/private and symmetric keys ensure that:

1.You are who you say you are, and that this message really come from you (digital signatures)

2.You are able to keep messages from being tampered with during their transmission (hashing)

3.You are able to keep messages secret (encryption) - only to be viewed by individuals for whom they are intended