Encrypting Data with the Transit Secrets Engine

In this guide, you’ll learn how Vault’s Transit Secrets Engine centralizes encryption operations, removes the burden of key management from application teams, and provides a consistent API for data protection.

Encryption Challenges in the Enterprise

Consider a typical three-tier application flow: web tier → app tier → database tier. When data (for example, name, credit card number, expiration date, date of birth) is stored in clear text, any compromise of a tier exposes sensitive information.

The image illustrates a flow of data from the web tier to the app tier and then to a database, highlighting encryption in the enterprise. A character with sunglasses comments, "Yes! Encrypted in Much Better!"

Teams typically address this in one of two ways:

Use the database’s built-in encryption.
Integrate an external crypto library or SDK in the app tier.

The image illustrates options for encrypting data in an enterprise, highlighting two methods: relying on database capabilities and using an external solution or library. It includes visual elements like code symbols, a database icon, and text labels.

Limitations of Database Encryption

High-performance stores like Cassandra often lack advanced encryption capabilities, forcing teams to choose legacy platforms (e.g., MSSQL) solely for encryption support.

The image discusses encryption issues in enterprise database selection, comparing Cassandra as an ideal database with MSSQL as the required choice due to its encryption capabilities.

Drawbacks of Custom Libraries

When each team picks its own solution—OpenSSL, Go's crypto, .NET libraries, in-house code, or tools like Voltage—you end up with:

Multiple custom implementations
Inconsistent security practices
Fragmented audit and compliance

Warning

Decentralized encryption makes it hard to enforce policies, rotate keys, and audit usage.

The image illustrates the challenges of encryption in enterprises, highlighting different teams using various encryption technologies like OpenSSL, Golang, .NET, internally developed solutions, and Voltage.

Introducing the Transit Secrets Engine

Vault’s Transit Secrets Engine provides a centralized encryption service. Applications send plaintext to Vault, request encryption, and store the returned ciphertext wherever they choose. Vault never persists the encrypted data.

The image illustrates a solution using Vault's Transit Secrets Engine, showing a process where cleartext data is sent, encrypted into ciphertext, and then stored. It includes icons representing data flow and storage, with a character in the bottom right corner.

All your services simply point to Vault:

The image illustrates a solution for centralizing an organization's encryption needs, featuring colorful code icons with arrows pointing towards a central "TRANSIT" symbol.

How It Works

Vault exposes simple API endpoints under /transit:

Authenticate and obtain a token scoped to specific keys.
Encrypt: send Base64-encoded plaintext to /transit/encrypt/<key> → receive ciphertext.
Store ciphertext in any datastore (database, object store, etc.).
Decrypt: send ciphertext to /transit/decrypt/<key> → receive Base64 plaintext.

The image is a slide titled "Intro to Transit Secrets Engine," explaining how the engine provides encryption and decryption functions, allowing applications to send cleartext data to Vault for encryption, with the encryption key stored securely in Vault.

Note

Vault’s Transit engine does not store ciphertext—it simply encrypts or decrypts and returns the result.

Key Management and Rotation

Vault manages your keys and their versions:

Secure storage: Keys live only in Vault.
Versioning: Rotate keys by adding new versions to the key ring.
Backward compatibility: Old versions remain available to decrypt legacy data.
Access control: Enforce version-based decryption limits (e.g., only allow versions ≥ 3).

The image is a slide titled "Intro to Transit Secrets Engine," explaining how encryption keys are created, stored, and managed in a Vault, including key rotation and permission requirements.

Re-wrapping Ciphertext

To upgrade ciphertext to the latest key version without exposing plaintext:

Call /transit/rewrap/<key> with existing ciphertext.
Vault returns new ciphertext using the current key version.

Application-Specific Keys

Assign each service its own encryption key. Your token policy can grant only the necessary operations:

A customer-facing service might have encrypt permissions only.
A billing service could have both encrypt and decrypt permissions.

The image is an infographic titled "Intro to Transit Secrets Engine," showing a process where applications send vault requests to obtain encryption keys, resulting in ciphertext. It includes colorful icons and text, with a character illustration in the bottom right corner.

Supported Key Types

Vault supports a variety of key algorithms. By default, it uses aes256-gcm96. Choose according to your security requirements:

Key Type	Use Case
aes256-gcm96	Default: AES-GCM with 96-bit nonce
chacha20-poly1305	ChaCha20-Poly1305
ed25519	EdDSA signatures
ecdsa-p256	ECDSA P-256 signing
rsa-2048	RSA encryption/signing with 2048-bit modulus

The image is a table listing different encryption key types along with their descriptions, including AES, ChaCha20, Ed25519, ECDSA, and RSA. The table highlights "aes256-gcm96" as the default key type.

Convergent Encryption Mode

Enable convergent encryption to ensure that encrypting the same plaintext with the same key always yields identical ciphertext. This feature is useful for searchable encryption but requires supported key types like AES-GCM or ChaCha20-Poly1305.

Base64 Encoding Requirement

All plaintext sent to Transit must be Base64 encoded to support arbitrary binary data (PDFs, images, etc.). Remember, Base64 is reversible encoding, not encryption.

For a hands-on experience, try the lab to enable Transit, create keys, and perform encrypt, decrypt, and rewrap operations.

Watch Video

Watch video content