Encryption: Turning Plaintext Into Key-Protected Ciphertext
📑 On this page
- A concrete example: a stolen laptop
- Plaintext, ciphertext, algorithm, and key
- Symmetric encryption
- Asymmetric encryption
- Encryption in transit
- Certificates connect keys to identities
- Authenticated encryption
- Nonces must follow the algorithm's rules
- Data at rest
- Key management is the central problem
- Key rotation
- Endpoints see plaintext
- Encryption is not hashing or signing
- Failure and recovery planning
- Knowledge check
- The one idea to remember
Data stored or transmitted in readable form can be exposed to anyone who gains access to the storage device, network path, backup, or account.
Encryption changes the representation.
Encryption transforms readable plaintext into ciphertext using an algorithm and key. Authorized parties use the required key to recover the plaintext or participate in a secure exchange.
The algorithm can be public. Security should depend on protecting keys, not hiding how the algorithm works.
A concrete example: a stolen laptop
A laptop contains customer documents. A thief removes its storage drive and connects it to another computer.
Without disk encryption, operating-system login controls may be bypassed because the thief reads the storage directly.
With properly configured full-disk encryption, the stored sectors are ciphertext. The thief needs the decryption key, which may be protected by a device security module and the user's login secret.
Encryption protects the powered-off storage. If the laptop is already unlocked, malicious software or a person at the keyboard may still read files through the authorized operating system.
Plaintext, ciphertext, algorithm, and key
The basic concepts are:
- Plaintext: Original readable data
- Ciphertext: Encrypted output
- Algorithm: Defined transformation
- Key: Secret or controlled value that determines the transformation
Modern cryptographic algorithms are designed for public analysis. An attacker can know exactly which algorithm is used and still be unable to decrypt without the key.
Creating a custom secret cipher is dangerous because subtle mathematical flaws are difficult to detect. Use established libraries and protocols.
Symmetric encryption
Symmetric encryption uses the same secret key, or closely related secret material, for encryption and decryption.
It is efficient for large amounts of data and is used for:
- Disk encryption
- Database fields
- Backups
- Network session traffic
- File archives
The hard problem is key sharing. How do two parties establish the secret without exposing it?
Modern protocols commonly use asymmetric cryptography to establish or protect a temporary symmetric session key.
Asymmetric encryption
Asymmetric cryptography uses a key pair:
- A public key that can be shared
- A private key that must remain controlled
For encryption, data protected for a public key can be decrypted by the corresponding private key under the scheme's rules.
Asymmetric operations are slower and have size constraints, so systems do not usually encrypt an entire video directly with them.
Instead, they use hybrid encryption:
- Generate a random symmetric key.
- Encrypt the data efficiently with that key.
- Protect the symmetric key using the recipient's public key.
Encryption in transit
Transport Layer Security, or TLS, protects communication such as HTTPS.
During a connection:
- The server presents a certificate.
- The client validates the server identity.
- The parties establish shared session keys.
- Traffic is encrypted and authenticated.
TLS protects against network observers reading or silently changing traffic.
It does not prove that the website itself is honest, that the user's device is clean, or that the server will handle submitted data responsibly.
Certificates connect keys to identities
A certificate binds a public key to a domain or other identity and is signed by a trusted certificate authority.
When visiting an HTTPS site, the browser checks:
- The certificate matches the requested domain.
- It is within its validity period.
- It chains to a trusted authority.
- Its signature and usage are valid.
Certificate automation reduces outages from expiration, but private keys and issuance controls remain sensitive.
A valid certificate means the encrypted connection reaches the named domain. It does not certify that every page or business claim is trustworthy.
Authenticated encryption
Encryption alone hides content but may not detect modification.
Modern systems use authenticated encryption, which provides:
- Confidentiality
- Integrity
- Authenticity under the shared key
If ciphertext or associated metadata changes, verification fails.
Algorithms such as AES-GCM and ChaCha20-Poly1305 are common authenticated-encryption constructions.
Developers should use a high-level library that manages details rather than combine encryption and authentication primitives manually.
Nonces must follow the algorithm's rules
Many encryption modes require a nonce, a value used once with a particular key.
A nonce often does not need to be secret, but reuse can destroy security for some algorithms.
Libraries and protocols may generate nonces automatically. If application code manages them, it must understand uniqueness, size, storage, and concurrency requirements.
This is an example of why correct algorithm names are not enough. Secure cryptography depends on correct operation.
Data at rest
Encryption at rest can apply to:
- Full disks
- Individual files
- Database storage
- Backups
- Object storage
- Selected fields
Storage-level encryption protects lost media and some unauthorized infrastructure access.
Application-level field encryption can keep selected values unreadable even to some database operators, but complicates search, rotation, and recovery.
Choose the layer according to the threat. Multiple layers can protect different boundaries.
Key management is the central problem
Encrypted data is only as protected and recoverable as its keys.
Key management includes:
- Secure generation
- Access control
- Storage
- Rotation
- Backup
- Revocation
- Audit
- Destruction
Keys should not be embedded in source code or stored beside ciphertext with identical permissions.
Organizations often use hardware security modules or managed key services that perform cryptographic operations while restricting raw key access.
Key rotation
Keys may need rotation after:
- Suspected compromise
- Staff or role changes
- Policy deadlines
- Cryptographic migration
- Routine lifecycle limits
Rotation can mean:
- Encrypting new data with a new key
- Rewrapping data keys
- Gradually re-encrypting old records
- Preserving older keys for authorized decryption
Deleting an old key too early can make legitimate historical data permanently unreadable.
Rotation needs inventory and tested recovery, not only a new key-generation command.
Endpoints see plaintext
Encryption protects data between trusted endpoints or while stored outside active use.
At some point, an authorized application decrypts data to display or process it.
Threats at that endpoint include:
- Malware
- Stolen sessions
- Excessive permissions
- Screen capture
- Application bugs
- Insider misuse
End-to-end encryption reduces which intermediaries can access content, but the sender and recipient devices still handle plaintext.
Secure endpoints and authorization remain necessary.
Encryption is not hashing or signing
These tools serve different purposes:
- Encryption: Reversible confidentiality using a key
- Hashing: One-way fingerprint for integrity and verification
- Digital signature: Private-key proof that data was approved by the key holder and not changed
A digital signature does not hide a document. Encryption does not automatically prove who created it unless used inside an authenticated protocol.
Clear goals prevent misuse of cryptographic tools.
Failure and recovery planning
Before encrypting important data, answer:
- Who can decrypt it?
- Where are keys stored?
- What happens if the key service is unavailable?
- How are keys backed up?
- How is access revoked?
- Can data be migrated to new algorithms?
- How is key use audited?
Losing a key can be equivalent to deleting every encrypted record.
Security that prevents both attackers and legitimate recovery is not successful.
Knowledge check
- Why can an encryption algorithm be public?
- How do symmetric and asymmetric encryption differ?
- What does TLS protect, and what does it not prove?
- Why is nonce reuse dangerous for some encryption modes?
- Why do trusted endpoints remain a risk after encryption is deployed?
The one idea to remember
Encryption converts readable data into key-protected ciphertext. Its real security depends on authenticated protocols, correct operation, controlled keys, trustworthy endpoints, and a recovery plan that preserves legitimate access.