Encrypting a secret means turning it into a string of characters that is unreadable for anyone who does not hold the key. A password, an access token or an API key must be encrypted at two moments: when it sits on a disk (at rest) and when it travels over the network (in transit). The delicate point is elsewhere: where do you keep the key that unlocks everything? The professional answer is called envelope encryption, backed by a hardware safe that never lets its master key leave. This page defines each term without assuming any prerequisite, to understand how a secret is really protected.
What you will learn
Encryption looks magical from afar, but it rests on a few simple ideas that anyone can grasp. Concretely, you will be able to:
- Tell apart encryption at rest (on storage) from encryption in transit (on the network).
- Explain envelope encryption, with its data key and its master key, and why this double layer is safer.
- Understand the role of the HSM and the KMS, these guardians of the master key that never let it out.
- Spot the value of encryption as a service, which avoids handing the key to applications.
- Avoid classic mistakes such as keeping the key next to the data it protects.
- Connect this subject to the secret lifecycle and to the threats that weigh on secrets (in French), which show when and why this encryption matters.
Why encrypt secrets?
A secret is data that gives access or power: a password, an authentication token, a private key, a database connection string. If an attacker gets hold of it, they obtain the same rights as you. Encryption is the barrier that makes this theft useless: even stolen, an encrypted secret stays a worthless string of characters as long as the attacker does not have the matching key.
The diagram below sums up upfront the answer this page develops: the data is encrypted by a data key, itself encrypted by a master key that never leaves its HSM or its KMS. Read it from left to right, each arrow adding a layer of protection.
A secret is vulnerable in two different places, and it must be protected in both. The first is at rest: when the secret is stored somewhere, on a hard disk, in a database, in a configuration file or on a backup. Encryption at rest guarantees that someone who steals the disk or copies the file reads nothing exploitable in it. Without it, a lost backup or a discarded disk becomes a leak of secrets.
The second place is in transit: when the secret travels over the network, between your browser and a site, between an application and its database, between two services. Encryption in transit prevents a spy placed on the path from reading what goes through. The standard tool is called TLS (Transport Layer Security), the protocol that sets up an encrypted tunnel between two machines. It is what turns http into https and shows the padlock in your browser.
These two protections are complementary, never interchangeable. A secret encrypted on the disk but sent in clear over the network can still be intercepted. A secret protected by TLS during its journey but stored in clear on arrival can still be stolen from the server. A well-protected secret is protected on both sides, from storage to the network.
What is envelope encryption?
Once you want to encrypt, an awkward question comes up: you need a key to encrypt, but then where do you keep that key? If you put it next to the encrypted data, the attacker who steals one steals the other, and the encryption served no purpose. Envelope encryption solves this puzzle by stacking two levels of keys.
The idea is to nest two keys like a letter in an envelope. The data key (often written DEK, for Data Encryption Key) is the key that actually encrypts the secret, or more often a large volume of data. The master key (often written KEK, for Key Encryption Key) does not encrypt the data itself: it only encrypts the data key. You then store the encrypted secret and its encrypted data key side by side, without risk, because the data key is itself unusable without the master key.
Why not encrypt everything directly with the master key, which would be simpler? For several practical reasons. First, the master key is precious and well guarded: you want to make it work as little as possible and expose it as rarely as possible. Next, you can generate a different data key for each file, each database or each secret, which limits the damage if one leaks. Finally, to change the master key (a recommended security operation), you only need to re-encrypt the small data keys, not terabytes of secrets. The double envelope brings flexibility without sacrificing security.
That leaves the heart of the problem: where does the master key live? The right answer is a component designed never to let it out. An HSM (Hardware Security Module) is a hardened physical box that generates and keeps keys inside its enclosure. You send it a data key to decrypt, it decrypts it inside and returns the result, but the master key never leaves the box. Even the administrator cannot extract it. A KMS (Key Management Service) is the service, often offered by a hosting provider or a piece of software, that drives all this: it creates keys, manages their authorisations, sits on top of an HSM and offers a clean interface to encrypt and decrypt without ever handling the master key yourself.
What is encryption as a service?
Envelope encryption settles where the master key is kept, but a risk remains in applications. Traditionally, to encrypt data, a program must fetch a key into memory, use it, then hope to erase it properly. In the meantime, the key lingers in the process, vulnerable to a memory leak, a too-chatty log or a crash dump. Multiply this by dozens of applications and you have as many places where a key can escape.
Encryption as a service reverses the logic: instead of giving the key to the application, you take the key away and offer it a service that encrypts and decrypts for it. The application sends data to a central service saying "encrypt this for me" or "decrypt this for me", and gets the result back. The key stays with the service, never in the application. The program does its job without ever seeing, storing or handling a single key.
This model brings three concrete benefits. First, the exposure surface shrinks: the key lives in a single protected place rather than duplicated in every application. Next, key rotation (replacing them regularly) becomes centralised and transparent, without touching the applications' code. Finally, you can log every encryption operation in the same place, which gives a valuable trace in case of an incident. HashiCorp Vault offers exactly this mechanism under the name transit engine: applications delegate encryption to it without ever holding the key.
How do you put it into practice?
Understanding these concepts is one thing, applying them is another, and you do not have to build everything yourself. The most widespread building block in the ecosystem is a secrets vault coupled with an encryption service. The HashiCorp Vault guide shows how to delegate encryption and decryption to a central service through its transit engine, exactly following the encryption-as-a-service model described above: your applications never hold the key.
For the storage of the secrets themselves, centralising them in a vault is the first reflex to adopt even before talking about algorithms. The overview page on secrets management presents the available tools and how to choose. A vault applies envelope encryption for you, manages authorisations and traces accesses, which spares you from reinventing a fragile mechanism by hand. When the secrets must live in a Git repository, SOPS encrypts the values while leaving the structure of the file readable.
What pitfalls should you avoid?
Encryption gives a feeling of security that can be misleading. A few mistakes come back again and again and drain the protection of its substance without anyone noticing.
Pitfall number one is storing the key with the data it protects. A key written in a configuration file versioned next to the encrypted database, a key slipped into an environment variable readable by everyone, a key committed by mistake in a Git repository: in all these cases, the attacker who obtains the data also obtains the key, and the encryption becomes decorative. The key must always live elsewhere, in a vault or a dedicated service, out of reach of whoever accesses the data.
The second pitfall is to never change the key. A key that encrypts the same data for years ends up leaking, through a lost backup, an employee leaving or a forgotten flaw. Key rotation consists in replacing keys periodically and re-encrypting what they protected. Envelope encryption makes this operation affordable, since you only re-encrypt the small data keys. Not renewing your keys means leaving a door whose lock you handed out for too long.
The third pitfall is to confuse encryption and access management. Encrypting guarantees that a stolen secret stays unreadable, but says nothing about who has the right to ask for its decryption. A service that decrypts for any caller without checking its identity protects poorly, however strong its encryption. The two layers, encryption and rights control, must hold together.
Key points
-
Two moments to protect: a secret is encrypted at rest (on storage) and in transit (on the network, via TLS), never one without the other.
-
The real problem is the key: encrypting is easy, keeping the key safe is the real difficulty.
-
Envelope encryption: a data key (DEK) encrypts the secret, a master key (KEK) encrypts the data key, which brings flexibility and security.
-
The master key never leaves: an HSM (hardware box) or a KMS (management service) generates and keeps the master key without ever letting it escape.
-
Encryption as a service: delegating encryption to a central service avoids handing the key to applications, which never hold it.
-
Never the key next to the data: a key stored with what it protects cancels all the benefit, and a key never renewed ends up leaking.
-
Move on to practice: the reference framework requires never leaving a secret in clear text and entrusting it to a safe vault (SOCLE-SEC-GEN-2); the threat model for secrets (in French) shows which attacks this encryption blocks.
Knowledge check
Check that the essentials of this lesson are in place. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: HashiCorp Vault: manage your secrets securely
A new full quiz with random questions
Work again only on the questions you missed