Cryptography worries people. It all seems very complicated. But it needn't be...
The analysis of what encryption techniques work, and how ‘attacks’ can break them, is a huge subject with thousands of egg-head practitioners around the world. But just as we don’t have to understand metallurgy, aerodynamics, structural engineering, fluid flow, electrical standards, crumple zone design and all the other things that make up car design in order to understand how a car works; so we don’t need to understand cryptography in detail to see how it offers security to our software. So when I need to design systems involving cryptography, I concentrate on what cryptography delivers, rather than the detail of how and why it works. It’s enough.
So here’s my ‘bluffers guide to cryptography’.
The Key
The fundamental basis of cryptography is this: a long enough string of random bits cannot be guessed by trial and error. We call such a string of bits a ‘key’. Nowadays a key of 128 bits – think of it as a 21 random characters - is considered long enough to defeat most attackers (I simplify massively – see Wikipedia for more).
Encryption algorithms
There are many ‘encryption algorithms’ to use such a key to encode a message to send or to store. But there are only two important variants:
Symmetric encryption: Here both sender and receiver have the same key. The sender encrypts the message; the receiver decrypts it with the same key. Simple. Common examples are AES, 3DES, and RC4.
Public key encryption: This requires a pair of keys, generated together. We call one of the pair the ‘public key’; it is not secret and can be published anywhere. The other (‘the private key’) is kept secret. But if the sender encrypts the message using the public key, only a receiver with the corresponding private key can decrypt it – and vice versa. Common examples of Public Key Encryption are RSA, DSA and Diffie-Hellman.
That’s it for encryption.
Signing
The next concept is signing. Here the message is sent ‘in clear’, but with extra text that proves that the message is exactly as the sender created it, and that only the sender could have created it.
This requires a ‘hash’, a way of munging the whole message into a few bytes in such a way that any change to the message changes the hash (think checksum). The sender encrypts the hash with its private key to produce a ‘certificate’; any receiver can use the corresponding public key to decode the certificate and check everything’s OK.
Keychains
A final concept is the keychain. This is a way of distributing public keys. The receiver of a message has a ‘root’ public key issued by a trusted company. But you don’t want the trusted company to have to sign every message. Instead the trusted company signs a short text document containing the senders’ identification and public key, and the sender keeps the resulting ‘keychain’.
When the sender wants to sign a message, it sends the message signed with its own public key; it also sends the keychain. The receiver can now use its root public key to validate the keychain and get the sender’s identification and public key; it then uses the sender’s public key to validate the message. This can obviously be extended, and typical internet key chains have 4-6 public keys in them, each validating the next; most browsers have several dozen ‘root’ public keys embedded within them.
For example
Most examples of cryptographic software security are built up from these five concepts. For example, the popular TLS web protocol used in HTTPS has each server configured with a private key, and a public key stored as a keychain.
In the most common use of TLS, the server sends its keychain, and the client verifies it using a root certificate as above. The client then generates a random number, encrypts it with the server’s public key from the keychain, and sends it. Only the server has the private key to decrypt that random number; so both parties can now trust that random number as a key for the symmetric encryption of further messages. That’s it – job done.
But what about the complexity?
So where does the complexity come in? Well, in practice there are many different variations of private key and public key encryptions, and many many more variations of the techniques making use of them. They vary in how easy they are to ‘crack’, in the processing power required to support them, and in a variety of other factors. They have names involving long acronyms…
But for many applications, that doesn’t really matter. We just need to know the principles. And we do!
- Charles
Written by Charles Weir, copyright (c) Penrillian Ltd, used by permission.