Encrypt your data: 5 practical examples

At a glance

Key points

Encryption protects access to readable information when you control the keys. Check device encryption, add a vault for sensitive cloud files and choose an appropriate method for sharing. Always prepare recovery and a backup: making a file unreadable does not prevent its disappearance.

Who can open your files?

A passport scan in a synchronised folder. Family photos on an external drive. A document sent to a relative. We know how to move these files, but less often examine what stops somebody else from opening them.

Encryption transforms readable data into data that needs a key to recover its contents. It does not make the file disappear. It changes the conditions under which it can be read.

The right tool depends on the situation. Protecting a lost laptop is different from concealing a document’s contents from the service storing it. Neither problem, by itself, addresses losing the final copy. Start by separating these needs.

References[1] CNIL: understanding encryption

Passwords, keys and encoding have different jobs

A cryptographic key is a value used by an algorithm. Depending on the software, a password helps derive a key or unlock an existing one. Symmetric encryption uses the same secret for encryption and decryption. Asymmetric systems use public and private keys with complementary roles.

An encoding such as Base64 does not protect a secret: it can be reversed without a secret key. Hashing produces a digest, not an encrypted file you can later decrypt. Do not judge a method by how incomprehensible its output looks.

An algorithm’s name is not enough to evaluate protection either. An AES-256 archive protected by your cat’s name remains vulnerable to password guessing. The software, settings, quality of the secret and where you keep that secret are all parts of the same problem.

References[1] CNIL: understanding encryption [10] 7-Zip: the 7z format and AES-256 encryption [16] CNIL: encryption, hashing and signatures

Four protections covering different parts of the journey

HTTPS uses TLS to protect the connection between your browser and the server it contacts. This does not promise that the server cannot read the information it receives. A provider can also encrypt its drives while holding the keys needed to operate its service.

To choose, ask a precise question: where does the information become readable again, and by whom? The word “encrypted” without that detail leaves out the most important part.

Protection	What it provides and where it stops
HTTPS connection	Protects transport to the server. The technical recipient receives the information.
Disk encryption	Protects against offline access to storage, depending on configuration. An open session is a different context.
Server-side encryption	Protects against some storage access. If the provider holds the keys, it does not exclude its own access.
End-to-end encryption	Places decryption at the intended endpoints. Devices, recipients and backups still need examination.

References[2] MDN: protecting a connection with TLS [5] Microsoft: BitLocker operation and recovery [13] Signal: end-to-end encryption [15] CNIL: cloud encryption and control of keys

Example 1: protect a computer that could be lost

Your laptop disappears on a train. Disk encryption helps prevent someone reading its contents by removing the drive or booting another system. This is not the moment to discover where its recovery key is stored.

On a Mac, open System Settings, Privacy & Security, then FileVault. Macs with Apple silicon or a T2 chip already encrypt their storage; FileVault adds protection tied to user authentication. Check its status and your chosen recovery method. Keep any recovery key somewhere other than only on the drive it unlocks.

On a compatible PC, look under Settings, Privacy & security, Device encryption. This feature is also available on some Windows Home devices. The full BitLocker drive encryption controls are available on editions including Pro. A missing menu alone does not establish the drive’s encryption state.

Before changing protection, verify your backups and access to the BitLocker recovery key. Depending on configuration, it may be held in your Microsoft or organisation account. A hardware change can trigger a recovery request. For a managed computer, consult its administrator instead of changing settings blindly.

References[3] Apple: protect Mac data with FileVault [4] Microsoft: device encryption in Windows [5] Microsoft: BitLocker operation and recovery

Example 2: encrypt a folder before synchronising it

You want to keep personal records in your usual cloud service while adding content protection before upload. Cryptomator creates a local vault containing encrypted files. Your cloud client still handles synchronisation.

Create a vault called “Personal-documents” and start with two unimportant files. Locate the folder containing the encrypted version and the drive that provides access to decrypted files. Once you can identify both locations, move on to your documents.

Create a Cryptomator vault in a folder synchronised by your chosen cloud service.
Choose a unique passphrase and keep the recovery method separately.
Unlock the vault. Copy the two test files into the virtual drive shown by Cryptomator, not directly into its encrypted folders.
Close the documents, lock the vault and let synchronisation finish.
On another compatible device, open the synchronised vault and check that both files are readable with the correct secret.

Understand Cryptomator and its limits

References[6] Cryptomator: creating a vault [7] Cryptomator: accessing vault files

What that operation does not remove from the cloud

Copying an old folder into a vault does not retroactively encrypt previous uploads. Originals may remain in a shared folder, a recycle bin, version history, an attachment or a backup. Make an inventory before deciding what to keep or delete.

Do not delete your only copy just to tidy things up. Check the new vault, its backup and recovery first. Only then manage old copies using the service’s tools. A deletion visible in your interface does not let you personally verify that every provider-side copy disappeared immediately.

Cryptomator also documents observable information, including file sizes, counts and timestamps. Applications can create readable temporary files while you work. The vault protects its stored contents; it is neither an anonymity system nor general protection against malware.

References[9] Cryptomator: security scope and limits

Example 3: send an encrypted archive to a relative

You need to send three documents to someone using Windows. First agree on a tool they can open. In 7-Zip, the 7z format supports AES-256 encryption and an option to encrypt file names. A compressed archive is not automatically an encrypted one.

In 7-Zip, select the copies you want to send, choose Add to archive, select the 7z format, then AES-256 and a unique password in the encryption options. Enable file name encryption too. Give the archive a neutral name: the archive’s own name remains visible.

Before sending, close and reopen the archive to check that it requests the password and contains only the intended documents. If necessary, test with the recipient using a fictional file. Built-in system utilities do not all support the same encrypted formats.

Send the secret through a separate channel to a recipient you know, for example a call to their already saved number. CNIL recommends separating protected information from its secret. Putting the password in the same email as the archive removes much of the benefit against a compromised inbox.

References[10] 7-Zip: the 7z format and AES-256 encryption [11] 7-Zip author Igor Pavlov: file name encryption [12] CNIL: secure file exchanges

Example 4: share directly in an encrypted conversation

For a few documents between people who know each other, an end-to-end encrypted messenger may be simpler than an archive and a separate password. Signal encrypts messages and calls end to end. Still check that the conversation belongs to the intended person before sending.

For a sensitive exchange, compare Signal’s safety number with your contact, ideally by scanning their QR code in person. This checks the conversation’s keys; it does not establish somebody’s civil identity on its own. A change may follow a new phone or reinstallation and is not automatic proof of an attack.

The file is readable on the receiving device. Its owner can save it, take a screenshot or back it up elsewhere. Choose what you share accordingly: if one page is enough, perhaps the whole folder does not belong in the conversation.

Read the Signal overview

References[13] Signal: end-to-end encryption [14] Signal: verifying a safety number

Example 5: restore an encrypted backup

An encrypted drive protects the reading of its contents, not their survival. Hardware failure, deletion or malware can destroy files that are already encrypted. Synchronisation can also propagate a bad modification. By itself, it is not a substitute for a recoverable backup.

For important documents, keep another encrypted copy, for example on an external drive you disconnect after backing up. Depending on your needs, add version history or a further physically separate copy. Think about the keys for each one: encrypting your laptop’s drive does not automatically encrypt everything you copy onto a USB stick.

Try a small exercise: restore a fictional folder from the backup into a new location, open its files and check that you can retrieve the secret without relying on the computer you assume has been lost. This answers a question a “backup successful” label cannot settle: will you be able to recover your data at the wrong moment?

References[9] Cryptomator: security scope and limits

Where should you keep recovery keys?

A recovery key is not an administrative detail. It can open access to the data. Keep it somewhere protected but accessible if your usual device disappears. Avoid circular dependencies: a vault password inside the vault, with the only recovery key stored there too.

In Cryptomator, the recovery key lets you reset the vault password. Changing that password does not renew the keys encrypting the files. An old copy of the masterkey file, together with the old password, may therefore remain useful to an attacker.

If your secret was compromised, examine the software’s appropriate recovery procedure. In this vault scenario, you may need a new vault with fresh keys and a carefully verified migration. Changing a password does not recall old copies or erase material somebody already decrypted.

Prepare account recovery

References[8] Cryptomator: passwords and recovery keys

Start with one device or folder

Choose one concrete need. If you regularly carry your computer, check its encryption and recovery. If sensitive records sit in the cloud, try a vault with two fictional files. If you need to send a folder, first agree on a method with the recipient.

Before encrypting more folders, try reopening this one from your backup. Find the key or password without using the original device. If that fails, fix recovery before extending the setup.

Identify the files and all copies that matter.
Choose suitable protection: device, vault, archive or conversation.
Create a unique secret and prepare recovery.
Test opening and restoring unimportant files.
Keep applications updated and control access to devices.

Frequently asked questions

Practical questions

Does encryption replace a backup?

No. It restricts access without the key, but does not prevent deletion, disk failure or file corruption. Keep an independent copy and try restoring it with the keys you saved.

Cryptomator: security scope and limits ↗

#Link to this answer

Does encrypting files now remove old cloud copies?

No. Unencrypted files may remain in version history, trash, shares or other backups. Check those locations and the service’s retention rules. A new encrypted vault does not remove copies that already existed.

Cryptomator: security scope and limits ↗