Cryptographic algorithm decision system for engineers, architects, and technical decision-makers.
97 algorithms. 17 categories. 68 linked public demos. Sourced recommendations. Safe-usage guidance. Reference architectures. Post-quantum migration context.
So whether you eat or drink or whatever you do, do it all for the glory of God. — 1 Corinthians 10:31
crypto::compare is a browser-based decision-support tool for choosing cryptographic algorithms responsibly.
It is designed for the point where real engineering work begins: when someone has to decide what to use for messaging, storage, authentication, signatures, or post-quantum migration, and needs something better than vague advice or a random blog post.
This project helps you:
- choose algorithms by use case rather than by hype
- compare primitives side by side using consistent fields
- understand where recommendations are strong, conditional, or uncertain
- avoid common cryptographic mistakes before they become system failures
This project does not:
- implement cryptographic operations
- certify systems for compliance
- replace a professional security review
- protect you from implementation bugs or operational mistakes
If you only spend 30 seconds on this repository, use this path:
- Need a decision fast? Start with If You're Building X → Use This.
- Need to compare options? Use the live comparison table and decision flowchart.
- Need to avoid dangerous mistakes? Read Common Pitfalls & Safe Usage before touching code.
This project tries to earn trust in concrete ways rather than by tone alone.
| Signal | What It Means |
|---|---|
| 97 algorithms across 17 categories | Coverage is broad enough to support real design tradeoffs, not just a curated shortlist |
| Per-algorithm provenance | Entries are backed by standards, cryptanalysis, deployment references, and review dates |
| 5-level recommendation model | Recommendations are not binary; they distinguish safe defaults from acceptable, legacy, research, and avoid |
| Explicit tradeoffs | Entries include "Why not this?", assumptions, and "When this changes" conditions |
| Validation and tests | Dataset validation is enforced with Zod and covered by a substantial automated test suite |
| Static architecture | No backend, no accounts, no telemetry, no hidden recommendation engine |
Trust still has limits here:
- recommendation quality is only as good as the underlying sources and review freshness
- implementation safety still depends on the library and the surrounding system design
- there is no institutional backing, external audit, or guaranteed update cadence
- provenance entries currently carry review dates spanning 2026-03-16 through 2026-04-07
- each algorithm record includes a
lastReviewedvalue in the dataset provenance - recommendation confidence should drop as that review window gets older relative to new cryptanalysis, standards work, or deployment changes
These are conservative defaults, not universal laws. They are meant to get a capable engineer onto safe ground quickly.
| Building | Recommended Stack | Why It Works | Real-World Pattern | Avoid This | When It Changes |
|---|---|---|---|---|---|
| Secure Messaging | XChaCha20-Poly1305 + X25519/ML-KEM-768 hybrid + HKDF ratchet + strong identity signatures | AEAD for confidentiality and integrity, hybrid exchange for forward secrecy plus PQ transition, ratcheting for compartmentalization | Signal-style designs, PQXDH-style migration, modern end-to-end messaging | Static RSA, no ratchet, random-nonce AES-GCM at very high message volume without discipline | Shift more fully to PQ components as ecosystem support matures |
| Password Storage / Authentication | Argon2id with strong memory cost, unique salt, TLS in transit | Memory-hard password hashing raises attacker cost materially after database compromise | Modern password storage guidance, password managers, current OWASP direction | MD5, SHA-1, SHA-256 alone, unsalted hashes, low-cost PBKDF2 for new systems | Tune parameters upward as commodity hardware improves |
| File Encryption at Rest | AES-256-GCM where hardware acceleration exists, otherwise XChaCha20-Poly1305; HKDF for key separation | AEAD prevents silent tampering; per-file derivation limits blast radius | Full-disk encryption, backup encryption, encrypted archives | ECB, CBC without authentication, nonce reuse, same key for every purpose | Add PQ wrapping when long-term confidentiality matters |
| API / Web Encryption | TLS 1.3 with AES-256-GCM or ChaCha20-Poly1305; X25519 with hybrid PQ where available | Removes legacy negotiation problems, provides forward secrecy, aligns with modern transport security practice | HTTPS, service-to-service APIs, gRPC over TLS | TLS 1.0/1.1, RSA key exchange, skipping certificate validation | Certificate and KEM choices change as PQ standards land in mainstream PKI |
| Long-Term Sensitive Data | ML-KEM-1024 + AES-256 + conservative signature choice such as SLH-DSA for archival cases | Designed for data that may need to survive the classical-to-PQ transition | Government, medical, legal, and archival confidentiality planning | Waiting for a "perfect" migration moment, assuming RSA/ECC is fine for multi-decade secrecy | Reassess if PQ cryptanalysis materially changes confidence in current assumptions |
| Digital Signatures | ML-DSA for PQ planning; Ed25519 for classical deployments where appropriate | Clear modern defaults with strong ecosystems and fewer operational traps than older options | Software signing, document signing, API auth, commit signing | RSA-1024, legacy DSA, fragile ECDSA deployments with poor nonce handling | Toolchain and compliance requirements may force different choices in regulated environments |
The live tool expands these with detailed stacks, rationale, tradeoffs, and links into specific algorithms.
Cryptographic algorithms are public standards and published constructions, not secret sauce. AES, SHA-256, HKDF, ML-KEM, and ML-DSA are secure because they have been studied, attacked, formalized, debated, and deployed in the open.
That also means algorithm choice is only part of the problem.
Most real-world failures happen in implementation and operations:
- nonce reuse
- broken key management
- skipped certificate validation
- side channels
- unsafe defaults
- custom code where a vetted library should have been used
Do not write your own cryptographic primitives.
Use established libraries. Treat algorithm selection and implementation quality as separate decisions that both matter.
This section is intentionally direct because crypto mistakes fail hard.
| Rule | Why It Matters |
|---|---|
| Never reuse a nonce with AES-GCM or ChaCha20-Poly1305 | Reuse can destroy confidentiality and authenticity guarantees |
| Never encrypt without authentication | Confidentiality without integrity gives attackers room to manipulate ciphertext |
| Never use fast general-purpose hashes for passwords | Password storage needs memory-hard functions like Argon2id, not SHA-256 |
| Never use ECB mode | It leaks structural information about plaintext |
| Never hard-code secrets | Keys in source control or build pipelines eventually leak |
| Never roll your own crypto | Custom primitives and protocols fail in ways that are difficult to detect |
| Never disable certificate verification | That turns TLS into theater |
- generate keys with a CSPRNG, never a general-purpose PRNG
- separate keys by purpose: encryption, MAC, signing, and derivation keys should not be interchangeable
- rotate long-lived keys on an explicit policy rather than ad hoc intuition
- keep secrets in hardware-backed stores or dedicated secret-management systems where possible
- plan for compromise: revocation, re-issuance, and blast-radius reduction matter as much as initial generation
- timing leaks, memory-safety bugs, and side-channel vulnerabilities
- bad protocol composition
- poor secrets handling and weak operational controls
- unsafe framework defaults or insecure deployment configuration
Choosing the right primitive helps. It does not make the surrounding system safe by itself.
Algorithm safety depends heavily on implementation quality. If your codebase touches cryptography directly, prefer mature libraries with strong operational history.
| Category | Primary Direction | Common Options |
|---|---|---|
| General-purpose application crypto | libsodium | NaCl-family bindings across major languages |
| TLS and transport security | BoringSSL or OpenSSL 3.x | Also language-native TLS stacks built on vetted primitives |
| Rust systems | ring plus rustls where appropriate | Use ecosystem-native wrappers instead of raw bindings where practical |
| Post-quantum experimentation and integration | liboqs and PQClean-derived wrappers | For evaluation and early integration, not blind production use |
| Browser crypto | Web Crypto API | Use native browser primitives rather than hand-rolled JavaScript |
| Go services | crypto/* and x/crypto |
Prefer standard-library and official extensions |
| JVM / .NET ecosystems | Bouncy Castle where needed | Especially when broader algorithm coverage is required |
| Library | Why It Is Trusted | Seen In |
|---|---|---|
| libsodium | Misuse-resistant API design and broad language support | Modern application crypto, sealed boxes, message encryption |
| BoringSSL | Hardened operational pedigree and large-scale deployment | Chrome, Android, large internet-facing systems |
| OpenSSL 3.x | Deep ecosystem penetration and compliance relevance | Servers, appliances, enterprise deployments |
| ring | Minimalist surface area and strong Rust adoption | Rust TLS and security-sensitive infrastructure |
| liboqs | Tracks mainstream PQ standardization work closely | PQ evaluation and migration prototypes |
| Web Crypto API | Native browser implementation path | Web apps that need client-side cryptography |
The right pattern is usually: choose a sound algorithm here, then implement it through one of these libraries instead of custom code.
These are not complete protocols. They are system-level reference patterns that show how the primitives fit together.
Identity Keys → Hybrid Session Setup → HKDF / Ratchet → AEAD Message Encryption → Transcript / State Binding
- Stack: identity signatures, hybrid key establishment, HKDF-derived message keys, AEAD for messages
- Security properties: confidentiality, forward secrecy, compartmentalization, authenticated peer identity
ClientHello → Certificate Validation → Ephemeral Key Agreement → Session Keys → AEAD Records
- Stack: TLS 1.3, ephemeral key agreement, AEAD record protection, authenticated certificates
- Security properties: confidentiality, integrity, server authentication, replay resistance, forward secrecy
Passphrase or Master Key → Strong KDF → Per-File Key → AEAD Encryption → Store Ciphertext + Metadata
- Stack: Argon2id or master-key input, HKDF-style separation, AES-256-GCM or XChaCha20-Poly1305
- Security properties: confidentiality, integrity, limited blast radius, portability of encrypted artifacts
Password → Argon2id → Stored Hash + Salt + Parameters → TLS-Protected Login → Constant-Time Verification
- Stack: Argon2id, per-user salt, TLS transport, constant-time comparison, controlled session issuance
- Security properties: brute-force resistance after breach, safe verification flow, transport confidentiality
These flows are intentionally simple enough to teach and strong enough to guide architecture discussions.
This project exists to support engineering judgment, not replace it.
The goal is to help a reader move from "I know crypto matters" to "I can defend this algorithm choice in an architecture review." That is a different goal from implementing libraries, publishing new research, or certifying production systems.
- prefer algorithms with strong public analysis and meaningful deployment history
- prefer safe defaults over novelty
- treat post-quantum migration as a real planning problem, not marketing language
- show uncertainty explicitly instead of burying it behind a recommendation label
| Level | Meaning |
|---|---|
| Recommended | Strong default for new systems in the stated context |
| Acceptable | Reasonable in bounded scenarios, compatibility needs, or transitional environments |
| Legacy | Still encountered, but not the direction to choose for new systems |
| Research | Interesting, promising, or relevant, but not a safe default for ordinary deployment |
| Avoid | Unsafe, obsolete, or too failure-prone for responsible new use |
Recommendation levels are based on a combination of:
- public standardization status
- maturity of cryptanalysis
- deployment experience
- implementation ecosystem quality
- misuse risk in ordinary engineering contexts
- relevance to current classical and post-quantum threat models
Each algorithm entry is expected to answer more than "what is it?"
It should also answer:
- Why would I choose it?
- Why would I avoid it?
- What assumptions am I making?
- What would make this recommendation change later?
That is why the dataset includes recommendation rationale, assumptions, tradeoffs, estimation methodology, and provenance instead of just names and key sizes.
The project is grounded in:
- NIST FIPS and SP 800 publications
- IETF RFCs
- ISO and national standards where relevant
- academic papers and cryptanalysis literature
- deployment evidence from major protocol and library ecosystems
See docs/data-sources.md and src/data/provenance.ts for the source backbone.
Some choices in cryptography are not pure right-or-wrong decisions. They are judgment calls under changing constraints.
Common examples:
- how aggressively to push post-quantum migration today for systems with different risk horizons and compatibility budgets
- Ed25519 vs ECDSA P-256 in environments where deployment simplicity and regulatory expectations pull in different directions
- ML-DSA vs more conservative hash-based signatures when long-term confidence matters more than size or speed
- Groth16 vs PLONK vs zk-STARKs when proof size, trusted setup assumptions, prover cost, and transparency matter differently
The project takes a conservative view, but it is explicit that some recommendation boundaries are matters of engineering judgment rather than timeless truth.
- this is not an implementation guide down to API calls and safe parameter handling in every language
- this is not a compliance mapping tool
- this is not a live feed of vulnerabilities, audits, or ecosystem incidents
- this is not guaranteed current forever; review freshness matters
- this is still a solo-maintained project
That honesty is part of the trust model, not a weakness in spite of it.
| Capability | What It Gives You |
|---|---|
| Browse by category | 97 algorithms across elliptic curves, encryption, KEM, signatures, hashing, password hashing, ZKPs, MPC, OT/PIR, threshold signatures, and more |
| Compare side by side | Consistent field-by-field comparisons adapted to category-specific metrics |
| Use the decision flowchart | A guided path from problem statement to algorithm recommendation |
| Download justification reports | Markdown output for architecture reviews and design discussion |
| Filter and sort | PQ-safe, standards-track, NIST status, deployment, origin, size, and security dimensions |
| Review hybrid patterns | Classical-plus-PQ constructions for practical migration planning |
| Explore linked demo projects | 68 linked public demos across the mapped categories, with per-category project context in the explainer panels |
| Read safety and architecture guidance | Use-case content, pitfalls, library direction, and system-level flows |
| Category | Examples |
|---|---|
| CSPRNG | CSPRNG (OS), ChaCha20-based DRBG |
| Symmetric Encryption | AES-256-GCM, ChaCha20-Poly1305, XChaCha20-Poly1305 |
| Hashing | SHA-2, SHA-3, BLAKE2b, BLAKE3 |
| MAC | HMAC-SHA-256, CMAC-AES, KMAC-256 |
| KDF | HKDF, Argon2-KDF |
| Password Hashing | Argon2id, bcrypt, scrypt, PBKDF2 |
| Asymmetric Encryption | RSA-OAEP, ECIES |
| KEM | ML-KEM, HQC, Classic McEliece, FrodoKEM |
| Signatures | ML-DSA, FALCON, SLH-DSA, XMSS |
| Threshold Signatures | FROST, GG20 |
| Secret Sharing | Shamir, Feldman VSS, Additive |
| Homomorphic Encryption | TFHE, CKKS, BGV |
| ZKP | Groth16, zk-STARKs, PLONK |
| MPC | SPDZ, ABY, Garbled Circuits |
| OT / PIR | OT, SimplePIR, SealPIR |
| Steganography | LSB, DCT, Spread Spectrum |
| Layer | Technology |
|---|---|
| Framework | Next.js 14 static export |
| Language | TypeScript in strict mode |
| Validation | Zod-based dataset validation |
| Testing | Vitest + Testing Library |
| Styling | Tailwind CSS |
| Deployment | GitHub Pages |
No backend. No accounts. No cookies. No analytics.
The app includes semantic landmarks, ARIA states and labels, keyboard navigation, focus-visible support, reduced-motion handling, touch-friendly controls, and mobile layouts for smaller screens.
git clone https://github.com/systemslibrarian/crypto-compare.git
cd crypto-compare
npm install
npm run devOpen http://localhost:3000.
| Command | Purpose |
|---|---|
npm run dev |
Start the local development server |
npm run build |
Build the static export |
npm run test |
Run the automated test suite |
npm run type-check |
Run the TypeScript checker |
npm run lint |
Run linting |
src/
├── app/ # routes and layout
├── components/ # UI, decision guides, architectures, safety content
├── data/ # algorithm dataset, categories, hybrid patterns, provenance
├── lib/ # comparison logic, validation, keyboard shortcuts
├── types/ # strict TypeScript data models
└── __tests__/ # behavioral and dataset tests
High-value files:
- src/components/CryptoCompare.tsx
- src/components/DecisionFlowchart.tsx
- src/components/UseCaseGuide.tsx
- src/components/SafeUsage.tsx
- src/components/ReferenceArchitectures.tsx
- src/components/DesignPhilosophy.tsx
- src/data/algorithms.ts
- src/data/provenance.ts
Each category in the app links to working demo projects that illustrate the cryptographic concepts in practice.
- Full live crypto-lab index: systemslibrarian.github.io/crypto-lab
- App mapping source of truth: src/data/categories.ts
- Current mapped public demos: 68 (including crypto-lab and non-crypto-lab public repos)
The list below is representative rather than exhaustive.
| Project | Focus |
|---|---|
| Quantum Vault KPQC | Symmetric crypto, KEM, signatures, KDF, MAC, secret sharing, CSPRNG |
| Blind Oracle | Fully homomorphic encryption (TFHE) |
| Silent Tally | Secure multi-party computation |
| FROST Threshold | Threshold signatures (FROST / Ed25519) |
| Patron Shield | Private information retrieval (PIR) |
| Iron Letter | Asymmetric / public-key encryption (ECIES, RSA-OAEP) |
| Shadow Vault | Deniable symmetric encryption (ChaCha20-Poly1305) |
| Dad Mode Morse | Symmetric encryption + digital signatures |
| Corrupted Oracle | CSPRNG backdoor demonstration (Dual_EC_DRBG) |
| ZK Proof Lab | Zero-knowledge proof systems |
| Phantom Vault | Stateless password manager (PBKDF2 + HMAC-DRBG) |
| snow2 | Steganography / covert channels |
| Hybrid Wire | Hybrid post-quantum key exchange (X25519 + ML-KEM-768) |
| Kyber Vault | ML-KEM (CRYSTALS-Kyber) key encapsulation — NIST FIPS 203 |
| Dilithium Seal | ML-DSA (CRYSTALS-Dilithium) post-quantum signatures — NIST FIPS 204 |
| SPHINCS+ Ledger | SLH-DSA (SPHINCS+) hash-based PQ signatures — NIST FIPS 205 |
| Ratchet Wire | Double Ratchet Algorithm (Signal protocol) |
| Shamir Gate | Shamir's Secret Sharing with polynomial visualization |
| Iron Serpent | Serpent-256 block cipher (AES finalist) |
| Dead Sea Cipher | Cryptographic history — Atbash to AES-256-GCM |
| Biham Lens | Differential cryptanalysis (Biham & Shamir, DES) |
| AES Modes | AES modes comparison — ECB, CBC, CTR, GCM, CCM with attacks |
| Format Ward | Format-preserving encryption (FF1, FF3-1) |
| Padding Oracle | CBC padding oracle attack (Vaudenay 2002) |
| Timing Oracle | Timing side-channel attacks and constant-time defenses |
| Curve Lens | Elliptic curve explorer — point arithmetic, ECDH |
| X3DH Wire | X3DH asynchronous key agreement (Signal handshake) |
| BIKE Vault | BIKE code-based post-quantum KEM |
| McEliece Gate | Classic McEliece — oldest post-quantum KEM (1978) |
| HQC Vault | HQC Hamming Quasi-Cyclic post-quantum KEM |
| Noise Pipe | Noise Protocol Framework — handshake patterns + WireGuard |
| Falcon Seal | Falcon NTRU lattice signatures (NIST alternate) |
| Babel Hash | Hash functions — SHA-256, SHA3-256, BLAKE3 with attacks |
| KDF Chain | KDF comparison — HKDF, PBKDF2, scrypt, Argon2id |
| MAC Race | MAC comparison — HMAC, CMAC, Poly1305, GHASH |
| RSA Forge | RSA demo — textbook, OAEP, PSS, live attacks |
| Meow Decoder | Secure optical air-gap file transfer via QR-code GIFs |
See CONTRIBUTING.md.
MIT