An organization can encrypt every disk it owns and still leave a serious gap if the same records travel across a network without protection. It can also secure a connection and leave a database copy readable to anyone who can access the underlying files. The source article’s central point is that data has more than one exposure boundary. The practical job is to match a control to the moment an attacker might reach it, then decide who is allowed to use the key.
Encryption (turning readable information into a form that requires a key to read) changes what possession of a device or a captured connection can reveal. The article calls the readable form plaintext and the protected form ciphertext. That distinction is useful, but it is not the whole security plan: the source also notes that an unlocked system can expose data to users or applications that already have permission to read it.
A stolen device and a tapped connection are different problems
Data at rest (information stored on a device or in a database) and data in transit (information moving between systems) face different paths to exposure. The source lists hard drives, backups, object storage, and removable media as storage examples. For traffic, it names browsers connecting to web servers, application services exchanging calls, database replication, file transfers, and email.
A full-disk control addresses the case where someone obtains the storage medium. The article describes LUKS (Linux Unified Key Setup, a format for managing encrypted disk volumes) with dm-crypt (the Linux disk-encryption layer) as a common Linux approach. It says LUKS can encrypt a disk or partition and describes up to eight key slots for separate passphrases or key files. That is the source’s feature description; the operational decision is whether the people responsible can protect and recover the credentials they choose to use.
A network connection needs a different control. TLS (Transport Layer Security, the protocol used to protect network sessions) is the source’s example for web and application traffic. It describes OpenSSL as a cryptography library and toolkit used by web servers and applications to provide encrypted channels. Let’s Encrypt and Certbot appear as a way to obtain and renew certificates, with the article stating that certificates expire after 90 days. That automation can reduce a recurring administrative burden, but the source’s point is not that a certificate alone protects every path through an application.
The same boundary-based view helps sort other tools the source names. These examples are not interchangeable:
- Web sessions. The article recommends TLS 1.3 with OpenSSL for network traffic and describes Let’s Encrypt with Certbot for certificate issuance and renewal.
- Remote access. OpenSSH is the source’s example for encrypted shell sessions and file transfers; it also describes port forwarding for applications that do not speak TLS themselves.
- Private network links. The article contrasts WireGuard, which it describes as lightweight, with OpenVPN, which it says supports more platforms.
- Portable files. GPG (GNU Privacy Guard, an OpenPGP implementation) and Age (a simpler command-line file-encryption tool, as described in the source) address files rather than whole disks.
- Database fields. The PostgreSQL pgcrypto extension is named for column-level encryption, while the article also discusses encrypting sensitive fields in the application before they reach the database.
A tool list is useful only after the exposure point is clear. Buying or installing a product because its name appears in a comparison table does not answer whether it covers the path that matters.
Encryption changes when the system is unlocked
The source makes an important distinction that often disappears from simplified security advice. Disk encryption protects the raw storage while the device is locked or disconnected, but the guide says that once the operating system has loaded and the disk is unlocked, permitted users and applications can read the files. That means full-disk protection and access control answer different questions.
File-level encryption can add another boundary. The source describes GPG’s hybrid approach: the data is encrypted with a symmetric key, and that key is protected with the recipient’s public key. It also says GPG supports digital signatures. Age is presented as a simpler option for file encryption and automated backup workflows. The choice between them should be based on who needs to exchange files and how they will manage the corresponding keys, not on a label like modern or traditional.
For database records, the source names pgcrypto for encrypting selected columns and describes application-layer encryption before sensitive fields are submitted to the database. It argues that this can keep plaintext away from database administrators or backup operators. That is a design claim in the source, not a guarantee about every deployment. A team considering it needs to decide how applications obtain keys and what happens when the data must be read or restored.
VeraCrypt (a cross-platform tool for encrypted disks and file containers, according to the source) addresses yet another shape: a file that can be mounted as a virtual disk and moved between operating systems. The article also describes hidden volumes as a feature. That is a specific use case, not a substitute for deciding which people should have access to the container and where its key material lives.
The key path is part of the data path
The source describes key management as the point where encryption projects often fail. It warns against hard-coding a key into a program, checking it into Git, or keeping it next to the data it protects. Those examples share one problem: the barrier that is meant to separate data from unauthorized access can disappear if the key travels with the ciphertext.
HashiCorp Vault appears in the source’s comparison as a system for secrets and key lifecycle, including centralized storage and audit logging. The article names it as one possible category of tool, not a universal requirement. A small organization still needs a written answer to the basic questions: which person or service can access a key, where it is stored, and who can recover it when the usual administrator is unavailable.
This is also why a tool that encrypts data automatically is not automatically a complete control. The source lists certificates, VPNs, disk encryption, file encryption, and database functions, but each one leaves a different operational task behind. A renewal process must be monitored. A recovery key must remain usable without being stored beside the device. A file recipient must receive the right key without making it public. These are practical checks, not claims that a particular product handles them for every organization.
Build the plan around the records you have
An organization does not need to deploy every tool in the article at once. A useful first pass is to name the records, identify where they live and move, and then assign one control to each boundary. Keep the review small enough that someone can own it.
- List sensitive records. The source calls out customer passwords, patient medical records, and financial information as examples worth protecting.
- Mark storage locations. Include laptops, database files, backups, and removable drives, which the article identifies as data-at-rest locations.
- Map network paths. Record which applications, services, and transfers move the information between systems.
- Assign a control. Choose a disk, file, database, or transport mechanism that matches the exposure point.
- Name the key owner. Decide who can retrieve, rotate, or recover the key, and where those actions are documented.
That checklist is editorial advice built from the source’s categories. It avoids pretending that an organization can make an encryption plan by copying a list of tool names. It also gives a team a way to notice a missing boundary before purchasing another layer.
Trade-offs
Encryption reduces what an intruder can learn from data they can reach, but it moves responsibility toward the keys. The source explicitly warns that a key stored with the data or inside the source code can undermine the protection. It also describes different operating burdens: certificate renewal, VPN configuration, full-disk recovery, file exchange, and database access are not the same task.
There is no one-tool shortcut in the article. A disk volume does not replace TLS for traffic. A TLS session does not encrypt a database dump at rest. File encryption does not decide who should receive a key. My recommendation is to accept the extra key-management work only where the data and exposure justify it, then document who owns that work. If nobody can maintain or recover a control, the label on the tool will not make the system safer in practice.
Bottom line
Start with the path an attacker could take, not the product catalog. Protect stored data, moving data, and sensitive fields with controls designed for those boundaries, then treat key custody as part of the design. Encryption can make a stolen copy less useful. The people and processes around its keys determine whether that protection holds when the system is in use.