Encryption & Cryptography for Developers: Practical Guide

Encryption & Cryptography

Cryptography protects the confidentiality and integrity of data. For most application developers, "doing crypto" doesn't mean inventing algorithms — it means making correct choices and using proven libraries safely.

Get the choices right (the right primitive for the job, unique nonces, managed keys) and the math takes care of itself. Get them wrong (custom schemes, reused IVs, keys next to ciphertext) and strong algorithms won't save you.

TL;DR

Never build custom crypto — use vetted libraries.
Use TLS for data in transit (see HTTPS & TLS).
Hash passwords (Argon2/bcrypt); don't encrypt them.
For data at rest, use AEAD ciphers (AES-256-GCM) and envelope encryption with managed keys.
Key management and rotation matter as much as the algorithm.

Quick Example

Authenticated encryption with AES-256-GCM in Node — note the unique IV per message and the auth tag:

Core Concepts

Encryption vs hashing

Encryption is reversible with a key — for confidentiality.
Hashing is one-way — for integrity and fingerprints.

Passwords must be hashed with a slow password-hashing function, never encrypted. See Password Security.

Symmetric vs asymmetric

In practice they combine: asymmetric crypto exchanges a key, symmetric crypto encrypts the data (this is roughly how TLS works).

Encryption at Rest

Encrypt sensitive data such as tokens, secrets, and (depending on your threat model) personal data and backups.

Envelope encryption is the standard pattern:

Generate a random data key per record/object.
Encrypt the data with the data key.
Encrypt the data key with a master key held in a KMS.

This lets you rotate the master key without re-encrypting all your data.

Key Management

Algorithms are the easy part; keys are where systems fail. Cover:

Storage — keep keys in a KMS or vault, never in the codebase. See Secrets Management.
Access — grant to the smallest set of services possible.
Rotation — rotate on a schedule and support re-encryption workflows.
Audit — log key usage.

Digital Signatures

Signatures prove authenticity and integrity (who produced this, and that it wasn't altered). Common uses: signed JWTs, webhook verification, and signed build artifacts. See JWT.

What to Use

When in doubt, reach for a high-level library like libsodium, which picks safe defaults for you.

Common Mistakes

Encrypting passwords instead of hashing them

Reusing a nonce/IV

Choosing an unauthenticated mode

FAQ

What's the difference between encryption and hashing?

Encryption is reversible with a key and is for confidentiality. Hashing is one-way and is for integrity or fingerprints. You decrypt ciphertext; you only ever compare hashes — you never "unhash."

Should I encrypt user passwords?

No — hash them with Argon2 or bcrypt. Encryption is reversible, so a single key compromise would expose every password. Hashing is one-way and salted by design.

When do I need asymmetric encryption?

When two parties can't share a secret in advance — key exchange, verifying signatures, or identity. For bulk data you've already got a shared key for, symmetric (AES-GCM) is far faster.

Where should encryption keys live?

In a dedicated KMS or secrets manager, separate from the ciphertext, with tightly scoped access and audit logging. Never check keys into source control or store them next to the data they protect.