Two ways to encrypt

The first approach is symmetric key encryption. The same key does the encrypting and the decrypting. It feels like your front door key: one is enough to lock and to open.

The representative method is AES. It is the most widely used symmetric cipher today, and when something really matters — encrypting files, encrypting a database — this is usually it.

What is good about it is speed. Even comparing at key lengths chosen to give about the same strength, both encrypting and decrypting are far lighter than the public key approach coming next. So when there is a volume of data to move, this is what gets picked.

It goes by several names — symmetric, secret key, shared key — but they all point at the same thing.

Using the same key means the other side has to be holding that key. This is the single biggest weakness of symmetric encryption.

Think it through. You encrypted because you did not want the contents read — so what happens if you send the key itself across the network in the clear? Anyone who glimpses the key can open the ciphertext too. You must never send a key as plaintext.

So to use symmetric encryption you have to hand the key over by some other safe route before the conversation starts. Handing it over in person, passing it by a separate channel — it takes effort.

This question of how to get the key there is called the key distribution problem. It is why symmetric encryption cannot stand on its own.

The other weakness is how many keys you need. A symmetric key has to be a different one for every party you talk to. If A and B are talking with one key and C joins on the same key, C can read what A and B say to each other.

Which means the number of keys needed is the number of pairs. Three people gives A-B, B-C and A-C: three keys. Four gives A-B, A-C, A-D, B-C, B-D and C-D: six.

Here is how to count it. From one person, there are n-1 others. Across everybody that is n(n-1), but A-with-B and B-with-A are the same pair counted twice, so you divide by 2.

So it is n(n-1)/2. For 100 people that is 100 x 99 / 2 = 4950 keys. It gets out of hand fast as numbers grow.

The second approach is public key encryption, and its trick is that keys are made in pairs of two.

• Public key … a key you may hand to anybody
• Private key … held by one person only, and never let out

The two stand in a relationship where what one locks, only the other can open. Something encrypted with a public key can be decrypted only by that person private key.

So there is no longer any need to deliver a key in secret. A public key can be published openly. Everybody knowing the locking key does no harm, because only its owner holds the key that opens.

What may be published is the encrypting key and the method. Only the decrypting key stays secret. That is the decisive difference from symmetric encryption.

This is the most-asked point in the exam. When you want to hide the contents, lock with the recipient public key.

If X is sending mail to Y, what gets used is Y public key. Then the only person who can open it is Y, who holds Y private key.

You must not use your own key. If X locked with X own public key, only X could open it, and Y could not read a thing.

One more important property falls out of this. However many people you send the same ciphertext to, only the key owner can open it. Send mail locked with B public key to both B and C, and C cannot open it with C own private key. "My own private key will open it" is wrong — only what was locked with the matching public key opens.

Go public key and the worry about key counts disappears too, because one pair per person (a public key and a private key) is enough no matter how many people there are.

Why is it enough? Whoever you are sending to, what you use is the key that person has published, and they only ever hold one pair. There is no need to make a new key per correspondent.

So n people means 2 keys each x n people = 2n. Even 100 people comes to 200. Set that against 4950 for symmetric keys.

And there is no work in distributing the extra keys safely, either. A public key may be published, so leaving it lying about is all that is required.

Reading this far, it might seem you should just use public key encryption. But it has a weakness: the arithmetic is heavy. Put a long message through it whole and it takes far too long.

So real encrypted communication combines the two. This is called the hybrid approach.

• The message is encrypted with symmetric encryption (because it is fast)
• The symmetric key it used is encrypted with the recipient public key (because that gets it there safely)
• Both the ciphertext and the encrypted symmetric key are sent

The receiving side pulls the symmetric key out with its own private key, then decrypts the message with that symmetric key.

The neat part is that the heavy public key work is spent on one short key only. The speed stays that of symmetric encryption while public key encryption solves the key distribution problem. https:// traffic has this same shape inside.

And worth holding on to: all this achieves is that the contents are not read. Whether it was tampered with, or whether the sender is who they claim, does not follow from this alone.

Some questions are nothing but a list of method names. Make sure you can say which camp each belongs to.

• AES … symmetric. The current standard
• RSA … public key. Built on how hard it is to factor a very large number
• Elliptic curve cryptography … public key. Gets about the same security from a shorter key than RSA, which suits underpowered machines such as phones
• SHA-256 … not encryption at all, but the hash function coming next

Here are the confusable ones too. DSA is a method for signatures and PKI is the name of the arrangement for handling certificates. Neither is "a method for encrypting data".

Unfamiliar names such as IDEA or KCipher-2 sometimes get mixed in. Remembering them all is hopeless, so crossing off the ones you are sure about is the practical move.

If you do not know the key and want to open a ciphertext, the plainest move is to try keys one after another. This is a brute force attack.

Get hold of one plaintext-and-ciphertext pair and you can fit each candidate key in turn and look for the one that produces that plaintext. So the defending side wins by making the number of candidates too large to get through.

What does that work is key length. An n-bit key has 2 to the n candidates. One extra bit doubles the candidates, so the longer it gets, the sharply stronger it becomes.

Some methods carry the length in their name. AES-256 means a 256-bit key, so trying at most 2 to the 256 times will eventually hit. It will hit, yes — but that is a number that does not finish inside real time.

There are other lines of attack too: ones that take a statistical bias as their handle, ones that watch how the ciphertext changes when the plaintext is altered slightly. Keep brute force filed as "just try them all".

Finally, a tool of a rather different flavour from encryption: the hash function. Put data through and a short value comes out, and that value is called a hash value or a message digest.

It has three properties.

• The length is always the same … whether the input is ten characters or a hundred thousand, the value that comes out is the same length
• One character different, a different value … the slightest change produces something completely unlike
• You cannot get back … recovering the original data from the value is not possible. This is called being one-way

The third is the decisive difference from encryption. Encryption comes back with the key; a hash value comes back for nobody.

The other important idea is a collision — different data producing the same hash value. These must not be easy to make. If a way to build collisions in realistic time is ever found, that function can no longer be called safe. Encryption or hash functions losing their safety through the passage of time and advances in technique is called compromise.

How this short value gets used to check for tampering and to check who somebody is comes in the next lesson.