Encryption, encryption protocols and digital certificates

How encryption works: plaintext, ciphertext, keys and ciphers

Encryption is the process of turning readable data into a form that is meaningless to anyone who does not hold the key. The readable original is plaintext - an email, a password, a card number, a frame of video. The scrambled output is ciphertext, and decryption is the reverse process that turns ciphertext back into plaintext. The point of the whole exercise is that plaintext sent across a network passes through routers, servers and Wi-Fi access points that neither the sender nor the receiver controls, so anyone sitting on that path can copy it.

A cipher is the mathematical procedure that does the scrambling, and a key is the piece of data that the procedure is fed. Good modern design assumes the algorithm is public: AES and RSA are published, documented and analysed by thousands of people, and anyone can read exactly how they work. The security lies entirely in keeping the key secret. If security depended on the algorithm being secret, one leak would compromise every message ever sent with it, and every user in the world would have to change system at once.

A substitution cipher shows the idea, and shows why simple versions fail. Replace every letter with the letter three places further on and 'meet' becomes 'phhw'. The letters have changed, but the pattern of the language has not: e is still the most common letter in the ciphertext, double letters still appear together, and common short words still appear as short words. That leftover structure is what frequency analysis exploits. A modern block cipher such as AES takes 128 bits at a time and shuffles and substitutes them over many rounds, so that changing one bit of plaintext changes roughly half the bits of the ciphertext and no statistical trace of the original survives.

That leaves an attacker exactly two routes. The first is to attack the mathematics - try every possible key, or find a weakness in the algorithm - which is infeasible for a long key. The second is to obtain the key itself by stealing it, guessing it, phishing it or intercepting it while it is being distributed. The second route is almost always easier, which is why the rest of this topic is about keys rather than about ciphers.

Symmetric key cryptography: one shared key

In symmetric key cryptography the same single key is used both to encrypt and to decrypt, so both the sender and the receiver must already hold an identical copy. The key is sometimes called a shared secret or a secret key. It is fast: a modern processor encrypts hundreds of megabytes a second with AES, which is why symmetric ciphers are used for the bulk of the data in every secure connection you make.

Its weakness is not speed but key distribution. If Alice and Bob have never met, how does the key reach Bob without an eavesdropper copying it? Sending the key over the same network that the message will travel on simply moves the problem: whoever can intercept the message can intercept the key. The problem gets worse as the number of users grows, because each pair of users needs its own key: with 100 users that is 4 950 keys to generate, distribute, store and revoke, and with 1 000 users it is 499 500. There is no formula that makes this manageable.

A second weakness is that symmetric cryptography alone gives no proof of origin. Because both sides hold the same key, a message that Bob receives could have been created by Bob himself, so he cannot prove to a third party that Alice sent it. This property is called non-repudiation, and symmetric cryptography cannot provide it.

Key length is the practical defence against brute force. Each extra bit doubles the number of possible keys, so a 128-bit key is not twice as hard to break as a 64-bit one but about 2^64 times harder. DES used a 56-bit key and is now breakable by dedicated hardware in hours, which is why it was replaced by AES, which uses 128, 192 or 256-bit keys.

• One key, two directions: the same key encrypts and decrypts, so both parties must already hold it.
• Fast: ideal for bulk data such as files, video and the body of a web page.
• Key distribution problem: the key has to reach the other party securely before anything can be sent.
• Scaling problem: n users need n(n-1)/2 keys, so 1 000 users need 499 500 keys.
• No non-repudiation: either party could have produced the ciphertext, because both hold the same key.
• Examples: AES (128/192/256-bit keys) is current; DES (56-bit) is obsolete.

Asymmetric key cryptography: a linked pair of keys

Asymmetric key cryptography uses two different but mathematically related keys, generated together as a key pair. The public key is published - placed in a directory, on a website, inside a digital certificate - and anyone may have a copy. The private key never leaves the owner's machine and is never transmitted. What one key of the pair encrypts, only the other key can decrypt, and it is computationally infeasible to work out the private key from the public one.

The relationship is a one-way function: easy to compute in one direction, effectively impossible in the other. In RSA, the public key is built from the product of two very large prime numbers, and recovering the private key means factoring that product back into the two primes - trivial for small numbers, hopeless for the 2 048-bit keys used in practice. The pair can be generated locally on the owner's own machine, so the private key never has to cross a network, which removes the distribution problem that symmetric cryptography suffers from.

The price is speed. Asymmetric operations involve arithmetic on very large numbers and are hundreds to thousands of times slower than AES, so asymmetric cryptography is never used to encrypt a video or a whole web page. It is used for short pieces of data only: encrypting a symmetric session key, and creating and checking digital signatures.

The direction of use decides what you get, and this is the single most examined idea in the topic. Encrypting with the recipient's public key gives confidentiality, because only the holder of the matching private key can decrypt. Encrypting with the sender's private key gives authenticity and integrity, because anyone can reverse it with the published public key, so the only way to produce it was to hold the private key.

Sending a private message from the public to an individual or organisation

This is the case the syllabus describes as a private message from the public: a customer, a stranger, someone who has never spoken to the organisation before, wants to send it something that nobody else may read. A bank publishes its public key. The customer fetches it, encrypts the message with it, and sends the ciphertext. The ciphertext can only be decrypted with the bank's private key, which never left the bank's servers. The customer cannot read back what they have just sent either, which is a useful test that the encryption was done the right way round.

The elegance of this is that no prior shared secret is needed. The public key can be published to the entire world, printed on a poster, embedded in a certificate; publishing it does not weaken the encryption in the slightest, because it can only be used to lock data, not to unlock it. This is how asymmetric cryptography solves the key distribution problem: a million customers can each use the same public key, and only the organisation can open what they send.

The weakness is the reverse of the one it solves. Nothing in the mathematics tells the customer that the key they downloaded really belongs to the bank. An attacker who can intercept the traffic could publish their own public key, claim to be the bank, decrypt everything the customer sends with their own private key, re-encrypt it with the real bank's public key and pass it on. That is a man-in-the-middle attack, and the answer to it is the digital certificate covered later in this topic.

• 1. The organisation generates a key pair and publishes the public key.
• 2. The member of the public obtains that public key (in practice from the organisation's digital certificate).
• 3. The sender encrypts the plaintext with the organisation's public key to produce ciphertext.
• 4. The ciphertext is sent across the network; anyone may copy it, but it is meaningless to them.
• 5. The organisation decrypts with its private key, which no one else holds.
• 6. The message is confidential: no other party, including the sender, can recover the plaintext from the ciphertext.

Sending a verified message to the public: digital signatures

Now reverse the problem. A software company publishes a security update and wants every customer to be able to check that it genuinely came from the company and was not altered on the way. Confidentiality is not the issue - the update is public - so encrypting it with the customers' public keys would be pointless. What is needed is proof of origin and proof of integrity.

The sender first computes a hash of the message: a fixed-length digest, produced by a one-way function, such that the same message always gives the same digest and any change to the message - even a single bit - produces a completely different one. The sender then encrypts that hash with their own private key. The result is a digital signature, which is sent alongside the message. This is exactly how a digital certificate is used to produce digital signatures: the certificate proves which public key belongs to the sender, so the receiver knows whose key to verify against.

The receiver decrypts the signature using the sender's public key, which recovers the original hash. The receiver then hashes the message they actually received and compares the two digests. If they match, the message is unchanged; and because only the sender holds the private key that produced the signature, the message must have come from the sender. If a single character was altered in transit, the recomputed hash will not match and the software refuses to install.

A digital signature therefore gives three things at once: authenticity (it came from the holder of that private key), integrity (it has not been altered) and non-repudiation (the sender cannot credibly deny having signed it, because no one else could have produced that signature). It gives no confidentiality, because anyone with the public key can read the message. Real systems that need both sign and encrypt: sign with the sender's private key, then encrypt the message and the signature with the recipient's public key.

How data is encrypted and decrypted with symmetric and asymmetric cryptography together

Real systems do not choose between the two types; they use each one for what it is good at. Asymmetric cryptography solves the key distribution problem but is far too slow for bulk data. Symmetric cryptography is fast but needs a shared key. The hybrid approach uses asymmetric cryptography once, at the start, to establish a symmetric key, and then uses that symmetric key for everything else.

The sequence is the one you must be able to write out. The client contacts the server and the server replies with its digital certificate, which contains its public key. The client checks the certificate against the certificate authorities it already trusts. The client then generates a random session key, encrypts it with the server's public key, and sends it. Only the server can decrypt that with its private key, so both ends now hold the same session key and nobody listening does - the key distribution problem is solved without the key ever being readable in transit. From that point the session uses a fast symmetric cipher such as AES, with a new session key for each connection.

TLS can also agree the key rather than transmit it, using Diffie-Hellman key exchange (in modern TLS, the ephemeral form). Each side contributes to a shared value that neither can predict alone, and the key is never sent at all, even in encrypted form. Ephemeral keys also give forward secrecy: because a fresh key is derived for every session and then discarded, stealing the server's long-term private key tomorrow does not allow an attacker to decrypt the traffic they recorded today.

The practical lesson is that both types appear in one connection, doing different jobs: asymmetric cryptography for identity and key exchange, symmetric cryptography for the data itself. A candidate who says 'TLS uses asymmetric encryption' without qualification has described only the beginning of the connection.

• Asymmetric job: prove the server's identity and get a key safely to the other side.
• Symmetric job: encrypt the actual data, fast, for the rest of the session.
• The symmetric key is called a session key; a new one is generated for each connection.
• The session key may be sent encrypted with the server's public key, or agreed using Diffie-Hellman and never transmitted.
• Forward secrecy: ephemeral session keys mean a stolen long-term private key does not expose recorded past traffic.

Digital certificates and how one is acquired

A public key on its own is just a number: it cannot tell you whose key it is. A digital certificate is the file that binds a public key to an identity, and it is signed by a certificate authority (CA) - a body that both parties already trust. It contains the subject's name or domain name, the subject's public key, the name of the issuing CA, the validity dates, a serial number, the signature algorithm, and the CA's own digital signature over all of those fields.

Acquisition follows a fixed sequence. The organisation generates its key pair locally, so the private key never leaves its control. It then creates a certificate signing request (CSR), which contains its public key and identity details and is signed with its own private key to prove it holds the matching private key. The CSR is submitted to a CA, which verifies the identity claimed: for a basic domain-validated certificate the CA only checks that the applicant controls the domain, while organisation-validated and extended-validation certificates require company documents and sometimes a phone call. The CA then issues the certificate and signs it with the CA's private key. The organisation installs the certificate, and where an intermediate CA was used, the intermediate certificate as well.

Why anyone should believe the CA comes down to the chain of trust. Operating systems and browsers ship with a store of trusted root certificates, installed by the manufacturer. A root CA does not usually sign websites directly; it signs an intermediate CA, which signs the website's certificate. When a browser receives a certificate it follows the chain up to a root it already holds, checking each signature with the issuer's public key. If the chain reaches a trusted root, the site's public key is trusted - even though the browser has never heard of that site before.

Two practical points finish the picture. Certificates expire, which limits the damage if a key is later compromised, and they can be revoked before expiry if a private key leaks or an organisation closes; browsers check revocation lists or use the Online Certificate Status Protocol. A self-signed certificate, signed by its own key rather than by a CA, produces a browser warning and is only appropriate for internal testing. Free domain-validated certificates from Let's Encrypt, issued and renewed automatically through the ACME protocol, are why almost all web traffic is now encrypted.

SSL and TLS: purpose and use in client-server communication

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are protocols that sit between the application layer and the transport layer and turn an ordinary, readable TCP connection into a secure one. SSL is the older name; SSL 2.0 and 3.0 are obsolete and insecure, and the versions in use are TLS 1.2 and TLS 1.3, though the term 'SSL' is still used loosely across the industry. Because it sits below the application, any application can use it: HTTPS is simply HTTP carried over TLS, normally on port 443, and the same protection is used for IMAPS and SMTPS for mail, FTPS for file transfer, and VPNs.

The purpose of TLS is to provide three guarantees for a connection over an untrusted network. Confidentiality: the data is encrypted with a symmetric session key, so anyone copying the packets learns nothing about the content. Integrity: each record carries a message authentication code, so a packet altered or injected in transit is detected and discarded rather than delivered. Authentication: the server presents a digital certificate, so the client knows it is talking to the real server and not to an impostor. The client can also present a certificate, which is how mutual TLS works between servers.

In client-server communication the guarantees are established during the handshake, before any application data is sent. The client sends a hello listing the TLS versions and cipher suites it supports; the server chooses and replies with its certificate; the client verifies the certificate against its trusted roots and checks the name matches the host it asked for; the two sides then establish the session key, either by the client encrypting a generated key with the server's public key or by Diffie-Hellman key agreement; and from then on both ends encrypt and decrypt with that symmetric key. The expensive asymmetric work happens once, and the bulk data uses the fast symmetric cipher.

When TLS is appropriate: any time credentials, payment details, personal data, messages or anything whose integrity matters crosses a network you do not control. Logging in anywhere, online banking and shopping, webmail, APIs carrying tokens, public Wi-Fi, and increasingly traffic between internal services on the grounds that the internal network is not automatically safe. When it adds little: transferring files between two machines on an isolated network with no confidentiality or tampering risk, or on hardware so constrained that the handshake cost matters more than the risk - though even there the trend is towards encrypting everything. It is also worth knowing what TLS does not do: it does not protect data stored on a server, it does not stop a legitimate server from being malicious or compromised, and it does not hide the fact that a connection happened or, in most configurations, which domain was visited.

Quantum cryptography: purpose, benefits and drawbacks

Quantum cryptography uses the behaviour of individual photons to distribute a key, so that its security rests on the laws of physics rather than on the difficulty of a mathematical problem. The practical technique is quantum key distribution (QKD): each bit of the key is encoded in the polarisation or phase of a single photon sent down a fibre-optic cable. An eavesdropper cannot copy an unknown quantum state - the no-cloning theorem - and cannot even measure it without disturbing it, so any attempt to read the key in transit leaves a detectable trail of errors.

The best-known protocol is BB84, published by Bennett and Brassard in 1984. The sender encodes each bit using one of two randomly chosen bases and records which basis was used; the receiver measures each photon using a randomly chosen basis of their own. The two then compare, over an ordinary public channel, which bases they used - not the values - and keep only the bits where the bases matched. They sacrifice a sample of the remaining bits to check the error rate: if it is above the level expected from noise, someone was listening, the key is thrown away and the process starts again. Eavesdropping is therefore not merely difficult but detectable, which is the whole point.

The benefits follow from that. Security does not depend on computational hardness, so a future quantum computer running Shor's algorithm - which would break RSA and elliptic-curve keys - does not threaten a QKD key. Interception is detected rather than hidden, so there is no silent compromise. And because a key can be discarded whenever the error rate is too high, recorded traffic cannot be attacked later with a key that was captured but not noticed, which matters for data that must stay confidential for decades.

The drawbacks are practical and severe. It needs specialised hardware - single-photon sources and detectors - and it is expensive. Range is limited, because photons are lost in optical fibre and, unlike a signal, cannot be amplified by a repeater without destroying the quantum state; long distances need trusted intermediate nodes or satellite links. Key rates are low, so QKD produces keys for symmetric ciphers rather than carrying data itself. It is point-to-point, not broadcast. It also still needs an authenticated classical channel to compare bases, so it solves key distribution but not authentication - that still needs certificates. Outside trial metropolitan networks and research links, deployment is very limited.

• Purpose: distribute a symmetric key with security guaranteed by physics, not by computational difficulty.
• Mechanism: single photons in randomly chosen bases; measuring disturbs the state, so eavesdropping shows up as errors.
• Benefit: eavesdropping is detected, not just made hard; immunity to attack by a future quantum computer.
• Benefit: a compromised key is discarded, so recorded traffic cannot be decrypted later.
• Drawback: specialised, expensive hardware; short range because photons cannot be amplified.
• Drawback: low key rates, point-to-point only, and it still needs an authenticated channel, so it does not replace certificates.
• Drawback: not widely deployed; mainly trials and metro-scale networks.