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 combines memory hardness with GPU and side-channel resistance, making brute-force attacks orders of magnitude more expensive than hash-only or iteration-only approaches.

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 (eliminating the most dangerous class of ECDSA bugs), compact 64-byte signatures, and a mature ecosystem. For post-quantum planning, ML-DSA-65 (NIST FIPS 204) provides 192-bit PQ security with reasonable signature sizes.

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 the universal interoperability default: NIST standardized, hardware-accelerated on most modern processors, and the foundation of HMAC-SHA-256, HKDF, and certificate infrastructure. BLAKE3 offers massively parallel hashing at ~0.3 cycles/byte when raw throughput matters more than ecosystem compatibility.

MAC / message integrity

Why: HMAC-SHA-256 is the universal standard for keyed message authentication: NIST FIPS 198-1, used in TLS 1.3, IPsec, and JWT. It is PQ-safe (quantum attacks only halve the security to 128 bits via Grover's algorithm, which remains sufficient). Works with any hash function and has a clean security proof under the PRF assumption.

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.