{"id":50487189,"url":"https://github.com/systemslibrarian/crypto-compare","last_synced_at":"2026-06-01T23:04:40.601Z","repository":{"id":344744885,"uuid":"1182906042","full_name":"systemslibrarian/crypto-compare","owner":"systemslibrarian","description":"Interactive cryptographic algorithm reference — 17 categories, 97 algorithms, 16+ countries. Comparison tool with beginner/advanced modes, PQ-safe filtering, and justification report export.","archived":false,"fork":false,"pushed_at":"2026-04-19T20:29:49.000Z","size":19865,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-04-19T21:08:05.666Z","etag":null,"topics":["aes","cryptographic-algorithms","cryptography","digital-signatures","education","homomorphic-encryption","nist","post-quantum","pqc","reference","typescript","vite","zero-knowledge"],"latest_commit_sha":null,"homepage":"https://crypto-compare.systemslibrarian.dev","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/systemslibrarian.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-03-16T04:29:28.000Z","updated_at":"2026-04-19T20:29:54.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/systemslibrarian/crypto-compare","commit_stats":null,"previous_names":["systemslibrarian/crypto-compare"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/systemslibrarian/crypto-compare","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/systemslibrarian%2Fcrypto-compare","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/systemslibrarian%2Fcrypto-compare/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/systemslibrarian%2Fcrypto-compare/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/systemslibrarian%2Fcrypto-compare/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/systemslibrarian","download_url":"https://codeload.github.com/systemslibrarian/crypto-compare/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/systemslibrarian%2Fcrypto-compare/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33797150,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-01T02:00:06.963Z","response_time":115,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aes","cryptographic-algorithms","cryptography","digital-signatures","education","homomorphic-encryption","nist","post-quantum","pqc","reference","typescript","vite","zero-knowledge"],"created_at":"2026-06-01T23:04:39.806Z","updated_at":"2026-06-01T23:04:40.592Z","avatar_url":"https://github.com/systemslibrarian.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# crypto::compare 🔐\n\n**Cryptographic algorithm decision system for engineers, architects, and technical decision-makers.**\n\n97 algorithms. 17 categories. 97 unique linked public demos. Sourced recommendations. Safe-usage guidance. Reference architectures. Post-quantum migration context.\n\n🌐 **[Live Site →](https://crypto-compare.systemslibrarian.dev/)**\n\n\u003e *So whether you eat or drink or whatever you do, do it all for the glory of God.* — 1 Corinthians 10:31\n\n---\n\n## What This Is\n\ncrypto::compare is a browser-based decision-support tool for choosing cryptographic algorithms responsibly.\n\nIt 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.\n\nThis project helps you:\n- choose algorithms by use case rather than by hype\n- compare primitives side by side using consistent fields\n- understand where recommendations are strong, conditional, or uncertain\n- avoid common cryptographic mistakes before they become system failures\n\nThis project does **not**:\n- implement cryptographic operations\n- certify systems for compliance\n- replace a professional security review\n- protect you from implementation bugs or operational mistakes\n\n---\n\n## Start Here\n\nIf you only spend 30 seconds on this repository, use this path:\n\n1. **Need a decision fast?** Start with **If You're Building X → Use This**.\n2. **Need to compare options?** Use the live comparison table and decision flowchart.\n3. **Need to avoid dangerous mistakes?** Read **Common Pitfalls \u0026 Safe Usage** before touching code.\n\n![TLS and HTTPS data flow visual](public/images/tls-https-data-flow.png)\n\n---\n\n## Why Trust This\n\nThis project tries to earn trust in concrete ways rather than by tone alone.\n\n| Signal | What It Means |\n|--------|----------------|\n| **97 algorithms across 17 categories** | Coverage is broad enough to support real design tradeoffs, not just a curated shortlist |\n| **Per-algorithm provenance** | Entries are backed by standards, cryptanalysis, deployment references, and review dates |\n| **5-level recommendation model** | Recommendations are not binary; they distinguish safe defaults from acceptable, legacy, research, and avoid |\n| **Explicit tradeoffs** | Entries include \"Why not this?\", assumptions, and \"When this changes\" conditions |\n| **Validation and tests** | Dataset validation is enforced with Zod and covered by a substantial automated test suite |\n| **Static architecture** | No backend, no accounts, no telemetry, no hidden recommendation engine |\n\nTrust still has limits here:\n\n- recommendation quality is only as good as the underlying sources and review freshness\n- implementation safety still depends on the library and the surrounding system design\n- there is no institutional backing, external audit, or guaranteed update cadence\n\n### Freshness Snapshot\n\n- provenance entries currently carry review dates spanning **2026-04-18** through **2026-04-18**\n- each algorithm record includes a `lastReviewed` value in the dataset provenance\n- recommendation confidence should drop as that review window gets older relative to new cryptanalysis, standards work, or deployment changes\n\n---\n\n## If You're Building X → Use This\n\nThese are conservative defaults, not universal laws. They are meant to get a capable engineer onto safe ground quickly.\n\n| Building | Recommended Stack | Why It Works | Real-World Pattern | Avoid This | When It Changes |\n|----------|-------------------|--------------|--------------------|------------|-----------------|\n| **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 |\n| **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 |\n| **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 |\n| **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 |\n| **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 |\n| **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 |\n\nThe live tool expands these with detailed stacks, rationale, tradeoffs, and links into specific algorithms.\n\n---\n\n## Crypto Reality\n\nCryptographic 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.\n\nThat also means algorithm choice is only part of the problem.\n\nMost real-world failures happen in implementation and operations:\n- nonce reuse\n- broken key management\n- skipped certificate validation\n- side channels\n- unsafe defaults\n- custom code where a vetted library should have been used\n\n**Do not write your own cryptographic primitives.**\n\nUse established libraries. Treat algorithm selection and implementation quality as separate decisions that both matter.\n\n---\n\n## Common Pitfalls \u0026 Safe Usage\n\nThis section is intentionally direct because crypto mistakes fail hard.\n\n### Critical Rules\n\n| Rule | Why It Matters |\n|------|----------------|\n| **Never reuse a nonce** with AES-GCM or ChaCha20-Poly1305 | Reuse can destroy confidentiality and authenticity guarantees |\n| **Never encrypt without authentication** | Confidentiality without integrity gives attackers room to manipulate ciphertext |\n| **Never use fast general-purpose hashes for passwords** | Password storage needs memory-hard functions like Argon2id, not SHA-256 |\n| **Never use ECB mode** | It leaks structural information about plaintext |\n| **Never hard-code secrets** | Keys in source control or build pipelines eventually leak |\n| **Never roll your own crypto** | Custom primitives and protocols fail in ways that are difficult to detect |\n| **Never disable certificate verification** | That turns TLS into theater |\n\n### Key Management Basics\n\n- generate keys with a CSPRNG, never a general-purpose PRNG\n- separate keys by purpose: encryption, MAC, signing, and derivation keys should not be interchangeable\n- rotate long-lived keys on an explicit policy rather than ad hoc intuition\n- keep secrets in hardware-backed stores or dedicated secret-management systems where possible\n- plan for compromise: revocation, re-issuance, and blast-radius reduction matter as much as initial generation\n\n### What This Tool Does Not Protect Against\n\n- timing leaks, memory-safety bugs, and side-channel vulnerabilities\n- bad protocol composition\n- poor secrets handling and weak operational controls\n- unsafe framework defaults or insecure deployment configuration\n\nChoosing the right primitive helps. It does not make the surrounding system safe by itself.\n\n---\n\n## Recommended Libraries\n\nAlgorithm safety depends heavily on implementation quality. If your codebase touches cryptography directly, prefer mature libraries with strong operational history.\n\n| Category | Primary Direction | Common Options |\n|----------|-------------------|----------------|\n| **General-purpose application crypto** | libsodium | NaCl-family bindings across major languages |\n| **TLS and transport security** | BoringSSL or OpenSSL 3.x | Also language-native TLS stacks built on vetted primitives |\n| **Rust systems** | ring plus rustls where appropriate | Use ecosystem-native wrappers instead of raw bindings where practical |\n| **Post-quantum experimentation and integration** | liboqs and PQClean-derived wrappers | For evaluation and early integration, not blind production use |\n| **Browser crypto** | Web Crypto API | Use native browser primitives rather than hand-rolled JavaScript |\n| **Go services** | `crypto/*` and `x/crypto` | Prefer standard-library and official extensions |\n| **JVM / .NET ecosystems** | Bouncy Castle where needed | Especially when broader algorithm coverage is required |\n\n### Why These Libraries\n\n| Library | Why It Is Trusted | Seen In |\n|---------|-------------------|---------|\n| **libsodium** | Misuse-resistant API design and broad language support | Modern application crypto, sealed boxes, message encryption |\n| **BoringSSL** | Hardened operational pedigree and large-scale deployment | Chrome, Android, large internet-facing systems |\n| **OpenSSL 3.x** | Deep ecosystem penetration and compliance relevance | Servers, appliances, enterprise deployments |\n| **ring** | Minimalist surface area and strong Rust adoption | Rust TLS and security-sensitive infrastructure |\n| **liboqs** | Tracks mainstream PQ standardization work closely | PQ evaluation and migration prototypes |\n| **Web Crypto API** | Native browser implementation path | Web apps that need client-side cryptography |\n\nThe right pattern is usually: **choose a sound algorithm here, then implement it through one of these libraries instead of custom code.**\n\n---\n\n## Reference Architectures\n\nThese are not complete protocols. They are system-level reference patterns that show how the primitives fit together.\n\n### Secure Messaging\n\n```text\nIdentity Keys → Hybrid Session Setup → HKDF / Ratchet → AEAD Message Encryption → Transcript / State Binding\n```\n\n- **Stack:** identity signatures, hybrid key establishment, HKDF-derived message keys, AEAD for messages\n- **Security properties:** confidentiality, forward secrecy, compartmentalization, authenticated peer identity\n\n### Web API / TLS-Style Transport\n\n```text\nClientHello → Certificate Validation → Ephemeral Key Agreement → Session Keys → AEAD Records\n```\n\n- **Stack:** TLS 1.3, ephemeral key agreement, AEAD record protection, authenticated certificates\n- **Security properties:** confidentiality, integrity, server authentication, replay resistance, forward secrecy\n\n### File Encryption System\n\n```text\nPassphrase or Master Key → Strong KDF → Per-File Key → AEAD Encryption → Store Ciphertext + Metadata\n```\n\n- **Stack:** Argon2id or master-key input, HKDF-style separation, AES-256-GCM or XChaCha20-Poly1305\n- **Security properties:** confidentiality, integrity, limited blast radius, portability of encrypted artifacts\n\n### Authentication System\n\n```text\nPassword → Argon2id → Stored Hash + Salt + Parameters → TLS-Protected Login → Constant-Time Verification\n```\n\n- **Stack:** Argon2id, per-user salt, TLS transport, constant-time comparison, controlled session issuance\n- **Security properties:** brute-force resistance after breach, safe verification flow, transport confidentiality\n\nThese flows are intentionally simple enough to teach and strong enough to guide architecture discussions.\n\n---\n\n## Design Philosophy \u0026 Trust Model\n\n### Purpose\n\nThis project exists to support engineering judgment, not replace it.\n\nThe 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.\n\n### Conservative Recommendation Philosophy\n\n- prefer algorithms with strong public analysis and meaningful deployment history\n- prefer safe defaults over novelty\n- treat post-quantum migration as a real planning problem, not marketing language\n- show uncertainty explicitly instead of burying it behind a recommendation label\n\n### How Recommendation Levels Work\n\n| Level | Meaning |\n|-------|---------|\n| **Recommended** | Strong default for new systems in the stated context |\n| **Acceptable** | Reasonable in bounded scenarios, compatibility needs, or transitional environments |\n| **Legacy** | Still encountered, but not the direction to choose for new systems |\n| **Research** | Interesting, promising, or relevant, but not a safe default for ordinary deployment |\n| **Avoid** | Unsafe, obsolete, or too failure-prone for responsible new use |\n\nRecommendation levels are based on a combination of:\n- public standardization status\n- maturity of cryptanalysis\n- deployment experience\n- implementation ecosystem quality\n- misuse risk in ordinary engineering contexts\n- relevance to current classical and post-quantum threat models\n\n### Transparency by Design\n\nEach algorithm entry is expected to answer more than \"what is it?\"\n\nIt should also answer:\n- **Why would I choose it?**\n- **Why would I avoid it?**\n- **What assumptions am I making?**\n- **What would make this recommendation change later?**\n\nThat is why the dataset includes recommendation rationale, assumptions, tradeoffs, estimation methodology, and provenance instead of just names and key sizes.\n\n### Data Sources\n\nThe project is grounded in:\n- NIST FIPS and SP 800 publications\n- IETF RFCs\n- ISO and national standards where relevant\n- academic papers and cryptanalysis literature\n- deployment evidence from major protocol and library ecosystems\n\nSee [docs/data-sources.md](/workspaces/crypto-compare/docs/data-sources.md) and [src/data/provenance.ts](/workspaces/crypto-compare/src/data/provenance.ts) for the source backbone.\n\n### Where Reasonable Experts May Disagree\n\nSome choices in cryptography are not pure right-or-wrong decisions. They are judgment calls under changing constraints.\n\nCommon examples:\n- **how aggressively to push post-quantum migration today** for systems with different risk horizons and compatibility budgets\n- **Ed25519 vs ECDSA P-256** in environments where deployment simplicity and regulatory expectations pull in different directions\n- **ML-DSA vs more conservative hash-based signatures** when long-term confidence matters more than size or speed\n- **Groth16 vs PLONK vs zk-STARKs** when proof size, trusted setup assumptions, prover cost, and transparency matter differently\n\nThe project takes a conservative view, but it is explicit that some recommendation boundaries are matters of engineering judgment rather than timeless truth.\n\n### Honest Limitations\n\n- this is not an implementation guide down to API calls and safe parameter handling in every language\n- this is not a compliance mapping tool\n- this is not a live feed of vulnerabilities, audits, or ecosystem incidents\n- this is not guaranteed current forever; review freshness matters\n- this is still a solo-maintained project\n\nThat honesty is part of the trust model, not a weakness in spite of it.\n\n---\n\n## What You Can Do In The App\n\n| Capability | What It Gives You |\n|-----------|--------------------|\n| **Browse by category** | 97 algorithms across elliptic curves, encryption, KEM, signatures, hashing, password hashing, ZKPs, MPC, OT/PIR, threshold signatures, and more |\n| **Compare side by side** | Consistent field-by-field comparisons adapted to category-specific metrics |\n| **Use the decision flowchart** | A guided path from problem statement to algorithm recommendation |\n| **Download justification reports** | Markdown output for architecture reviews and design discussion |\n| **Filter and sort** | PQ-safe, standards-track, NIST status, deployment, origin, size, and security dimensions |\n| **Review hybrid patterns** | Classical-plus-PQ constructions for practical migration planning |\n| **Explore linked demo projects** | 97 unique linked public demos across the mapped categories, with per-category project context in the explainer panels |\n| **Read safety and architecture guidance** | Use-case content, pitfalls, library direction, and system-level flows |\n\n### Coverage Snapshot\n\n| Category | Examples |\n|----------|----------|\n| CSPRNG | CSPRNG (OS), ChaCha20-based DRBG |\n| Symmetric Encryption | AES-256-GCM, ChaCha20-Poly1305, XChaCha20-Poly1305 |\n| Hashing | SHA-2, SHA-3, BLAKE2b, BLAKE3 |\n| MAC | HMAC-SHA-256, CMAC-AES, KMAC-256 |\n| KDF | HKDF, Argon2-KDF |\n| Password Hashing | Argon2id, bcrypt, scrypt, PBKDF2 |\n| Asymmetric Encryption | RSA-OAEP, ECIES |\n| KEM | ML-KEM, HQC, Classic McEliece, FrodoKEM |\n| Signatures | ML-DSA, FALCON, SLH-DSA, XMSS |\n| Threshold Signatures | FROST, GG20 |\n| Secret Sharing | Shamir, Feldman VSS, Additive |\n| Homomorphic Encryption | TFHE, CKKS, BGV |\n| ZKP | Groth16, zk-STARKs, PLONK |\n| MPC | SPDZ, ABY, Garbled Circuits |\n| OT / PIR | OT, SimplePIR, SealPIR |\n| Steganography | LSB, DCT, Spread Spectrum |\n\n---\n\n## Tech Stack\n\n| Layer | Technology |\n|-------|-----------|\n| Framework | Next.js 14 static export |\n| Language | TypeScript in strict mode |\n| Validation | Zod-based dataset validation |\n| Testing | Vitest + Testing Library |\n| Styling | Tailwind CSS |\n| Deployment | GitHub Pages |\n\nNo backend. No accounts. No cookies. No analytics.\n\n### Accessibility and Responsiveness\n\nThe 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.\n\n---\n\n## Getting Started\n\n```bash\ngit clone https://github.com/systemslibrarian/crypto-compare.git\ncd crypto-compare\nnpm install\nnpm run dev\n```\n\nOpen \u003chttp://localhost:3000\u003e.\n\n| Command | Purpose |\n|---------|---------|\n| `npm run dev` | Start the local development server |\n| `npm run build` | Build the static export |\n| `npm run test` | Run the automated test suite |\n| `npm run test:demos` | Run demo-sync and demo-resource integrity tests |\n| `npm run type-check` | Run the TypeScript checker |\n| `npm run lint` | Run linting |\n| `npm run check:demos` | Compare local demo mappings to the live crypto-lab catalog |\n| `npm run check:demos:json` | Output demo sync report as JSON for automation |\n| `npm run check:demos:report` | Write demo sync JSON report to demo-sync-report.json |\n| `npm run validate:full` | Run dataset validation plus strict live demo sync check |\n\nOffline audit option:\nRun `npx tsx scripts/check-demo-sync.ts --live-html-path=/tmp/crypto-lab.html --strict` to compare against a saved catalog snapshot.\nAdvanced options:\nUse `--timeout-ms=\u003cn\u003e` and `--max-retries=\u003cn\u003e` to tune network behavior for constrained CI or unreliable connections.\nUse `--help` to print all available flags.\n\n---\n\n## Project Structure\n\n```text\nsrc/\n├── app/                      # routes and layout\n├── components/               # UI, decision guides, architectures, safety content\n├── data/                     # algorithm dataset, categories, hybrid patterns, provenance\n├── lib/                      # comparison logic, validation, keyboard shortcuts\n├── types/                    # strict TypeScript data models\n└── __tests__/                # behavioral and dataset tests\n```\n\nHigh-value files:\n\n- [src/components/CryptoCompare.tsx](/workspaces/crypto-compare/src/components/CryptoCompare.tsx)\n- [src/components/DecisionFlowchart.tsx](/workspaces/crypto-compare/src/components/DecisionFlowchart.tsx)\n- [src/components/UseCaseGuide.tsx](/workspaces/crypto-compare/src/components/UseCaseGuide.tsx)\n- [src/components/SafeUsage.tsx](/workspaces/crypto-compare/src/components/SafeUsage.tsx)\n- [src/components/ReferenceArchitectures.tsx](/workspaces/crypto-compare/src/components/ReferenceArchitectures.tsx)\n- [src/components/DesignPhilosophy.tsx](/workspaces/crypto-compare/src/components/DesignPhilosophy.tsx)\n- [src/data/algorithms.ts](/workspaces/crypto-compare/src/data/algorithms.ts)\n- [src/data/provenance.ts](/workspaces/crypto-compare/src/data/provenance.ts)\n\n---\n\n## Related Projects\n\nEach category in the app links to working demo projects that illustrate the cryptographic concepts in practice.\n\n- Full live crypto-lab index: [crypto-lab.systemslibrarian.dev/crypto-lab](https://crypto-lab.systemslibrarian.dev/crypto-lab/)\n- App mapping source of truth: [src/data/demoResources.ts](/workspaces/crypto-compare/src/data/demoResources.ts)\n- Current mapped crypto-lab demos: **97** unique slugs (kept in sync with the live crypto-lab catalog)\n\nThe list below is representative rather than exhaustive.\n\n| Project | Focus |\n|---------|-------|\n| [Quantum Vault KPQC](https://github.com/systemslibrarian/crypto-lab-quantum-vault-kpqc) | Symmetric crypto, KEM, signatures, KDF, MAC, secret sharing, CSPRNG |\n| [Blind Oracle](https://github.com/systemslibrarian/crypto-lab-blind-oracle) | Fully homomorphic encryption (TFHE) |\n| [Silent Tally](https://github.com/systemslibrarian/crypto-lab-silent-tally) | Secure multi-party computation |\n| [FROST Threshold](https://github.com/systemslibrarian/crypto-lab-frost-threshold) | Threshold signatures (FROST / Ed25519) |\n| [Patron Shield](https://github.com/systemslibrarian/crypto-lab-patron-shield) | Private information retrieval (PIR) |\n| [Iron Letter](https://github.com/systemslibrarian/crypto-lab-iron-letter) | Asymmetric / public-key encryption (ECIES, RSA-OAEP) |\n| [Shadow Vault](https://github.com/systemslibrarian/crypto-lab-shadow-vault) | Deniable symmetric encryption (ChaCha20-Poly1305) |\n| [Dad Mode Morse](https://github.com/systemslibrarian/dad-mode-morse2) | Symmetric encryption + digital signatures |\n| [Corrupted Oracle](https://github.com/systemslibrarian/crypto-lab-corrupted-oracle) | CSPRNG backdoor demonstration (Dual_EC_DRBG) |\n| [ZK Proof Lab](https://github.com/systemslibrarian/crypto-lab-zk-proof-lab) | Zero-knowledge proof systems |\n| [Phantom Vault](https://github.com/systemslibrarian/crypto-lab-phantom-vault) | Stateless password manager (PBKDF2 + HMAC-DRBG) |\n| [snow2](https://github.com/systemslibrarian/snow2) | Steganography / covert channels |\n| [Hybrid Wire](https://github.com/systemslibrarian/crypto-lab-hybrid-wire) | Hybrid post-quantum key exchange (X25519 + ML-KEM-768) |\n| [Kyber Vault](https://github.com/systemslibrarian/crypto-lab-kyber-vault) | ML-KEM (CRYSTALS-Kyber) key encapsulation — NIST FIPS 203 |\n| [Dilithium Seal](https://github.com/systemslibrarian/crypto-lab-dilithium-seal) | ML-DSA (CRYSTALS-Dilithium) post-quantum signatures — NIST FIPS 204 |\n| [SPHINCS+ Ledger](https://github.com/systemslibrarian/crypto-lab-sphincs-ledger) | SLH-DSA (SPHINCS+) hash-based PQ signatures — NIST FIPS 205 |\n| [Ratchet Wire](https://github.com/systemslibrarian/crypto-lab-ratchet-wire) | Double Ratchet Algorithm (Signal protocol) |\n| [Shamir Gate](https://github.com/systemslibrarian/crypto-lab-shamir-gate) | Shamir's Secret Sharing with polynomial visualization |\n| [Iron Serpent](https://github.com/systemslibrarian/crypto-lab-iron-serpent) | Serpent-256 block cipher (AES finalist) |\n| [Dead Sea Cipher](https://github.com/systemslibrarian/crypto-lab-dead-sea-cipher) | Cryptographic history — Atbash to AES-256-GCM |\n| [Biham Lens](https://github.com/systemslibrarian/crypto-lab-biham-lens) | Differential cryptanalysis (Biham \u0026 Shamir, DES) |\n| [AES Modes](https://github.com/systemslibrarian/crypto-lab-aes-modes) | AES modes comparison — ECB, CBC, CTR, GCM, CCM with attacks |\n| [Format Ward](https://github.com/systemslibrarian/crypto-lab-format-ward) | Format-preserving encryption (FF1, FF3-1) |\n| [Padding Oracle](https://github.com/systemslibrarian/crypto-lab-padding-oracle) | CBC padding oracle attack (Vaudenay 2002) |\n| [Timing Oracle](https://github.com/systemslibrarian/crypto-lab-timing-oracle) | Timing side-channel attacks and constant-time defenses |\n| [Curve Lens](https://github.com/systemslibrarian/crypto-lab-curve-lens) | Elliptic curve explorer — point arithmetic, ECDH |\n| [X3DH Wire](https://github.com/systemslibrarian/crypto-lab-x3dh-wire) | X3DH asynchronous key agreement (Signal handshake) |\n| [BIKE Vault](https://github.com/systemslibrarian/crypto-lab-bike-vault) | BIKE code-based post-quantum KEM |\n| [McEliece Gate](https://github.com/systemslibrarian/crypto-lab-mceliece-gate) | Classic McEliece — oldest post-quantum KEM (1978) |\n| [HQC Vault](https://github.com/systemslibrarian/crypto-lab-hqc-vault) | HQC Hamming Quasi-Cyclic post-quantum KEM |\n| [Noise Pipe](https://github.com/systemslibrarian/crypto-lab-noise-pipe) | Noise Protocol Framework — handshake patterns + WireGuard |\n| [Falcon Seal](https://github.com/systemslibrarian/crypto-lab-falcon-seal) | Falcon NTRU lattice signatures (NIST alternate) |\n| [Babel Hash](https://github.com/systemslibrarian/crypto-lab-babel-hash) | Hash functions — SHA-256, SHA3-256, BLAKE3 with attacks |\n| [KDF Chain](https://github.com/systemslibrarian/crypto-lab-kdf-chain) | KDF comparison — HKDF, PBKDF2, scrypt, Argon2id |\n| [MAC Race](https://github.com/systemslibrarian/crypto-lab-mac-race) | MAC comparison — HMAC, CMAC, Poly1305, GHASH |\n| [RSA Forge](https://github.com/systemslibrarian/crypto-lab-rsa-forge) | RSA demo — textbook, OAEP, PSS, live attacks |\n| [Meow Decoder](https://github.com/systemslibrarian/meow-decoder) | Secure optical air-gap file transfer via QR-code GIFs |\n\n---\n\n## Contributing\n\nSee [CONTRIBUTING.md](/workspaces/crypto-compare/CONTRIBUTING.md).\n\n---\n\n[GitHub: systemslibrarian](https://github.com/systemslibrarian)\n\n---\n\n## License\n\nMIT\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsystemslibrarian%2Fcrypto-compare","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsystemslibrarian%2Fcrypto-compare","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsystemslibrarian%2Fcrypto-compare/lists"}