Encryption and Secure Deletion

Encryption comes up constantly in this section - VPNs, DNS, email, messaging apps - but it's usually mentioned in passing rather than explained. This article is the explanation: what a public/private key pair actually is, how to encrypt files and drives, why some "encrypted" apps protect you less than you'd assume, and what to do when you actually need to send something sensitive to someone.

Public and private keys, plainly

Most modern encryption (PGP/GPG email, Signal, HTTPS, SSH) is built on a simple idea: instead of one shared secret password both sides need to know, you get a matched pair of keys - one public, one private.

Your public key is meant to be shared with anyone. You can post it, email it, hand it out - it doesn't need to be kept secret. Anyone with your public key can encrypt a message that only your matching private key can decrypt.
Your private key never leaves your device and never gets shared with anyone. It's the only thing that can decrypt what was encrypted with your public key, and it's usually itself protected by a password or passphrase.

This solves the classic problem with a shared password: you never have to transmit the actual secret to anyone, which means it's never sitting in an email or a text message where it could be intercepted. Someone encrypts something for you using your public key; only your private key, which never left your device, can open it.

The one place this breaks down is verification - how do you know the public key you have really belongs to the person you think it does, and not an attacker who substituted their own? That has to be confirmed out-of-band: in person, over a phone call you trust, or by comparing a "fingerprint" (a short hash of the key) through a separate channel than the one you're trying to secure. Skipping this step is the most common way encrypted communication gets quietly defeated - not by breaking the math, but by handing your messages to the wrong key from the start.

The little padlock icon in your browser is this same idea at work. An SSL/TLS certificate is what lets a website use HTTPS - it does two jobs at once: encrypts the traffic between your browser and the site using the same public/private key approach described above, and solves that verification problem by having a trusted Certificate Authority vouch that the site's public key really belongs to the domain it claims to. That's why a certificate warning in your browser matters - it means that second part, the "this key actually belongs to who it says it does" check, just failed.

Encrypting files and drives: VeraCrypt

VeraCrypt is a free, open-source tool for encrypting files, folders, or entire drives. Two ways to use it:

A container - a single file that, once created, acts like a locked box. Mount it with your password and it appears as its own drive letter; unmount it and it's just an unreadable blob of data. Good for keeping a specific set of sensitive files separate from everything else on your machine. It's also just a file - you can rename it, move it, copy it to a USB drive, or upload it to cloud storage like any other file, none of which you can do with an encrypted partition or drive.
Full-disk encryption - encrypts an entire drive or partition, including the operating system itself if you set it up that way. Better for "everything on this device should be protected if it's lost or stolen," since nothing is left in the clear by accident.

VeraCrypt also supports hidden volumes - a second, hidden container tucked inside the free space of an outer, decoy container. Someone who compels you to reveal your password can be given the outer volume's password; the hidden volume inside it remains mathematically undetectable as long as you never write new data to the outer volume after creating the hidden one (doing so risks overwriting the hidden data). This is real plausible deniability, not just obscurity - but it only works if you actually follow that rule.

Worth knowing before you rely on it: hidden volumes are meaningfully harder to keep genuinely hidden on a full partition or physical drive than inside a simple file container. VeraCrypt itself will show a mounted volume's type as "Outer" rather than "Normal" if it was created with a hidden volume inside it - a direct giveaway to anyone who knows to look for that label. There's also the size mismatch you'd actually notice yourself: mount just the outer volume of an encrypted partition or drive, and the size reported next to its drive letter won't match the true size of the underlying partition or disk, since space was reserved for the hidden volume that isn't part of what's mounted. A careful examiner filling the outer volume with data can also work out how much space is "missing" by comparing what they can write against the drive's real capacity. A file container doesn't have this problem the same way, since the container file's own size on disk isn't compared against anything external - which is one more reason a container is usually the more practical choice over encrypting a whole partition or drive when a hidden volume is the point.

One practical step if you are using a partition or physical drive: remove its drive letter entirely (Windows Disk Management, "Change Drive Letter and Paths" - remove it rather than reassign it). Without a drive letter, the partition won't show up in File Explorer or "This PC" at all, which is enough to keep it off a casual observer's radar. It's still fully visible in Disk Management itself to anyone who opens that tool and looks - removing the letter hides it from casual browsing, not from a real search. To mount it in VeraCrypt afterward, use "Select Device" rather than picking a drive letter, since it no longer has one to pick.

WhatsApp vs. Signal: the key-custody gap

Both apps encrypt your messages end-to-end using the same underlying technology (the Signal Protocol) - the message content itself is genuinely protected in transit either way. The difference is what happens to your chat history afterward.

Signal keeps end-to-end encryption for backups too, and doesn't hold the key to your data at all - not for messages in transit, not for anything.

WhatsApp backs up your chat history to Google Drive (Android) or iCloud (iPhone) by default, and unless you specifically turn on WhatsApp's own end-to-end encrypted backup option, those cloud backups are not end-to-end encrypted the way the live chat is - Google or Apple can access them, and so can anyone who legally compels Google or Apple to hand them over. This is a genuinely common and easy-to-miss gap: the conversation itself is protected, the copy of it sitting in your cloud backup may not be, unless you went and turned that setting on yourself.

Your passphrase is the weak link

Nobody breaks VeraCrypt or AES by attacking the math. They get the password: from a sticky note, a notes app, a text file called "passwords", an email, or a camera over your shoulder. So the password habits matter as much as the encryption itself.

Use a passphrase you can remember, not a string you can't. Something like &5y46%88%63784 is so hard to remember that it ends up written down somewhere, which defeats it. Five or six random words strung together - a nonsense sentence - are stronger and easy to remember. Avoid anything that already exists (song lyrics, quotes, sayings); cracking tools have those. Our password tool can generate one.
Don't write it down, and don't store it anywhere digital - not in a note, a document, or an email to yourself. For your ordinary accounts a password manager is the right answer, but the passphrase for your encrypted drive or container is the one thing that belongs in your head.
Know the cost of forgetting. There's no "reset password" for VeraCrypt. Forget the passphrase and the data is gone for good - for you as much as for anyone else. Practice typing it for the first few weeks.

When someone else needs to open the file, give them the passphrase verbally - in person, or over a Signal voice call (an ordinary phone call isn't end-to-end encrypted). Never send it by email, and never over the same route as the file: an encrypted attachment with its password in the same email, or even a second email to the same inbox, hands both to anyone who gets into that inbox. A passphrase made of words has one more advantage here: it can be read out loud in one try, where &5y46%88%63784 can't.

How to actually send someone something sensitive

If you need to get sensitive information to someone else, the right tool depends on whether it's a real-time conversation or a one-off, asynchronous handoff.

Real-time: use Signal. Forward secrecy (compromising one message doesn't expose past or future ones) and minimal metadata retention make it the strongest practical default for an ongoing conversation.

Asynchronous alternatives, and their tradeoffs

A PGP/GPG-encrypted text file, attached to a normal email. Solves the content - the file itself is unreadable without the recipient's private key - but does nothing for metadata. Who emailed whom, when, and the subject line are all still visible to anyone watching either mailbox or the servers in between.
A shared cloud "dead drop" - both parties access the same account/folder instead of emailing each other directly. Real, old tradecraft, but it mostly relocates the metadata problem rather than solving it: if both parties log into the same account, their login times and IPs become the correlatable trail instead of a sender-to-recipient email link (this is literally how the Petraeus affair got exposed). It only works well paired with anonymized access - TOR to reach the drop, from different networks each time. The provider's jurisdiction matters here too: it protects against legal compulsion of the company, but not against an adversary (particularly the user's own government) willing to skip legal process and target the device or ISP directly instead. Treat jurisdiction as one layer, not the whole plan - a zero-knowledge provider (so the company can't read the files even if compelled) matters more than where it's incorporated.
A small VeraCrypt container, sent or uploaded. Best suited to bundling multiple files or needing plausible deniability via a hidden volume - overkill for a single short message, where a PGP-encrypted text file achieves basically the same protection with less friction.

Whichever method, the same rule from the public/private key section applies: none of this matters if the key exchange or shared password was intercepted or verified over an insecure channel to begin with.

Secure deletion

Deleting a file doesn't erase it, and the tools that fix that on an old spinning hard drive (Eraser, DBAN and similar overwrite tools) don't work reliably on the SSD in most modern computers. The approach that works on both is the one this article is about: if the drive was encrypted from the start, deleted files were never sitting there as readable data in the first place. For the full picture - hard drives vs. SSDs, wiping a whole drive properly with ATA Secure Erase or NVMe Sanitize, phones, and the myths - see our Secure Deletion article.

BleachBit is a free, open-source tool for a related but different job: clearing out the accumulated local traces most people don't think about - browser cache and history, temporary files, application logs, and similar clutter. It's general privacy hygiene, not a substitute for encryption or proper deletion.

Shellbags: the Windows history you've probably never heard of

Windows keeps a record, in the registry, of every folder you've ever browsed through File Explorer - including its position and view settings - and that record, known as "shellbags," persists even after the files or folders themselves have been deleted. This applies to folders inside a mounted VeraCrypt volume too: browsing your encrypted container in Explorer can leave a shellbags trail on the host system even though the volume itself is unmounted and unreadable afterward. Clearing shellbags requires a dedicated registry-cleaning step (some general cleanup tools include it); it's not something ordinary file deletion touches at all. To see your own shellbags, NirSoft's free ShellBagsView lists them, and PrivaZer can clear them - both are in the forensic tools section of our Resources page.

Hiding the tools themselves, not just the data

Everything above assumes an adversary who might find your data. Sometimes the tools themselves - a copy of TOR Browser, or a portable app like Psiphon - are what you'd rather not have sitting in plain view on a device. Since both are portable, no-install programs, there's nothing stopping either one from living inside a VeraCrypt container rather than the desktop or Downloads folder. A hidden volume (see above) can mean there's no visible evidence the tools even exist on the device at all.

The honest limit to this: storing the tools encrypted doesn't erase evidence that they ran. Shellbags, prefetch data, and other Windows forensic artifacts can record that a program was launched from a particular mounted drive letter, independent of whether that drive is now unmounted and unreadable. Hiding the source and cleaning up after running it are two different steps - VeraCrypt, shellbags cleanup, and secure deletion are meant to be used together, not as substitutes for one another. To see what your own PC has recorded, before and after cleaning up, try the forensic tools in our Resources.

As with everything in this section: this is about the best available precautions, not a guarantee. Layer them - encrypted storage, careful key exchange, and cleanup after use - rather than relying on any single one alone.

Resources to put this to work

VeraCrypt - free, open-source file/folder/full-disk encryption, containers and hidden volumes.
Gpg4win - free, open-source PGP/GPG suite for Windows, including Kleopatra, a graphical tool for generating your key pair and encrypting/decrypting files without touching a command line.
Signal - free, open-source, end-to-end encrypted messaging with genuinely encrypted backups, our recommended default for real-time sensitive conversation.
Proton Mail (affiliate link) and Proton Drive (affiliate link) - encrypted email and cloud storage from one provider, for when you would rather use a service than encrypt files yourself. See our Email Privacy and Cloud Storage articles for the caveats.
Our Secure Deletion article - which tools to use for deleting files and wiping drives, and why SSDs need different ones.
BleachBit - free, open-source cleanup of cache, temp files, and other local traces.

Last updated 2026-09-26