What it means
Encryption uses a cryptographic algorithm and key to transform readable data into ciphertext. Its value depends on where it is applied and who can use the key. Transport encryption protects a connection between endpoints; storage encryption protects data in a particular stored form. Neither automatically prevents an authorized application from disclosing the plaintext it can read. Implementations should use maintained libraries and established protocols, with a plan for key generation, access, rotation, recovery, and retirement. Integrity protection also matters: confidentiality alone does not establish that data was not altered.
The idea at a glance / Data
Keep the key separate from the package.
Compare readable data, its real encrypted bytes, and two authenticated-decryption results. Possessing a key and having permission are different questions.
Synthetic AES-256-GCM example: UTF-8 DOCK 8, no newline. Sender and receiver already have lab key K8 by a separate assumed setup. One encryption uses nonce N8 and a 128-bit tag; no additional authenticated data.
READ THE PICTURE
Read the connections and checks
DOCK 8 becomes ciphertext 12a0401ab096. The package includes a nonce and integrity tag, not K8. With K8, the valid package recovers DOCK 8; changing one tag bit causes refusal instead of accepted plaintext.
Keep in mindAll bytes and K8 are public teaching fixtures, not production secrets. Real GCM encryption must not reuse a nonce with its key. Successful decryption does not establish application permission or prevent replay by itself.
Read the complete example
- Read the connections and checks. DOCK 8 becomes ciphertext 12a0401ab096. The package includes a nonce and integrity tag, not K8. With K8, the valid package recovers DOCK 8; changing one tag bit causes refusal instead of accepted plaintext. The six UTF-8 bytes for DOCK 8 are 444f434b2038. AES-256-GCM under lab key K8 produces ciphertext 12a0401ab096; the full ciphertext is drawn, not an invented scramble. K8 is the public fixture value 0000000000000000000000000000000000000000000000000000000000000001. Nonce N8 is 000000000000000000000002, and the 128-bit tag T8 is c8a63e6a8018cf2c18b9b838b14b326b. There is no additional authenticated data and no newline. The sender retains the original plaintext. The transmitted/stored package contains ciphertext, nonce, and tag, while key provisioning is separate and assumed already complete. Independent decryption test A with K8, N8, and T8 recovers DOCK 8. Test B changes only the tag’s first byte from c8 to c9, yielding c9a63e6a8018cf2c18b9b838b14b326b; authentication fails and plaintext must not be accepted or released. These are two tests of one package, not two fresh encryptions with a repeated nonce. The real byte relationship and changed-tag refusal are checked with the platform cryptographic library. Knowing K8 permits cryptographic recovery under these conditions but does not prove that a human or account is authorized to read the content. GCM provides authenticated encryption; ordinary encryption alone does not necessarily provide integrity, and replay prevention needs protocol context.
All bytes and K8 are public teaching fixtures, not production secrets. Real GCM encryption must not reuse a nonce with its key. Successful decryption does not establish application permission or prevent replay by itself.
Diagram references: NIST SP 800-38D - authenticated encryption and decryption · OWASP - authenticated encryption and key handling
AN ILLUSTRATIVE SCENARIO
A clinic exports research records
A clinic sends an approved dataset to a research partner. The transfer uses an encrypted connection and the receiving storage has encryption enabled. The clinic still checks that the dataset contains only the permitted information and that the partner's account permissions are appropriate. For its own retained encrypted archive, the clinic tests recovery of the required key through a controlled procedure. A lost key could make the archive unreadable even though all the encrypted files remain present.
Put it to work
- Identify which data needs protection, who is allowed to read it, and the threats to transmission and storage. Map every place plaintext is created, processed, logged, or exported.
- Use supported platform encryption and vetted libraries rather than designing a cipher. Configure appropriate authenticated encryption or secure transport, and limit access to the associated keys and plaintext.
- Document key ownership, rotation, recovery, and revocation. Include encrypted backups and dependent services in recovery tests, and ensure logs or temporary files do not bypass the intended protection.
How to check your work
Check that the intended connection or stored object is encrypted, unauthorized identities cannot obtain plaintext, and authorized recovery works. Inspect one complete data flow for unprotected exports, logs, caches, and backup copies rather than checking a single settings page.
Connect the ideas
- TLS
A protocol that encrypts and integrity-protects an application conversation and checks a certificate for a name.
- Secrets management
Storing, rotating, and auditing passwords, keys, and tokens so they are not copied into chat or source.
- Confidentiality
The property that information is available only to people or systems authorized to see it.
- Privacy
Questions about appropriate collection, use, retention, and disclosure of personal information, including what the person can expect. Distinct from confidentiality.