3.4 File-level and container encryption

Granularity and portability

Full disk encryption protects a device when it is powered off, but it is a blunt instrument: the whole drive is one protected space. That is fine for everyday laptops and phones.

File-level encryption and encrypted containers add finer control. You protect specific files or groups of files, move them between devices, and decide when they are unlocked.

• File-level encryption: each file is encrypted on its own.
• A container: a single encrypted file that behaves like a virtual disk when unlocked.

Both are about granularity. You can leave personal photos unprotected on a family laptop while encrypting medical records or client contracts separately.

Portability matters too. A container can go on a USB drive or cloud storage and open anywhere you have the passphrase and the right software.

How the encryption actually works

It is worth knowing what these tools do, because the differences between them are real distinctions that affect your safety, not marketing.

Here is what happens when you encrypt a file or create a container:

• Your passphrase is not used directly. It goes through a deliberately slow process called key derivation, which turns a memorable but guessable phrase into a strong key and makes brute-force guessing expensive.
• The data is encrypted with that key using a modern cipher, most commonly AES, often in a mode that also detects tampering.
• Good tools use authenticated encryption, so if someone alters the encrypted file you find out, rather than silently opening corrupted or manipulated data.

The upshot: everything rests on two things, your passphrase and the soundness of the tool.

• A short passphrase undermines even the best cipher. Slow key derivation only buys time; it does not work miracles.
• A poorly implemented or abandoned tool can have weaknesses no passphrase can make up for.

The general principle, that encryption is only as good as its implementation and its key, is covered in 3.1, and it applies with full force here.

For everyday choices, a few established categories cover most needs:

• Cross-platform container tools, of which VeraCrypt is the best known, create the virtual-disk style of container and work across Windows, macOS and Linux.
• Tools designed for cloud storage, such as Cryptomator, encrypt files individually so they sync efficiently rather than as one large blob.
• Simple, modern file-encryption utilities, such as the age tool or long-established options built into archive software, suit encrypting a single file before sending or storing it.
• Built-in operating-system facilities, such as the encrypted disk images on macOS.

Pick based on whether you value portability, cloud compatibility or simplicity. Chosen from reputable sources and kept updated, they all rely on the same underlying ideas.

When full disk encryption is insufficient

Full disk encryption does not help once the device is unlocked. If your laptop is on, anyone with access to it can read whatever the system can read. That is not a flaw; it is the design. The moment you log in, the drive is decrypted for use.

File-level encryption keeps chosen data locked while the rest of the device is in use. For example:

• A solicitor keeps case notes in an encrypted container, so routine admin can happen without exposing sensitive files.
• A student in shared accommodation keeps passports and banking PDFs in an encrypted folder, while lecture notes stay accessible.

Shared devices are another classic case. Family computers in the UK often have several users, and not everyone logs out properly. Full disk encryption will not stop a logged-in sibling opening someone else's files if permissions are loose. Encrypting the files themselves adds a layer that does not depend on who is signed in.

Encrypted containers and naming risks

A container is a single file, often with a generic extension, that holds encrypted content and appears as a new drive or folder when unlocked. Tidy and portable, but its very presence can signal that something is being hidden.

A file called "Encrypted Tax Records" on a shared drive is effectively an index to your most private material.

The risk here is not cryptographic weakness. It is social and operational. If someone is curious or under pressure, a clearly labelled container invites scrutiny, and in some situations merely revealing that you use encryption changes how people treat you.

The mitigations are simple:

• Use neutral names. "Archive 2024" attracts less attention than "Sensitive Evidence".
• Remember the filename is often visible even when the container is locked.

For people who need plausible deniability, some tools offer hidden volumes. They are complicated to use correctly and can create their own risks if mishandled or if your usage patterns are inconsistent.

Storage locations and access patterns

Where you store encrypted files matters as much as how you encrypt them. A container in a cloud sync folder such as OneDrive or iCloud is protected at rest, but metadata is still visible:

• file size;
• file name;
• the fact that it changes regularly.

That can be enough for a curious employer, partner or service provider to infer what you are doing.

Access patterns can leak even when the contents are secure. A container that grows while you work on a specific project, or is opened every evening after a meeting, tells a story through timing. This matters more where oversight is routine: workplaces with device monitoring, or shared family computers with well-meaning but intrusive parents.

The practical fix is to separate storage from day-to-day activity:

• Keep a container on removable storage for genuinely private material, and copy it to a local drive only when needed.
• If you use cloud storage, treat it as transport, not a working directory. Open the container, copy out the file you need, work on it locally, put it back and close the container.

That cuts how often the container updates and how much metadata you expose.

Keys, passphrases, and the risk of losing access

The most common harm from file-level encryption is locking yourself out, not an adversary breaking in. Strong encryption is unforgiving by design: no helpline, no reset link, no recovery short of the passphrase or key you set.

Forget it, and the data is gone as surely as if the drive had been destroyed. That is the protection working as intended, so key management deserves as much thought as the encryption itself.

Two failure modes dominate:

• Forgetting a passphrase you chose under pressure and never wrote down. For any container holding something you cannot afford to lose, record the passphrase somewhere trustworthy, such as the password manager in 2.2, not only in your head.
• Having exactly one copy. If that single file is corrupted, lost or on a drive that fails, no passphrase will help.

Encryption protects confidentiality, not availability. It must sit alongside a backup strategy, not replace one.

The sensible discipline:

• Keep at least one additional, separately stored copy of any important encrypted container.
• Test that you can actually open your backups now and then, rather than assuming it will work.
• If your tool supports a recovery key or keyfile as well as a passphrase, treat it as seriously as the data it unlocks. Anyone who gets it has the same access you do.

Balancing loss against exposure is the heart of getting this right. Protection so tight you lose your own data has failed you just as badly as protection that is too loose.

Avoiding "sensitive data" signals

Myth: encryption itself keeps you clear of suspicion. Reality: how you use encryption can be as visible as the data it protects. A folder of encrypted files called "Legal Strategy" is not subtle. Nor is a USB stick permanently on a keychain labelled "Private".

Avoiding signals is not about hiding wrongdoing. It is about avoiding unnecessary attention. In the UK, lawful inspection of devices at borders or workplaces can involve questions about why certain files are protected. You do not have to assume hostile intent to recognise that humans respond to cues.

A balanced approach: make encryption part of normal routine, using it for mundane tasks as well as sensitive ones so encrypted items do not stand out. For example, keep your archive of receipts and household documents in the same container as a few genuinely private files. The container becomes an ordinary admin tool, not a special vault.

There are limits. If you carry a single encrypted container and refuse to unlock it, that is a choice with consequences. The risk cannot be eliminated, only managed. For many people the realistic goal is to keep sensitive data protected while avoiding obvious flags that invite curiosity or escalate attention.