AES-256-GCM Encryption for Estate Planning: Why It Matters

When you store your digital will --- the passwords, documents, instructions, and access credentials your family needs after you are gone --- the encryption protecting that data is not an academic concern. It is the single technical decision that determines whether your most sensitive information remains private until it is needed and whether your beneficiaries can trust that it has not been tampered with.

AES-256-GCM is the encryption standard used by Burning Ash Protocol to protect digital wills. This article explains what AES-256-GCM is, why it was chosen over alternatives, how it works in the context of estate planning, and what pitfalls exist in other approaches.

What AES-256-GCM Actually Is

AES-256-GCM combines two cryptographic operations into one: encryption (confidentiality) and authentication (integrity verification). Let's break down each component.

AES (Advanced Encryption Standard) is a symmetric-key block cipher adopted by the U.S. National Institute of Standards and Technology (NIST) in 2001. It operates on 128-bit blocks of data and supports key sizes of 128, 192, or 256 bits. AES-256 uses a 256-bit key, which means there are 2^256 possible keys --- a number so large that brute-force attacks are computationally infeasible with any known or foreseeable technology.

GCM (Galois/Counter Mode) is a mode of operation for block ciphers. AES by itself only encrypts a single 128-bit block. To encrypt larger data, you need a mode that defines how to chain multiple block encryptions together. GCM does this using counter mode (CTR) for encryption and a Galois field multiplication for authentication.

The combination --- AES-256-GCM --- is an Authenticated Encryption with Associated Data (AEAD) scheme. This means it provides three guarantees simultaneously:

1. Confidentiality: The encrypted data cannot be read without the key.
2. Integrity: Any modification to the ciphertext is detected.
3. Authenticity: The data provably came from someone who holds the key.

Why Authenticated Encryption Matters for Digital Wills

Many encryption implementations focus exclusively on confidentiality --- keeping data secret. For a digital will, this is necessary but not sufficient. Here is why.

The Tampering Problem

Imagine your digital will contains instructions for your family: account numbers, passwords, and directions for handling your affairs. If an attacker cannot read the encrypted will, they might still be able to modify it. With some encryption modes (notably CBC), it is possible to make targeted, predictable changes to the plaintext by flipping bits in the ciphertext. This is not theoretical --- it is a well-documented class of attacks.

An attacker who can modify your encrypted will could change an account number, redirect assets, or alter instructions. Without authentication, your beneficiaries would decrypt the modified will and have no way to know it had been changed.

AES-256-GCM prevents this. Every encryption operation produces an authentication tag --- a cryptographic checksum that covers both the encrypted data and any associated metadata (like the will's ID or creation timestamp). During decryption, the tag is verified first. If even a single bit of the ciphertext or associated data has been modified, decryption fails entirely rather than producing corrupted output.

The Silent Corruption Problem

Data stored for long periods --- which is the nature of a digital will --- is subject to bit rot, storage errors, and undetected corruption. With unauthenticated encryption, corrupted ciphertext decrypts to garbage without any error indication. Your beneficiaries would see nonsensical output and have no way to distinguish corruption from tampering.

GCM's authentication tag catches both deliberate tampering and accidental corruption, failing loudly rather than silently.

The Key Confirmation Problem

When your beneficiaries attempt to decrypt your will using a reconstructed key, authenticated encryption provides immediate feedback on whether the key is correct. With GCM, a wrong key produces an authentication failure, not garbled output. This is particularly important in threshold recovery scenarios where multiple key shares are combined --- the authentication tag confirms that the reconstruction was successful.

How BAP Implements AES-256-GCM

Burning Ash Protocol's encryption architecture uses AES-256-GCM as the foundation of a layered key management system.

The Key Hierarchy

BAP uses a three-tier key hierarchy:

1. Master Key: A 256-bit key stored as an environment variable on the server. This key never encrypts will data directly.
2. Data Encryption Keys (DEKs): Each will has its own unique DEK, generated with a cryptographically secure random number generator. The DEK is encrypted by the Master Key using AES-256-GCM and stored in the database.
3. Will Data: Documents and messages are encrypted with the will's DEK using AES-256-GCM.

This hierarchy exists for two reasons. First, it limits the blast radius of a key compromise --- if a single DEK is exposed, only one will is affected. Second, it enables key rotation at the master level without re-encrypting every document.

Nonce Management

AES-256-GCM requires a unique nonce (number used once) for every encryption operation with the same key. Reusing a nonce with the same key is catastrophic --- it allows an attacker to recover the authentication key and potentially decrypt data.

BAP generates a random 96-bit nonce for each encryption operation using Go's crypto/rand package. The nonce is prepended to the ciphertext, so it is available for decryption without separate storage. Given that the probability of a 96-bit random collision is negligible for any practical number of encryptions (well under the 2^32 limit recommended by NIST for random nonces), this approach is both safe and simple.

Shamir's Secret Sharing Integration

When the Will Transfer Protocol triggers, the will's DEK is not sent to a single Survivor. Instead, BAP splits the DEK using Shamir's Secret Sharing into N shares, distributed across N Survivors. A configurable threshold K of those shares is required to reconstruct the DEK.

This means the DEK exists in its complete form only in two places: encrypted in the database (protected by the Master Key) and temporarily in memory during the split/reconstruct operation. No single Survivor ever possesses the full key.

The combination of AES-256-GCM and Shamir's Secret Sharing provides defense in depth:

• AES-256-GCM protects the data at rest and verifies its integrity
• Shamir's threshold prevents any single point of compromise from exposing the key
• The master key adds an additional encryption layer around the DEK itself

Common Encryption Pitfalls in Estate Planning Tools

Understanding why AES-256-GCM is the right choice requires examining what can go wrong with alternatives.

AES-CBC Without HMAC

AES-CBC (Cipher Block Chaining) provides confidentiality but not authentication. Several digital will and dead man's switch tools use AES-256-CBC for encryption. Without a separate HMAC (Hash-based Message Authentication Code) step, CBC-encrypted data is vulnerable to:

• Padding oracle attacks: An attacker who can observe whether decryption succeeds or fails can iteratively recover the plaintext byte by byte
• Bit-flipping attacks: Targeted modifications to ciphertext produce predictable changes in the decrypted plaintext
• Silent corruption: Corrupted ciphertext decrypts to garbage without error

Adding HMAC to CBC (the Encrypt-then-MAC pattern) can achieve authenticated encryption, but the implementation is error-prone. The encrypt and authenticate operations must be correctly ordered (encrypt first, then MAC the ciphertext), the MAC must cover the IV, and the MAC verification must be constant-time to prevent timing attacks. GCM avoids all of these implementation hazards by combining encryption and authentication in a single, standardized operation.

Relying on Application-Layer Encryption

Some tools encrypt data at the application layer using high-level libraries without attention to key management. Common issues include:

• Hardcoded or derived keys: The encryption key is derived from a password or stored in a configuration file alongside the encrypted data
• Key and data colocation: The encryption key is stored on the same server as the encrypted data, so a server compromise exposes both
• No key rotation: The same key encrypts all data forever, increasing the impact of a key compromise

Encryption Without Key Management

Encryption is only as strong as the key management surrounding it. A perfectly implemented AES-256-GCM encryption is worthless if the key is stored in plaintext in a configuration file that gets committed to a Git repository or backed up to an unencrypted cloud drive.

BAP addresses this by separating the Master Key (environment variable, provided at runtime) from the DEKs (encrypted in the database) from the will data (encrypted with the DEKs). Compromising any single layer does not expose the will contents.

Performance Characteristics

AES-256-GCM is fast. On modern hardware with AES-NI instruction set support (which includes virtually all x86 processors manufactured after 2010 and most ARM processors since ARMv8), AES-256-GCM achieves throughput of several gigabytes per second.

For a digital will application, this means encryption and decryption are never a bottleneck. Even large documents encrypt in milliseconds. The authentication tag computation adds negligible overhead compared to encryption alone.

This performance profile is relevant for the user experience during both will creation (when documents are encrypted and stored) and will recovery (when Survivors reconstruct the key and decrypt the documents).

AES-256-GCM in Industry Context

AES-256-GCM is not an exotic or unusual choice. It is the encryption standard used by:

• TLS 1.3: The protocol that encrypts virtually all web traffic uses AES-256-GCM as one of its two mandatory cipher suites
• Google Cloud, AWS, Azure: All three major cloud providers use AES-256-GCM for their envelope encryption (the same pattern BAP uses with Master Key and DEKs)
• Signal Protocol: The end-to-end encrypted messaging protocol uses AES-256-GCM for message encryption
• IPsec/IKEv2: VPN protocols use AES-GCM for both encryption and authentication

Choosing AES-256-GCM for a digital will is aligning with the same standard that protects the world's most sensitive communications and data at rest.

What AES-256-GCM Does Not Solve

Honest security engineering requires acknowledging what a cryptographic primitive does not protect against.

Key management failures: AES-256-GCM is only as secure as the key. If the Master Key is leaked, all DEKs can be decrypted, and all wills are exposed. Proper key management --- secure storage, access controls, rotation policies --- is essential.

Endpoint compromise: If the server running BAP is fully compromised while it is operational, an attacker could potentially intercept the Master Key from memory or environment variables. Encryption protects data at rest and in transit, not data actively being processed in memory.

Side-channel attacks: Sophisticated attackers with physical access to the hardware might attempt to extract keys through power analysis, electromagnetic emanation, or cache timing attacks. These attacks are outside the threat model for most self-hosted deployments.

Social engineering: No encryption can protect against a Survivor who is tricked into handing over their key share. BAP's threshold model (K-of-N) mitigates this by requiring multiple Survivors to cooperate, but the system ultimately depends on human behavior at the recovery step.

Practical Implications for Your Digital Will

If you are evaluating digital will solutions, the encryption model should be a primary decision factor. Here is what to look for:

1. Authenticated encryption (AEAD): The tool should use AES-GCM, ChaCha20-Poly1305, or another AEAD scheme. If it uses AES-CBC or AES-CTR without a separate MAC, the integrity of your will data is not protected.

2. Per-document keys: Each will or document should have its own encryption key. A single key for all data means a single point of failure.

3. Key separation: The encryption key should not be stored alongside the encrypted data without an additional layer of protection (like a master key or HSM).

4. Nonce management: The tool should generate random nonces or use a deterministic nonce scheme that guarantees uniqueness. Ask about nonce handling --- it is a common source of implementation errors.

5. Threshold recovery: If you have multiple beneficiaries, the tool should support splitting the encryption key so that no single person can access your will alone.

Conclusion

AES-256-GCM is the right encryption standard for digital wills because it solves both the confidentiality problem (keeping your will secret) and the integrity problem (ensuring your will has not been tampered with) in a single, efficient, well-studied operation.

Combined with proper key management (hierarchical keys, per-will DEKs) and threshold recovery (Shamir's Secret Sharing), AES-256-GCM provides a defense-in-depth architecture that protects your most sensitive data through the most critical moment: the handoff to the people who need it when you are no longer around to verify it yourself.