Encryption Protocols, Digital Signatures and Certificates
Encryption alone proves nothing about who you are talking to. This section covers the two mechanisms that
close that gap: digital signatures and certificates, which establish identity and integrity, and
the SSL/TLS protocol, which combines everything into a secure connection.
1. The Problem Encryption Does Not Solve
Asymmetric encryption lets anyone encrypt a message with your public key that only you can decrypt. But two questions remain unanswered:
- Authentication — is this public key really the bank's, or an attacker's?
- Integrity — has the message been altered in transit?
An attacker who substitutes their own public key for the bank's can read everything the customer sends. This is a
man-in-the-middle attack, and encryption by itself cannot prevent it. Certificates exist
precisely to defeat it.
2. Hashing and Message Digests
A hashing algorithm reduces a message of any length to a fixed-length value called a message digest or hash.
| Property | Meaning |
|---|---|
| One-way | The original message cannot be recovered from the digest |
| Deterministic | The same message always produces the same digest |
| Avalanche effect | Changing a single character changes the digest completely |
| Fixed length | The digest is the same size regardless of message length |
Because any change alters the digest, comparing digests detects tampering.
3. Digital Signatures
A digital signature proves who sent a message and that it has not been altered. It uses the key pair in the opposite direction to encryption.
The crucial reversal. For confidentiality, the sender encrypts with the recipient's public
key. For a signature, the sender encrypts the digest with their own private key — because
only their matching public key can decrypt it, and only they possess the private key.
Creating and checking a signature
SENDER (Alice)
1. Hash the message -> digest
2. Encrypt the digest with
ALICE'S PRIVATE KEY -> digital signature
3. Send: message + signature
RECEIVER (Bob)
4. Decrypt the signature with
ALICE'S PUBLIC KEY -> digest A
5. Hash the received message -> digest B
6. Compare digest A with digest B
Match -> message is authentic AND unaltered
No match -> message was altered, or not sent by Alice
| What it proves | How |
|---|---|
| Authentication | Only Alice's private key could produce a signature her public key decrypts |
| Integrity | Any alteration changes the digest, so the two digests differ |
| Non-repudiation | Alice cannot deny sending it, since only she holds her private key |
A digital signature does not keep the message secret. The message itself is sent unencrypted
unless separately encrypted. Signing provides authentication and integrity, not confidentiality — a very
common confusion.
4. Digital Certificates
A signature verifies a message given a trusted public key. A digital certificate is what makes the public key trustworthy in the first place. It is issued by a Certificate Authority (CA) — an organisation both parties trust.
| A digital certificate contains |
|---|
| The owner's name and domain |
| The owner's public key |
| The name of the issuing Certificate Authority |
| A serial number |
| An expiry date |
| The CA's digital signature over all of the above |
Where the trust comes from. The CA signs the certificate with its own private key. A browser
already holds the public keys of trusted CAs, so it can verify that signature. If it checks out, the public key
inside genuinely belongs to the named owner — and the man-in-the-middle attack fails, because the attacker
cannot produce a CA signature over their own substituted key.
5. SSL and TLS
SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are the protocols that combine certificates, asymmetric encryption and symmetric encryption into a secure connection. TLS has superseded SSL, though the older name is still used loosely. This is what https uses.
The handshake
1. Client -> Server "Hello" - requests a secure connection,
states the TLS versions and ciphers it supports
2. Server -> Client Sends its DIGITAL CERTIFICATE
(containing the server's public key)
3. Client Verifies the certificate using the CA's public key
- checks the CA signature
- checks the expiry date
- checks the domain matches
4. Client Generates a SESSION KEY (a symmetric key)
-> Server Encrypts it with the SERVER'S PUBLIC KEY and sends it
5. Server Decrypts the session key with its PRIVATE KEY
Both sides now share the session key
6. Client <-> Server All further data is encrypted SYMMETRICALLY
using the session key
Why both kinds of encryption are used. Asymmetric encryption is secure but slow, so it is used
only briefly — to verify identity and to transport the session key. Symmetric encryption is fast, so it
carries the actual data. This combination gives secure key exchange and efficient bulk transfer.
The session key
- It is symmetric — the same key encrypts and decrypts
- It is generated fresh for each session, so a compromised key affects only that session
- It is discarded when the session ends
- It never crosses the network unprotected — it travels encrypted with the server's public key
6. Exam Focus
State which key is used at every step. Signing uses the sender's private key;
verifying uses the sender's public key; sending the session key uses the server's public key;
recovering it uses the server's private key. Naming the wrong one loses the mark even when the process
described is otherwise right.
Separate the certificate from the signature. A digital signature authenticates a
message. A digital certificate authenticates a public key, and is itself signed by a CA. Questions
frequently test whether candidates can distinguish them.
Explain the mix of encryption types. When asked why TLS uses both, the marks are for asymmetric
being secure but slow, symmetric being fast, and asymmetric being used to exchange the symmetric session key
safely.
Quick self-check
- State three properties of a hashing algorithm used for a message digest.
- List the steps by which Alice signs a message and Bob verifies it, naming each key.
- State four items contained in a digital certificate.
- Explain how a certificate prevents a man-in-the-middle attack.
- Describe the TLS handshake in five steps.
- Explain why a new session key is generated for every session.
- Does a digital signature keep a message confidential? Justify your answer.