Revision as of 22:49, 20 December 2010

Reproduced by kind permission of John Wiley & Sons.

For additional background reading, we recommend Applied Cryptography by Bruce Schneier [Schneier 1996] and Understanding PKI by Carlisle Adams and Steve Lloyd [Adams and Lloyd 1999].

Asymmetric Key Pairs

Unlike symmetric cryptography, where the same key is employed to decrypt data as was used to encrypt it, asymmetric cryptography is based on a related pair of keys. You can then use one key to encrypt the data, and the other to decrypt it – and vice versa. The generally followed scheme is for you to publish one key (referred to as a public key) and keep the other key (the private key) secret. This means that the following mechanisms can be used:

1. Using your public key, I can encrypt data, safe in the knowledge that only you can decrypt it.
2. Using my private key, I can encrypt data that anyone can decrypt using my public key.

Mechanism 2 doesn’t sound too useful at first. However, if the data does decrypt correctly (and you’ll need to recognize this – perhaps by seeing readable text) then you’ll know that I (and nobody else) encrypted it.

Hard-core cryptographers will argue over the rather general statements made above, and quite rightly point out that everything depends on the fact that private keys remain private and public keys are always correctly associated with the correct owner. Also, as time goes on, technological advances in cryptanalysis and mathematical wizardry mean that mechanisms 1 and 2 above become less reliable – which is why cryptography continuously evolves as well (e.g. by employing increasingly larger key sizes).

The Cryptographic Hash

A hash function takes some variable-length input data and produces a fixed-length output, which is usually called the hash or message digest. The idea here is that it’s extremely costly or time-consuming to find – or concoct – another input that produces the same hash value. It should also be effectively impossible to determine anything about the original input from the hash output.

How Signing Works

Signing a piece of data is a two-step process. First I calculate the hash of the data I wish to sign. Second, I encrypt the hash with the private key from my own asymmetric key pair. I can then send, post, or publish this data and signature. (Note that the data itself is not encrypted – only the hash.)

You, the recipient, by using my public key, are able to decrypt the hash and also run the same hash operation yourself to confirm that you come up with the same hash value. If the hash values match, then you can be reasonably sure (within cryptographic guarantees) that:

• The data hasn’t been tampered with.
• I constructed the data and I am the source.

There are things you are going to need to know to ‘verify’ the signature, and I didn’t draw attention to them in the paragraph above. The first is the ability to identify or obtain my public key (as opposed to anyone else’s). As I said earlier, this can be a little tricky to resolve. The second is the hash algorithm I used to calculate the hash (of which there are quite a few), and the third is the encryption algorithm, which I used to encrypt the hash. Standards exist which specify how these things go together to form a signature (for example, see the PKCS#7 and other related standards at http://www.rsasecurity.com/rsalabs).

The Digital Certificate

The digital certificate is an amalgamation of a number of useful things into a signed data container. The two key pieces of information present are:

• a public key
• Some information which can help to identify the owner or subject. In particular, this information should help differentiate the owner from others, and give you some idea that the public key belongs to that person and that the data therein matches your knowledge of the real person (name, country, company, e-mail address, etc.).

Other information is present too – in particular a date validity period and information about who issued (and signed) the certificate.