Most teams do not need a new cipher, they need clear defaults and the discipline to apply them consistently. If you pick algorithms by use case, keep keys out of reach, and minimize data lifetimes, you will already be ahead of most breaches in 2025.
This 101 is a practical map. It explains the building blocks, then gives you opinionated defaults for common scenarios so you can decide what to use and when.
Start with your goal and your data state
Every encryption decision flows from three questions:
- What do you need, confidentiality, integrity, authenticity, or all three
- Where is the data, in transit, at rest, or in use
- Who are you defending against, an external attacker, a compromised admin, a subpoena, or a malicious vendor
Answer these and selection becomes straightforward.
The quick answer, sensible 2025 defaults
- In transit, use TLS 1.3 with AEAD cipher suites, for example AES‑GCM or ChaCha20‑Poly1305, and enable forward secrecy. See RFC 8446.
- At rest, use AES‑256 with an authenticated mode. For disks use AES‑XTS, for files and objects use AES‑GCM. Wrap data keys with a KMS master key and rotate.
- Passwords, never encrypt, hash with Argon2id and unique salts. Tune memory, time and parallelism for your hardware. See RFC 9106.
- Key exchange, use X25519 or ECDHE P‑256 for forward secrecy. See RFC 7748.
- Digital signatures, prefer Ed25519 or ECDSA P‑256. Use RSA 3072 only if compliance or legacy requires it.
- One time secret handoff to people outside your system boundary, use client side encrypted, self destructing links with AEAD, short expiry and one view.
If you want a plain language deep dive on symmetric encryption itself, see our quick guide to AES‑256 encryption explained for non engineers.
Understand the building blocks
- Symmetric encryption, one secret key for encrypt and decrypt. Fast and ideal for data at rest. Example, AES‑256 in GCM mode.
- Asymmetric encryption, two keys, public and private. Useful for key exchange and signatures. Example, X25519 for key agreement, Ed25519 for signatures.
- AEAD, authenticated encryption with additional data. Protects confidentiality and integrity together. Examples, AES‑GCM and ChaCha20‑Poly1305.
- Hashing and KDFs, one way functions for verification or key derivation. Use Argon2id for passwords, HKDF for deriving subkeys.
- HMAC, message authentication with a shared key. Use HMAC‑SHA‑256 when you need integrity without confidentiality.
OWASP has solid, vendor neutral basics in its Cryptographic Storage Cheat Sheet and Password Storage Cheat Sheet.
What to use and when, a compact cheatsheet
| Goal | Typical choice | Avoid | Notes |
|---|---|---|---|
| Secure web and API traffic | TLS 1.3 with AES‑GCM or ChaCha20‑Poly1305, ephemeral ECDHE | Legacy TLS, static RSA key exchange, RC4, 3DES | Turn on HSTS, consider mTLS inside your perimeter, validate certificates properly. |
| Encrypt files or objects at rest | AES‑256‑GCM per object, keys managed by KMS and envelope encryption | AES‑ECB, AES‑CBC without authentication, home built schemes | Store only ciphertext and metadata, rotate data keys, separate duties for key access. |
| Full disk or volume encryption | AES‑XTS with strong keys | Plain file system, old or proprietary ciphers | Protect keys with TPM or HSM, lock when the machine sleeps, monitor for cold boot risk. |
| Store user passwords | Argon2id with per user salt, tuned cost | Plain SHA‑256, SHA‑1, MD5, reversible encryption | Consider an application level pepper stored in an HSM or KMS, rate limit and add MFA. |
| Database field level protection | AES‑GCM with per record or per tenant keys, optional deterministic AE only when you must index | Deterministic encryption for secrets, shared key across all tenants | Keep nonces unique, avoid leaking structure, plan key rotation and re‑encryption jobs. |
| Backups and archives | AES‑256 AEAD, separate key from backup, sign manifests | Unencrypted backups, shared keys with production | Keep keys off the backup media, test restores, rotate and destroy retired media. |
| Digital signatures | Ed25519 or ECDSA P‑256, RSA 3072 if mandated | DSA, tiny RSA keys | Timestamp signed artifacts, pin public keys where possible. |
| Key exchange | X25519 or ECDHE P‑256 | Static RSA key exchange | Forward secrecy protects past traffic if a key leaks later. |
| Human to human secret handoff | Client side encrypted, one time, self destructing link | Email, chat, tickets, long lived paste sites | Minimize lifetime and views, verify recipient via a separate channel, keep audit of access events without storing the secret. |
If your use case does not fit the table, the selection method is the same. Define the goal, pick an AEAD mode for confidentiality plus integrity, use modern curves for key exchange, and put key management first.
Key management matters more than the cipher
NIST's guidance on key life cycle and separation of roles is a good anchor. See NIST SP 800‑57 Part 1.
- Generation, use the OS cryptographic random source, never a custom PRNG.
- Storage, keep master keys in a KMS or HSM. Applications should receive short lived data keys, often via envelope encryption.
- Rotation, rotate on a schedule and for cause, and design for safe re‑encryption without downtime.
- Access control and audit, restrict who can use keys, log every use. Separate environments and tenants. Review logs regularly.
- Retirement, destroy retired keys and render old ciphertext inaccessible unless you explicitly need long term decryption.
When server side encryption is not enough
Server side encryption protects against a storage breach, but it does not protect against the service itself reading your data. When your threat model includes a compromised admin, an untrusted vendor, or subpoena exposure, move the trust boundary to the client with zero knowledge design.
Client side encryption means plaintext is encrypted on the sender's device, the server sees only ciphertext, and the decryption key never leaves the sender and recipient context. For a practical introduction to why this matters, see our explainer on client side vs server side encryption.
This is exactly the pattern for one time secret sharing. Nurbak encrypts secrets on the sender side, produces a one time link, and destroys the ciphertext after it is read. Access can be audited without ever storing the secret. That combination, one view, short expiry, audit event, and zero knowledge, dramatically reduces long term exposure.
Practical defaults and parameters in 2025
- AES‑GCM vs ChaCha20‑Poly1305, both are secure AEADs. AES‑GCM is very fast on servers with AES‑NI. ChaCha20‑Poly1305 is a strong default on mobile and embedded where AES acceleration may be weak.
- Key sizes, AES‑128 is acceptable, AES‑256 is a conservative default. For RSA use 3072 bit or higher if you must. For elliptic curves prefer P‑256 or the modern 25519 family.
- Nonces and IVs, generate a fresh, unique nonce per encryption. Never reuse nonces with AEAD.
- Password hashing parameters, tune Argon2id memory first, then iterations, then parallelism, to push verification close to your latency budget while keeping it expensive for attackers.
- Libraries, prefer vetted implementations over custom code. Examples include libsodium, BoringSSL or the platform Web Crypto API. Never copy code snippets from random forums.
Common mistakes that cause real breaches
- Encrypt without authentication, AES‑CBC without an HMAC invites tampering. Use AEAD.
- Reuse IVs or nonces, this can fully break confidentiality with AEAD modes.
- Hardcode keys or share them across tenants or environments.
- "Encrypt" passwords instead of hashing with a memory hard function.
- Rely on email or chat logs to move credentials. These channels are persistent, searchable and often backed up.
- Build your own crypto or mix primitives in novel ways. Composition is subtle and easy to get wrong.
A simple decision flow
Real world examples
- Sharing a database password with a vendor, send a zero knowledge, one time link with a one view cap and a 24 hour expiry. Confirm receipt over a separate channel. Rotate the password after use.
- Encrypting product exports or PII before cloud upload, encrypt with AES‑GCM on the client, wrap the data key with your KMS, store only ciphertext and metadata.
- Securing internal microservice calls, enforce TLS 1.3 everywhere, use mTLS for service to service trust, pin CA roots and automate certificate rotation.
- Storing user passwords for login, use Argon2id with per user salt, optional application level pepper in an HSM. Monitor login attempts and apply MFA.
Compliance notes
Strong encryption helps demonstrate due care for SOC 2, ISO 27001, GDPR and HIPAA. Auditors will look for documented algorithms and parameters, key management, separation of duties, and evidence of rotation and access review. Zero knowledge patterns reduce the amount of sensitive data you retain, which reduces breach and fine exposure.
How Nurbak fits
Nurbak focuses on one specific but risky gap, ad hoc human to human secret sharing. Instead of placing live credentials in persistent channels, Nurbak creates self destructing, client side encrypted links. Features that support this workflow include one time access links, AES‑256 encryption, zero knowledge architecture, no data logging or storage, audit access logs, and an admin dashboard with analytics for oversight. Secrets are encrypted locally and permanently deleted after being read, so your logs contain only dead links, not credentials.
If you are adopting a privacy by default posture, this is a high leverage win because it eliminates a common source of credential sprawl across email, chat and ticketing.
FAQs
What is the difference between encryption and hashing Hashing is one way and used for verification, for example password storage. Encryption is two way and used for confidentiality. When you need both confidentiality and integrity, use an AEAD mode like AES‑GCM.
Is AES‑256 always better than AES‑128 Both are secure when used correctly. AES‑256 offers a larger security margin. Performance and platform support sometimes favor AES‑128. Most teams standardize on AES‑256 for simplicity.
Should we still use RSA Use elliptic curves for new systems, for example X25519 for key exchange and Ed25519 for signatures. Use RSA 3072 only if you must support legacy or a compliance mandate. Avoid static RSA key exchange.
How do I choose Argon2id parameters Benchmark on your production hardware. Target a verification time that is acceptable for login while expensive for attackers. Increase memory first, then iterations. See the guidance in RFC 9106.
Can I encrypt in the database and still query Yes, but it is a trade off. Deterministic encryption allows equality queries but leaks duplicates. Keep it to low risk fields, never to secrets, and isolate keys per tenant or table.
What about key management best practices Use a KMS or HSM, never store master keys in application config. Rotate routinely and for cause. Log every key use and review access. See NIST SP 800‑57 Part 1.
How do I secure internal service to service calls Enforce TLS 1.3 everywhere with forward secrecy. Prefer ECDHE with X25519 or P‑256, and AEAD ciphers. Consider mutual TLS for authentication. See RFC 8446 and RFC 7748.
Ready to remove live credentials from email and chat without slowing your team down, Create a zero knowledge, one time encrypted link with Nurbak in seconds at Nurbak.