Encryption: Definition, How It Works, and Where You’ll Encounter It

Encryption is a foundational security control that protects data by converting readable plaintext into unreadable ciphertext using cryptographic keys. You’ll encounter encryption in TLS/HTTPS, VPNs, disk and database encryption, backups, and messaging apps—and it’s worth verifying the configuration, not just assuming it’s “on.”

How encryption works

At a high level, encryption is “math + keys.” The algorithm defines the transformation; the key determines the specific output and who can reverse it.

Symmetric encryption (one key)

Symmetric encryption uses the same secret key to encrypt and decrypt. It’s fast, which makes it ideal for bulk data: disk encryption, database storage encryption, and the data channel inside TLS.

• Common algorithm: AES (Advanced Encryption Standard)
• Typical modes: GCM (recommended), CBC (legacy), CTR (sometimes), XTS (disk encryption)
• Security depends on: key length, mode of operation, correct IV/nonce use, and key handling

Why modes matter: AES by itself is a block cipher; modes define how blocks are chained and authenticated. Modern designs prefer AEAD modes (Authenticated Encryption with Associated Data), like AES-GCM or ChaCha20-Poly1305, which provide confidentiality and integrity.

Asymmetric encryption (key pair)

Asymmetric encryption uses a public/private key pair:

• Public key: shared freely; used to encrypt or verify signatures
• Private key: kept secret; used to decrypt or sign

Asymmetric crypto enables: - Key exchange (securely agreeing on a symmetric session key) - Digital signatures (proving authenticity and integrity) - Secure distribution (e.g., encrypt to a recipient’s public key)

Asymmetric operations are slower, so most real-world systems use it to establish a secure session and then switch to symmetric encryption for data transfer.

Encryption in transit: TLS/HTTPS

When you connect to a website over HTTPS, you’re using TLS. TLS typically: 1. Authenticates the server (via X.509 certificate and a trusted CA chain). 2. Negotiates a cipher suite (protocol version + key exchange + symmetric cipher + MAC/AEAD). 3. Performs key exchange (commonly ECDHE) to derive a shared session key. 4. Encrypts application data (HTTP) using symmetric encryption (commonly AES-GCM or ChaCha20-Poly1305).

Important concept: forward secrecy - With ephemeral key exchange (e.g., ECDHE), capturing encrypted traffic today won’t allow decryption later even if the server’s long-term private key is compromised (assuming the session keys aren’t logged elsewhere).

Encryption at rest: disks, files, databases, backups

At-rest encryption protects stored data from offline access—lost laptops, stolen drives, improper disposal, or snapshot exposure. Examples: - Full-disk encryption (FDE) - Volume encryption - Database TDE (Transparent Data Encryption) - Encrypted object storage/bucket encryption - Encrypted backups

At-rest encryption is only as strong as: - the key management (where keys live, rotation, access controls), - the boot/unlock model (TPM, passphrase, escrow), - and the threat model (it does not stop an attacker who already has runtime access to a logged-in system).

End-to-end encryption (E2EE)

E2EE means data is encrypted on the sender’s device and only decrypted on the recipient’s device. Intermediate systems (servers, relays) should not be able to decrypt content.

E2EE is common in modern messaging systems, but the details matter: - How identity keys are verified (QR codes, safety numbers) - Whether metadata is protected (often not fully) - How backups are handled (backups can reintroduce server-side access)

Key management: the real make-or-break

Encryption fails most often due to key handling, not the cipher.

Key management includes: - Generation: use cryptographically secure RNGs - Storage: HSM/KMS, TPM, or secure key vaults - Access control: least privilege, separation of duties - Rotation: periodic and event-driven (compromise) - Revocation: remove/disable compromised keys - Auditing: log key usage and administrative actions

A useful mental model: Data is only as secure as the easiest path to the keys.

Technical notes: quick checks and practitioner commands

Below are practical ways to confirm encryption is actually happening and is modern.

Verify TLS and certificates

Check a site’s negotiated protocol/cipher:

# Show cert chain and handshake details
openssl s_client -connect example.com:443 -servername example.com </dev/null

# Force a specific TLS version (should fail for old versions if disabled)
openssl s_client -tls1_2 -connect example.com:443 -servername example.com </dev/null
openssl s_client -tls1_1 -connect example.com:443 -servername example.com </dev/null

Look for: - Protocol: TLS 1.2/1.3 (prefer TLS 1.3 where possible) - Cipher: AES-GCM or CHACHA20-POLY1305 - Valid certificate chain and SAN/CN matching the hostname

Identify weak/legacy TLS usage in logs

Common indicators (varies by stack): - Requests over plain HTTP (port 80) without redirect/upgrade - Negotiation failures due to old clients - Deprecated protocol attempts (TLS 1.0/1.1) showing handshake errors

Example patterns you might see: - “unsupported protocol” - “handshake failure” - “no shared cipher”

Check disk encryption status (Linux examples)

If using LUKS:

lsblk -f
cryptsetup status /dev/mapper/<name>
cryptsetup luksDump /dev/<device>

Signals of a healthy setup: - LUKS2 where feasible - Strong PBKDF parameters - Keys not stored in plaintext on the same disk

Confirm SSH uses modern crypto

ssh -vv user@host

Look for modern KEX and ciphers (e.g., curve25519, chacha20-poly1305, aes128-gcm). Disable obsolete algorithms in sshd_config when possible.

Where you’ll encounter encryption (and what to verify)

Encryption is everywhere in modern IT, but these are the places where configuration mistakes are most common—and most costly.

Web browsing and APIs (HTTPS/TLS)

• Public websites, admin portals, SaaS, internal apps
• API calls between services (microservices, service meshes)
• Load balancers and reverse proxies terminating TLS

What to do next - Enforce TLS 1.2+ (prefer TLS 1.3), disable legacy ciphers - Use HSTS for public web apps where appropriate - Ensure internal service-to-service traffic is encrypted when required by policy or regulation

Email and collaboration

• TLS between mail servers is common but not always guaranteed end-to-end
• Optional user-level encryption (S/MIME or PGP) exists but requires operational maturity

What to do next - Don’t assume email is end-to-end encrypted by default - Use secure portals or file-sharing with strong access controls for sensitive data

Remote access: VPN, ZTNA, SSH

• VPN tunnels encrypt traffic between endpoints
• Zero Trust Network Access (ZTNA) typically uses TLS with strong identity and device posture
• SSH encrypts remote shell sessions and file transfers

What to do next - Standardize on modern VPN protocols and strong authentication (MFA) - Restrict SSH to key-based auth; disable password auth where possible

If you’re selecting a VPN for travel or remote work, look for modern protocols (like WireGuard), audited apps, and clear no-logs policies. For example, NordVPN (Check NordVPN pricing →) or Surfshark (Try Proton VPN →) are commonly evaluated options—just make sure your decision also accounts for your org’s compliance requirements and identity controls.

Storage: laptops, servers, cloud volumes, backups

• Laptop full-disk encryption reduces risk from lost/stolen devices
• Cloud disk/object encryption is often available but may be optional or misconfigured
• Backups are frequently copied, moved, and retained—making encryption critical

What to do next - Encrypt backups and protect backup keys separately - Validate restore procedures (a backup you can’t decrypt/restore is not a backup)

Databases and secrets

• Database “transparent” encryption protects physical media/snapshots, not necessarily app-layer threats
• Application-level encryption can protect specific fields (PII, secrets) even if DB access is compromised

What to do next - Decide whether you need storage-level encryption, app-layer encryption, or both - Use a KMS/HSM for key storage and audit key usage

Messaging and conferencing

• Many tools encrypt in transit; some offer E2EE
• Meeting recordings and cloud archives can become the weak point

What to do next - Confirm whether “encryption” means in-transit, at-rest, or E2EE - Control recording storage, retention, and access policies

Practical security tie-ins (so encryption isn’t a checkbox)

Encryption is one control in a larger security system. Two common gaps:

• Endpoint compromise: If malware runs as the user (or on a server), it can access data after decryption. That’s why encryption should be paired with strong endpoint protection and monitoring. If you’re evaluating business endpoint security, see our comparison: best antivirus for windows business endpoints 2026.
• Credential theft: If attackers steal passwords/session tokens, they may not need to “break encryption” at all. Pair encryption with strong authentication and password hygiene; for teams, a managed password vault can reduce reuse and improve sharing controls. Our guide: password manager for small business 2026 (some readers also consider 1Password: Try 1Password →).