Offered by Dead Brands
How to protect stored and moving data with modern, standards-based encryption: envelope encryption with separated data keys and key-encryption keys, disciplined rotation, encrypted backups, TLS 1.3 ev
Use it over MCP: connect to https://mcp.deadbrands.co/hub/mcp and call skills_get with slug encryption-at-rest-and-in-transit.
# Encryption at Rest and In Transit Credit: SteTy — published free in the Skills Hub How to protect stored and moving data with modern, standards-based encryption: envelope encryption with separated data keys and key-encryption keys, disciplined rotation, encrypted backups, TLS 1.3 everywhere, and the judgment calls between disk-level, database-level, and field-level protection. Everything here is public best practice (NIST SP 800-57, RFC 8446, cloud KMS documentation) — the defensive correct-use patterns every bot that touches data should apply by default. ## Overview Encryption fails operationally far more often than it fails mathematically. AES-256 has never been brute-forced; breaches come from keys stored next to the data, unrotated keys, plaintext backups, and "temporary" unencrypted channels. This skill teaches the architecture that prevents those failures: never encrypt bulk data with a long-lived master key directly — encrypt data with a fresh data encryption key (DEK), encrypt the DEK with a key encryption key (KEK) held in a managed key service, and store only the wrapped DEK beside the ciphertext. Protect data in motion with TLS 1.2+ (prefer 1.3) using AEAD cipher suites and forward secrecy. ## Core Principles - **Use AEAD ciphers.** AES-256-GCM or ChaCha20-Poly1305 give confidentiality *and* integrity. Unauthenticated encryption (AES-CBC without a MAC, AES-CTR alone) lets attackers tamper undetected. - **One DEK per object (or per small batch).** A unique 256-bit DEK per file/record/database limits blast radius: compromise of one DEK exposes one object. - **Separate the KEK from the data.** The KEK lives in a KMS/HSM or dedicated key service with access control and audit logging; it never sits in the same database, disk, or backup as the wrapped DEKs it protects. - **Rotation ≠ re-encryption.** Rotating a KEK means new encryptions use new key material; old KEK versions stay available to unwrap old DEKs. Only DEK rotation (re-encrypting data) changes the data itself — schedule it by data sensitivity, not by calendar panic. - **Encrypt backups with independent keys.** A backup encrypted with the same key, stored in the same account, protected by the same credentials, is not a separate copy — it is the same failure domain. ## Techniques - **Envelope encryption flow:** (1) request a fresh DEK from the KMS (it returns plaintext DEK + wrapped DEK); (2) encrypt data locally with AES-256-GCM, random 96-bit nonce; (3) store ciphertext + wrapped DEK + nonce together; (4) wipe the plaintext DEK from memory; (5) to decrypt, send the wrapped DEK to the KMS, receive the plaintext DEK, decrypt locally. - **Key hierarchy:** root/KEK (in HSM-backed KMS, FIPS 140-3 validated where required) → wrapped DEKs (per object) → optionally per-tenant KEKs so one customer can be crypto-shredded without touching others. - **Crypto-shredding:** to irreversibly delete data across all backups, destroy its DEK/KEK. Ciphertext without the key is noise — this is the only reliable way to "delete" data from immutable backup media. - **Rotation policy:** KEK automatic rotation annually is a common managed-KMS default (AWS KMS rotates customer managed keys every 365 days when enabled); re-wrap or re-encrypt on suspicion of compromise, on personnel changes with key access, and per your data-classification schedule. - **Encryption context / AAD:** bind ciphertext to its purpose with authenticated additional data (e.g., record ID, tenant ID) so a wrapped blob can't be transplanted into another record and decrypted there. - **TLS in transit:** TLS 1.3 (RFC 8446) — 1-RTT handshake, mandatory forward secrecy via ephemeral (EC)DHE, only AEAD suites (TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256). TLS 1.2 acceptable only with ECDHE + AES-GCM/ChaCha20 suites. Disable TLS 1.0/1.1, static RSA key exchange, CBC, RC4, 3DES, SHA-1 signatures. Verify certificates — never `verify=False` in production. - **Choosing the layer:** - *Full-disk / volume encryption* (LUKS, BitLocker, cloud EBS encryption): protects against stolen media only; transparent to everything running. Baseline, never sufficient alone. - *Database / tablespace encryption (TDE):* protects data files and some backups; queries still see plaintext. Good middle layer. - *Field-level / application-level:* encrypt the sensitive columns (PII, tokens) in the application with per-record DEKs. Survives database dump leaks; supports per-tenant keys and crypto-shredding. Costs: no SQL search/sort on ciphertext (use blind indexes — keyed HMAC of the value — for equality lookups). - **Key storage hygiene:** keys come from a secrets manager/KMS at runtime, never in source code, config files committed to git, container images, or unencrypted environment dumps. Scope key permissions per service (least privilege), log every decrypt call, alert on anomalous volume. ## Worked Examples - **Encrypted file store:** user uploads a document → generate DEK → AES-256-GCM encrypt → store blob + wrapped DEK in object storage. Download: KMS unwrap (authorized + logged), decrypt, stream. Losing the storage bucket alone yields nothing readable. - **Backup set:** nightly database backup encrypted with a DEK wrapped by a KEK in a *different* account/region. Quarterly restore drill actually unwraps and restores — an untested backup key is a rumor, not a backup. - **Retiring a tenant:** destroy the tenant's KEK version material in the KMS. All their live data and every backup copy become permanently unreadable without touching the backup media. ## Common Pitfalls - Encrypting data directly with the KMS key on every operation — slow, rate-limited, and forces one key to do every job. Envelope encryption exists precisely to avoid this. - Storing the plaintext DEK (or the KEK) in the same row/volume as the ciphertext. - Rotating a KEK and deleting the old version, orphaning everything wrapped under it. - Reusing a GCM nonce with the same DEK (see the randomness skill — nonce reuse is catastrophic). - Encrypting the primary database but shipping plaintext exports, logs, analytics copies, or support bundles. - TLS present but certificate validation disabled, or internal service-to-service traffic left plaintext "because it's inside the network." - Field-encrypting a column and then indexing/searching it as if it were plaintext. ## Practice Drills 1. Implement envelope encryption for a test file: generate a DEK, AES-256-GCM encrypt, wrap the DEK with a second key, store all three artifacts separately, then decrypt using only the stored artifacts. 2. Rotate the KEK in your drill and prove old files still decrypt while new files use the new version. 3. Crypto-shred one test record and verify every stored copy (including your "backup" copy) is unrecoverable. 4. Scan a practice server with a TLS checker; list every enabled protocol/suite below the bar (TLS <1.2, CBC, static RSA) and disable them. 5. Threat-model exercise: for each copy of a sample dataset (primary, replica, backup, log, export), write down which key protects it and who can use that key. ## When to Use and Limits - **Use it when:** a task calls for encryption at rest and in transit, as laid out in the Techniques and Worked Examples above. - **Watch first for:** (see Common Pitfalls). - **Limits:** this is a general reference drawn from public sources; check exact values against the current standard or vendor docs before relying on them, and get expert review for production security decisions. ## Quick Reference - Cipher: AES-256-GCM (96-bit random nonce, never reused per key) or ChaCha20-Poly1305. - DEK: 256-bit, one per object, generated by the KMS/CSPRNG, wiped after use. - KEK: HSM/KMS-resident, versioned, rotated ~annually, access-logged. - TLS: 1.3 preferred (RFC 8446); 1.2 only with ECDHE + AEAD; forward secrecy mandatory. - Cert keys: RSA ≥2048-bit or ECDSA P-256+; automate renewal (ACME), short lifetimes. - Deletion guarantee = destroy the key (crypto-shredding), not the ciphertext. --- *Trademarks and copyrights mentioned belong to their respective owners. Educational reference only; not affiliated with or endorsed by them.*