crypto::compare

Safe Defaults

Conservative recommendations for the most common cryptographic decisions. Send this page to any engineer.

Each recommendation links to its full entry in the algorithm browser. Click any algorithm badge for details, sources, and comparisons.

Password storage

✅ Argon2idscrypt as fallback
Why: Memory-hard password hashing raises attacker cost materially after database compromise. Argon2id balances resistance to GPU cracking and side-channel leakage; the actual cost advantage depends on the parameters and attacker hardware.

Symmetric encryption

✅ AES-256-GCMXChaCha20-Poly1305 if nonce management is hard
Why: AES-256-GCM provides authenticated encryption (AEAD) — confidentiality and integrity in a single operation. Hardware acceleration (AES-NI) makes it extremely fast on modern processors. NIST standardized and universally supported.

Authenticated messaging

Why: The 192-bit nonce of XChaCha20-Poly1305 makes random nonce generation safe even at extremely high message volumes, eliminating the most common AEAD failure mode. Combined with X25519 key agreement and HKDF key derivation, this forms the basis of modern secure messaging stacks like libsodium's sealed box construction.

Web / API transport

Why: TLS 1.3 eliminates legacy negotiation weaknesses, mandates forward secrecy, removes all known-weak cipher suites, and reduces handshake latency to a single round trip. It is the only version of TLS that should be deployed for new systems.

Digital signatures

✅ Ed25519ML-DSA-65 for PQ planning
Why: Ed25519 provides strong signatures with deterministic nonce generation (avoiding failures caused by weak random ECDSA nonces), compact 64-byte signatures, and a mature ecosystem. For post-quantum planning, FIPS 204 assigns ML-DSA-65 to NIST security category 3; that category is not an exact bit-strength claim.

Key exchange

✅ X25519ML-KEM-768 hybrid for PQ planning
Why: X25519 is a safe-by-default Diffie-Hellman function on Curve25519, designed to resist implementation errors. For post-quantum readiness, ML-KEM-768 (NIST FIPS 203) can be combined in a hybrid scheme where the shared secrets are concatenated and fed through HKDF — already deployed in Chrome and Firefox TLS 1.3.

General-purpose hash

✅ SHA-256BLAKE3 for performance-sensitive paths
Why: SHA-256 is a broadly interoperable, NIST-standardized choice with hardware acceleration on many modern processors and extensive protocol support. BLAKE3's parallel design can be attractive when measured throughput on the target platform matters more than standards compatibility.

MAC / message integrity

Why: HMAC-SHA-256 is a widely interoperable keyed authenticator standardized in FIPS 198-1 and RFC 2104. Generic quantum search changes idealized brute-force estimates, but real assurance also depends on key strength, tag length, protocol use, and implementation.

Choosing the right algorithm is 20% of security.

The distinction between a primitive and a protocol is where most teams stumble. AES-256-GCM is a primitive — it encrypts a block of data with a key and a nonce. TLS 1.3 is a protocol — it negotiates keys, authenticates peers, handles session resumption, and defends against replay and downgrade. Choosing AES-256-GCM does not mean you have a secure transport layer any more than choosing good lumber means you have a house.

Key generation, storage, and rotation are at least as critical as algorithm selection. A perfectly chosen cipher is worthless if the key is generated from a weak PRNG, stored in plaintext in a config file, or shared across environments. Keys should be generated from a CSPRNG, separated by purpose (never reuse an encryption key for authentication), and rotated on an explicit schedule rather than when someone remembers.

Implementation risk is the silent killer. Misuse-resistant APIs (like libsodium's secretbox) exist because even expert developers make mistakes with low-level primitives. A nonce reused in AES-GCM does not produce a helpful error message — it silently destroys your authentication guarantees and can leak the GHASH key. Choose libraries that make the safe path the default path, not libraries that give you maximum rope.

Deployment and key management infrastructure determine whether your cryptographic choices survive contact with reality. HSMs, secret managers, certificate authorities, rotation automation, and incident-response plans for key compromise are all part of the system. The algorithm is one parameter in a much larger security function.

Correct crypto ≠ secure system. A system can use every recommended algorithm on this page and still be vulnerable to timing leaks, memory-safety bugs, insecure deserialization, broken access control, or a misconfigured reverse proxy that terminates TLS at the wrong boundary. Cryptography solves specific, well-defined problems. It does not solve the general problem of building secure software.