3.1 Encryption fundamentals

Understanding before trusting

Encryption turns readable information into something that looks like nonsense unless you hold the right key. It is not a magic cloak, but it is the most reliable tool we have for stopping casual and systematic reading of data by people who should not see it.

It is everywhere, quietly: your phone storing photos, your bank's website, messaging apps, the chip in your passport.

What matters is not just that encryption exists, but what it protects, where it protects it and where it cannot help. An encrypted file on a laptop and an encrypted connection to a website are not the same thing, and the difference shapes what can be seen and by whom.

Encryption at rest vs in transit

Encryption at rest protects stored data: a phone's storage, a laptop's disk, a cloud backup, a database. If the device is lost, stolen or seized, it can stop anyone reading the data without the key.

That is why a modern iPhone or Android phone can be safe to carry with years of messages and photos on it: properly locked, its storage is encrypted by default.

Encryption in transit protects data travelling over a network. The padlock you see when logging in to a bank or NHS service means TLS (Transport Layer Security) is encrypting the link between your device and their servers. It stops people on the same Wi-Fi, your internet provider or any network operator in between from reading or altering the contents in flight.

The two complement each other. In-transit encryption does nothing for data once it reaches the server; at-rest encryption does. Take sending a photo by messaging app:

• End-to-end encryption: the photo is encrypted in transit and readable only on the sender's and recipient's devices.
• Transport encryption only: the connection may be secure, but the service can read and store the photo in plain text once it arrives.

Knowing where encryption applies shows you the gaps. Back up your phone to the cloud and your phone's encryption does not automatically cover the backup; that depends on whether the backup is encrypted with a key you control.

Keys, passphrases and entropy

Encryption depends on keys. A key is the secret value that unlocks the data; without it, recovery should be computationally infeasible. Keys can be generated and stored by software, or derived from something you remember, such as a passphrase.

A passphrase is not just a longer password. It is a phrase you can remember with enough unpredictability to resist guessing. That unpredictability is called entropy: more entropy means more possible combinations and longer to crack by brute force.

Myth: a memorable phrase has lots of entropy. Reality: people overestimate it. "Correct Horse Battery Staple" beats "P@ssw0rd1", but only if the words were picked at random, not because they are memorable.

• A short, complex password can still have low entropy if it follows predictable patterns.
• A longer passphrase of random words, or words and numbers, is usually stronger and easier to remember.

Key handling is where most real-world failures happen:

• an encrypted phone seized while unlocked offers no protection;
• a disk encrypted with a weak passphrase can be cracked;
• a shared key on a sticky note defeats the point.

The fix is mostly behaviour and routine: strong device passcodes, a password manager to generate and store long random secrets, and no passphrase reused across services.

There is a trade-off. A passphrase long enough to resist guessing can be a pain to type, so people switch encryption off or pick easy unlocks. The safer path is device features that balance it: biometric unlock backed by a strong passcode, and automatic disk encryption with no manual steps.

Symmetric and public-key encryption

There are two broad families of encryption, and the difference quietly underpins almost everything else in this guide.

Symmetric encryption uses the same key to lock and unlock. It protects an encrypted disk or a password-manager vault: one secret, and whoever holds it can encrypt and decrypt. Fast, simple, and right when only you or a small trusted group need access.

Its limit shows up the moment two strangers need to talk: how do you share that one secret without an eavesdropper grabbing it on the way?

Enter public-key (or asymmetric) encryption, which uses a pair of mathematically linked keys:

• a public key you can publish freely;
• a private key you keep secret.

Anything encrypted with the public key can only be decrypted with the matching private key. Someone scrambles a message using your public key, only your private key can unscramble it, and no secret ever has to be exchanged in advance.

Run the maths the other way and you get digital signatures: your private key proves a message genuinely came from you and was not altered. Abstract? It is the machinery behind the most important protections you use daily.

Almost every system in this guide combines the two:

• Your browser padlock uses public-key cryptography to agree a shared symmetric key for the session, then the faster symmetric encryption for the actual traffic.
• End-to-end encrypted messengers in 7.1 use key pairs on each device, so only the participants hold the private keys. That is precisely why the provider cannot read the contents, and why the protection is so politically contested, as set out in 17.5.
• Passkeys, described in 2.2, are public-key cryptography applied to logging in: your device keeps a private key and proves it holds it without ever revealing it.

You do not need the maths to use any of this. Just remember: the public key is for locking and sharing; the private key is the secret you protect. The rest of the guide gets much clearer.

What encryption does not hide

Encryption protects content, not everything about the communication. Some information stays visible even with strong encryption. This is metadata: who you talk to, when, for how long, and from which device or location.

• Your mobile network still sees which cell tower you connected to.
• Your email provider still sees sender, recipient and, in most cases, the subject line.
• A website still sees your IP address and when you visited.

In the UK this matters because different legal frameworks apply to content and to communications data. You do not need the legal detail to get the practical effect: encryption can keep the message secret without making the activity invisible.

• Worried about casual snooping? Encryption is strong protection.
• Worried that your communication patterns are sensitive in themselves? Add other measures: share less, compartmentalise accounts, or use privacy-enhancing tools that reduce metadata exposure.

Encryption also cannot protect the ends. If your laptop has malware, or your phone is unlocked when searched, the data can be read in plain text. That is not a flaw in encryption; it is a reminder that encryption is one layer in a wider set of security habits.

Common misunderstandings

"If it's encrypted, it's private." Encryption protects confidentiality, not privacy in the broader sense. A service can still collect usage data, device identifiers and behaviour patterns. A fitness app can encrypt the connection yet still record your routes and upload them to a server for analysis. Content protected in transit; activity still stored and potentially shared.

"End-to-end encryption means the service knows nothing." It means the service cannot read message content. It can still see metadata and enforce policies by other means. Many apps keep account details, contact lists or device fingerprints, and some store unencrypted backups unless you turn on extra settings. The fix: check what the service retains, and keep backups encrypted with a key you control.

"My phone is encrypted, so it's safe to hand over." Encryption only helps when the device is locked. Unlocked, or protected by a weak passcode, the data is accessible. In the UK you may also be required to comply with certain legal requests. Whatever the legal context, encryption protects a device at rest, not one in active use.

"Encryption is only for criminals." Day to day it protects ordinary people from fraud, identity theft and accidental disclosure. Banks, hospitals, employers and government services use it precisely because unencrypted data is too easily copied or intercepted. Normal, low-risk use is the dominant case.

"If a company says 'encrypted', the data is safe." The word often hides important details:

• Is it encrypted on your device, or only on their servers?
• Who controls the key?
• Is it encrypted in backups and exports?

Without answers, the promise is incomplete. Look for phrases like "end-to-end encryption" and "keys you control", and treat vague marketing claims with caution.

Encryption is powerful but not absolute. It cuts specific risks and leaves others untouched. Know which layer you are relying on, what it protects and what still needs attention.