INTERACTIVE / DATA PROTECTION
Data protection and key lifecycle experiments.
Educational demo. Fictional values only. No HSM or CSP connection. Inputs, mappings, and the key stay in page memory; nothing is submitted or saved by this lab.
Replace the value with a random reference of the same length. Recovery uses the vault mapping, not decryption.
Awaiting comparisonRandom letters and digits, matching the input length.
Length includes spaces and counts Unicode code points. Very short tokens have few possible values. This in-memory vault is not a production security boundary.
Hide characters in a display value. This reduces what is visible without encrypting the original.
Awaiting comparisonValues of 4 characters or fewer are fully hidden.
Hidden characters cannot be recovered from the masked string alone. The original value still exists in the input.
Transform the value using AES-256-GCM. Decryption needs the matching key, and authentication detects modified data.
Awaiting comparison256-bit key / 96-bit unique IV / 128-bit tag
The IV is public and unique per encryption. Resetting or reloading this page discards the demo key.
| In this demo | Tokenization | Masking | Encryption |
|---|---|---|---|
| What changes | Value replaced by a random reference of the same length | Characters hidden in the displayed value | Value transformed into ciphertext |
| How recovery works | Look up the token in the mapping table | Hidden characters are absent from the masked output | Decrypt using the matching key, IV, and authentication tag |
| Same input again | Same token while its mapping exists | Same output with the same policy | Different ciphertext because each operation uses a unique IV |
| What must be protected | The original data and access to its mapping | The original data behind the masked view | The key and the surrounding application |
This vault-based example preserves length, not character types or spacing. Tokenization does not always preserve length. Masking is not encryption or guaranteed anonymization. Browser cryptography does not provide an HSM security boundary or establish compliance.
New keys. Existing data. What still opens?
Educational browser experiment, not an HSM or CSP connection. Use fictional data only. Keys and records stay in page memory and are discarded on reload.
Rotation affects new writes, not existing ciphertext. Disabling v1 is reversible in this demo.
No encrypted records in this session.
0 record(s) still depend on KEK v1.
A stored record will show its key dependency and encrypted values here.
Web Crypto performs AES-256-GCM payload encryption with a fresh DEK and 96-bit IV for every new encryption. AES-256-KW wraps that DEK. Rewrapping changes the KEK protection without changing the payload; re-encryption generates a new DEK, IV, and ciphertext.
KEKs are non-extractable CryptoKey objects. DEKs are extractable while wrapping or rewrapping, as required by Web Crypto. Disabling a key is an application-level rule here, not hardware enforcement or secure key destruction. An HSM may enforce different boundaries. This demo has no backups or retained historical copies; production retirement must account for those too.
Web Crypto key wrapping reference