Encryption

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.

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: what actually works on a modern computer

Eraser is a free, open-source secure-deletion tool for Windows, still actively maintained. It works by overwriting a deleted file's data on disk multiple times so it can't be recovered the way a normal "delete" can. The important caveat: it doesn't reliably work on SSDs. Modern solid-state drives use wear-leveling, which spreads data across physical cells in ways that defeat traditional overwrite-based deletion, and Eraser has no support for the SSD firmware-level commands that would actually guarantee erasure. Since most current computers run SSDs, full-disk encryption (VeraCrypt, above) is the more reliable modern answer for "make sure this data can't be recovered" - if the whole drive is encrypted, deleted files on it were never recoverable as plaintext in the first place.

If you need to wipe an SSD that was never encrypted - selling it, retiring it, repurposing it - the correct approach isn't a better overwrite tool, it's a completely different command built into the drive itself: ATA Secure Erase for SATA SSDs, or NVMe Sanitize/Format for NVMe drives. These are firmware-level operations that reset every physical cell, including reserved and remapped sectors an overwrite tool can never even see - and because it's a single operation rather than repeated overwrite passes, it's also far easier on the drive's limited write cycles than a traditional multi-pass wipe, which burns through wear for a result that doesn't even work reliably on an SSD in the first place.

• Parted Magic ($15 one-time) - a bootable environment that handles both ATA Secure Erase and NVMe Sanitize/Format with a point-and-click interface, and boots outside Windows so nothing is locking the drive. The standard cross-brand tool for this.
• hdparm - free, Linux command-line, issues the ATA Secure Erase command directly. SATA only - it won't work on an NVMe drive at all.
• nvme-cli - free, Linux command-line, the direct way to issue NVMe Sanitize commands with a verification log.
• Manufacturer tools (Samsung Magician, Crucial Storage Executive, WD Dashboard, Kingston SSD Manager) usually include their own free Secure Erase function for their own drives - worth checking first if you know the brand.

A trap worth knowing by name: DBAN (Darik's Boot and Nuke) and its modern successor ShredOS are also bootable "wipe a drive" tools, and DBAN in particular still gets recommended constantly in older guides as "the" way to wipe a drive. Both are overwrite-based, built for spinning hard drives - the exact same problem as Eraser, just packaged as bootable media instead of Windows software. Don't reach for either one on an SSD.

If what you actually want is a temporary, no-trace working session rather than wiping a drive - browsing or working on a public computer without leaving anything behind - that's a different tool for a different job: see TAILS in our A Safer OS article.

BleachBit is a free, open-source tool for a 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 the encryption or secure-deletion tools above.

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.

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 - this article's sections on VeraCrypt, shellbags, and secure deletion are meant to be used together, not as substitutes for one another.

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.
• Eraser - free, open-source secure file deletion for Windows (remember the SSD caveat above).
• BleachBit - free, open-source cleanup of cache, temp files, and other local traces.