Encryption and Digital Signatures

Every time you log in to a banking site, send a private message or buy something online, your data crosses networks operated by complete strangers — ISPs, transit providers, Wi-Fi hotspots — any of whom could in principle read it. Encryption is what makes this safe: it scrambles data so that even if it is intercepted, it is unintelligible to anyone without the key. But confidentiality is only part of the story. How do you know the bank's website is really the bank and not an impostor? How does the recipient of a message know it genuinely came from you and was not altered en route? Those questions — authentication and integrity — are answered by digital signatures and digital certificates, which are built on the same key-based cryptography.

At A-Level you must distinguish symmetric from asymmetric (public-key) encryption, explain the role of public and private keys, describe how a digital signature provides authentication and integrity, explain what a digital certificate is and the role of a Certificate Authority (CA), and — pulling it all together — explain how HTTPS/TLS combines these techniques. The most common exam pitfall is muddling which key does what (encrypt vs decrypt vs sign vs verify), so we will be ruthlessly precise about that throughout.

---

Spec Mapping

This lesson addresses the Communication and networking area of the AQA A-Level Computer Science (7517) specification, specifically encryption and related security techniques. It covers symmetric (private-key) encryption and asymmetric (public-key) encryption; the role of public and private keys; the key-distribution problem and how asymmetric cryptography solves it; digital signatures for authentication and integrity; digital certificates and Certificate Authorities; and how HTTPS/TLS combines asymmetric and symmetric encryption into a hybrid scheme. It links to the protocols content (HTTPS, SSH) and to the fundamentals of computer systems area, where classical ciphers and the principles of encryption are introduced.

---

What Encryption Is

Encryption converts plaintext (readable data) into ciphertext (scrambled, unintelligible data) using an algorithm (a cipher) together with a key. Decryption reverses the process. The security rests on the key, not the secrecy of the algorithm — a principle known as Kerckhoffs's principle: a good cryptosystem is secure even if everyone knows the algorithm, provided the key is secret. This is why AES and RSA are public, standardised and yet trusted.

flowchart LR
    P1["Plaintext"] --> EA["Encryption algorithm + key"] --> C1["Ciphertext"]
    C1 --> CH["(travels over the network<br/>— interceptable but unreadable)"]
    CH --> C2["Ciphertext"] --> DA["Decryption algorithm + key"] --> P2["Plaintext"]

Encryption delivers confidentiality — and only confidentiality on its own. It does not, by itself, prove who sent the data or that it was not altered; those properties come from the signature and certificate machinery later in this lesson. Keeping the three goals separate — confidentiality (encryption), authentication (who sent it) and integrity (not tampered with) — is the single clearest way to avoid losing marks on this topic.

---

Symmetric Encryption (Private-Key)

In symmetric encryption, the same secret key is used for both encryption and decryption. Sender and receiver must both hold this one shared key, and it must be kept secret from everyone else.

flowchart LR
    subgraph Sender
      P1["Plaintext"] --> E["Encrypt with shared key K"] --> C1["Ciphertext"]
    end
    C1 --> C2["Ciphertext over network"]
    subgraph Receiver
      C2 --> D["Decrypt with the same shared key K"] --> P2["Plaintext"]
    end

Examples: AES (Advanced Encryption Standard) is the dominant modern symmetric cipher, with 128-, 192- or 256-bit keys; DES (56-bit) is now insecure because its key is short enough to brute-force; 3DES applies DES three times as a stop-gap strengthening.

Property	Symmetric encryption
Keys	One shared secret key, used to both encrypt and decrypt
Speed	Fast — computationally efficient, suited to bulk data
Main weakness	The key-distribution problem (below)
Key count for n users	$\frac{n(n-1)}{2}$2n(n−1)​ keys if every pair needs its own

To make the idea of a shared key concrete (real ciphers like AES are far more complex, but the principle is identical), consider a trivial shift cipher with the shared key "shift by 3". Encrypting the plaintext HELLO shifts each letter forward by three positions to give the ciphertext KHOOR; the receiver, knowing the same key (shift by 3), shifts each letter back by three to recover HELLO. The defining feature is that the identical key drives both directions — and that anyone who learns "shift by 3" can both encrypt and decrypt, which is exactly why the key must stay secret and why getting it to the other party safely is the central problem.

The Key-Distribution Problem

Symmetric encryption has one serious flaw that motivates everything that follows: how do the two parties agree the shared key in the first place? If they have never met, the key itself must travel over the network — but the network is exactly the insecure channel they are trying to protect. An eavesdropper who captures the key in transit can decrypt everything. You cannot encrypt the key to protect it, because that just needs another key, and so on. This is the key-distribution (or key-exchange) problem, and it is the headline disadvantage of symmetric encryption.

The scalability issue compounds it. If every pair of users in a group needs a unique shared key, then for $n$n users the number of keys is $\frac{n(n-1)}{2}$2n(n−1)​. For 1,000 users that is $\frac{1000 \times 999}{2} = 499{,}500$21000×999​=499,500 keys — clearly unmanageable. Both problems are solved by asymmetric encryption.

---

Asymmetric Encryption (Public-Key Cryptography)

In asymmetric encryption, each party has a key pair: a public key, which may be shared with anyone, and a private key, which is kept absolutely secret. The two keys are mathematically related such that what one key encrypts, only the other key can decrypt — and, crucially, the private key cannot feasibly be derived from the public key.

There are two distinct usage modes, and confusing them is the commonest error on this topic:

Goal	Encrypt with	Decrypt / verify with	Why
Confidentiality (send a secret to Bob)	Bob's public key	Bob's private key	Only Bob holds his private key, so only Bob can read it
Authentication / signing (prove I, Alice, sent it)	Alice's private key	Alice's public key	Only Alice could have produced something her public key reverses

flowchart LR
    subgraph Sender["Sender (wants to send Bob a secret)"]
      P1["Plaintext"] --> E["Encrypt with BOB'S PUBLIC key"] --> C1["Ciphertext"]
    end
    C1 --> C2["Ciphertext over network"]
    subgraph Receiver["Bob"]
      C2 --> D["Decrypt with BOB'S PRIVATE key"] --> P2["Plaintext"]
    end

Examples: RSA (Rivest–Shamir–Adleman), whose security rests on the difficulty of factoring the product of two large prime numbers; and Elliptic Curve Cryptography (ECC), which achieves equivalent security with much shorter keys, making it efficient for mobile and IoT devices.

Property	Asymmetric encryption
Keys	A public/private key pair per user
Key distribution	Solved — only public keys are shared; private keys never travel
Speed	Slow — far more computationally expensive than symmetric
Key count for n users	$2n$2n keys (one pair each)
Enables	Digital signatures, as well as confidential exchange

How Asymmetric Encryption Solves Key Distribution

The breakthrough is that the secret key never needs to travel. To receive confidential data, Bob simply publishes his public key; anyone can encrypt with it, but only Bob's private key — which has never left his machine — can decrypt. There is nothing secret in transit for an eavesdropper to capture. Scalability is solved too: each of the $n$n users needs only one key pair ($2n$2n keys total), not a unique shared key with every other user.

The price is speed. Asymmetric algorithms involve heavy mathematics on very large numbers and are typically hundreds of times slower than symmetric ciphers — far too slow to encrypt, say, a large file or a video stream. This speed gap is precisely why real systems do not use asymmetric encryption for the bulk data; they combine the two, as we see next.

---

Hybrid Encryption — The Best of Both

Real-world secure systems use hybrid encryption, marrying the strengths of each method:

1. Asymmetric encryption is used briefly to securely agree a one-time session key (and to authenticate the parties). This solves key distribution.
2. That session key is then used with symmetric encryption for the actual bulk data transfer, because symmetric is fast.

So asymmetric cryptography does the slow-but-secure job of getting a shared key safely into place, and symmetric cryptography does the fast job of protecting the data once the key is agreed. This is exactly how TLS (the protocol behind HTTPS) works, which we walk through in full below. The pattern — asymmetric to establish, symmetric to transfer — is one of the most examinable ideas in the topic, so commit it to memory.

Symmetric vs Asymmetric — Side by Side

Pulling the two methods together clarifies why each is used where it is:

Aspect	Symmetric (private-key)	Asymmetric (public-key)
Keys used	One shared secret key for both operations	A public/private key pair; keys differ
Key distribution	Hard — the secret must somehow be shared safely	Solved — only the public key is shared
Speed	Fast — suited to bulk data	Slow — heavy maths on large numbers
Scalability ($n$n users)	$\frac{n(n-1)}{2}$2n(n−1)​ keys	$2n$2n keys (one pair each)
Can sign / authenticate?	No (no separate keys to prove origin)	Yes — enables digital signatures
Typical role in TLS	Encrypts the bulk session data	Authenticates the server and agrees the session key
Examples	AES, DES, 3DES	RSA, ECC

The crucial reading of this table is that the two methods are complementary, not competing: asymmetric encryption's strength (no key-distribution problem, plus the ability to sign) is symmetric encryption's weakness, while symmetric encryption's strength (speed) is asymmetric encryption's weakness. Hybrid systems like TLS therefore use each for the job it is good at — which is the single most important takeaway of the whole lesson.

---

Hashing — The Foundation of Signatures

Before digital signatures make sense, you need hashing. A cryptographic hash function (e.g. SHA-256) takes input of any size and produces a fixed-length hash value (digest) with three key properties:

• Deterministic — the same input always yields the same hash.
• One-way — you cannot feasibly reverse a hash back to the original data.
• Avalanche / collision-resistant — changing even one bit of the input produces a wildly different hash, and it is infeasible to find two inputs with the same hash.

Hashing is not encryption — there is no key and no way back. Its role here is to produce a small, tamper-evident "fingerprint" of a message: if the message changes by even one character, its hash changes completely, which is exactly the property a digital signature exploits to detect tampering.

---

Digital Signatures — Authentication and Integrity

A digital signature proves two things: that a message genuinely came from a particular sender (authentication, and hence non-repudiation — the sender cannot later deny it), and that it has not been altered in transit (integrity). Note carefully: a signature does not keep the message secret — that is encryption's job. Signing and encrypting are separate operations that can be combined.

The mechanism cleverly combines hashing with the signing mode of asymmetric cryptography:

1. The sender hashes the message (e.g. with SHA-256) to produce a fixed-length digest.
2. The sender encrypts the hash with their own private key — this encrypted hash is the digital signature.
3. The sender transmits the message + signature together.
4. The receiver decrypts the signature with the sender's public key, recovering the original hash (hash A).
5. The receiver independently hashes the received message (hash B).
6. If A = B, the message is authentic (only the sender's private key could have produced a signature their public key reverses) and intact (the recomputed hash matches, so nothing was altered). If they differ, the message was tampered with or did not come from the claimed sender.

flowchart TB
    subgraph SenderSide["Sender"]
      M1["Message"] --> H1["Hash function (SHA-256)"]
      H1 --> HV1["Hash value"]
      HV1 --> ENC["Encrypt hash with SENDER'S PRIVATE key"]
      ENC --> DS["Digital signature"]
    end
    DS --> NET["Message + signature sent together"]
    subgraph ReceiverSide["Receiver"]
      NET --> DS2["Digital signature"]
      DS2 --> DEC["Decrypt with SENDER'S PUBLIC key"]
      DEC --> HA["Hash value A (recovered)"]
      NET --> M2["Received message"]
      M2 --> H2["Hash function (SHA-256)"]
      H2 --> HB["Hash value B (recomputed)"]
      HA --> CMP{"A = B ?"}
      HB --> CMP
      CMP -- "yes" --> OK["Authentic AND unaltered"]
      CMP -- "no" --> FAIL["Tampered, or not from claimed sender"]
    end

Notice the elegant logic. The signature uses the private key to encrypt and the public key to decrypt — the opposite way round to confidential messaging — precisely because the goal is the opposite: not secrecy (anyone can read it, since the public key is public) but proof of origin (only the holder of the private key could have created it). Hashing first, rather than signing the whole message, keeps the operation fast and the signature small, since asymmetric encryption is slow and the hash is short.

Exam Tip: State the key roles precisely. To send a confidential message: encrypt with the recipient's public key, decrypt with the recipient's private key. To sign: encrypt the hash with the sender's private key, verify with the sender's public key. A signature gives authentication and integrity, not confidentiality. Mixing up whose key and which key is the single most common lost mark here.

---

Digital Certificates and Certificate Authorities