{ "markdown": "# qrp-mcp\n\n\n\n**Every signature in your wallet, contract and validator rests on elliptic-curve cryptography.\nA large quantum computer breaks it. This tells your AI agent exactly where yours is.**\n\nAn MCP server that scans a local directory for cryptography that Shor's algorithm defeats —\nsecp256k1, Ed25519, BLS, Schnorr, RSA — plus weak primitives and CI signing commands, and\nclassifies each one: broken by a quantum computer, post-quantum, or neither.\n\n**Everything runs on your machine.** No network calls, no account, no API key, nothing\nuploaded. A tool that reads your keys' surroundings has no business phoning home, so this one\nmakes zero outbound connections — enforced by a test, not promised in a paragraph.\n\n## Why this matters for chains and wallets\n\nBitcoin and Ethereum authenticate with **ECDSA over secp256k1**. Solana, Cardano and Polkadot\nuse **Ed25519**. Ethereum's consensus layer aggregates with **BLS12-381**. Taproot adds\n**Schnorr**.\n\nAll four are public-key schemes whose security rests on discrete-log hardness — and all four\nfall to the same quantum algorithm. The practical consequence is specific: **once a public key\nis exposed, the private key becomes derivable.** Reused addresses, on-chain public keys,\nand long-lived validator keys are where that exposure already exists today.\n\nNone of this is a prediction about dates. It is an inventory question: *which of my code paths\nsign with what?* That question has an answer right now, and this tool gives it.\n\n## Quick start\n\nAdd it to your MCP client — no installation step, `uvx` fetches and runs it:\n\n```json\n{\n \"mcpServers\": {\n \"qrp\": {\n \"command\": \"uvx\",\n \"args\": [\"qrp-mcp\"]\n }\n }\n}\n```\n\nThen ask your agent:\n\n> Scan ~/code/my-protocol for quantum-vulnerable cryptography.\n\n### As a Claude Code plugin\n\nThe same server, packaged with a skill, so there is no config file to edit:\n\n```\n/plugin marketplace add StanimirTenev/qrp-mcp\n/plugin install qrp@quantumreadiness\n```\n\nThen `/qrp:pqc-scan` in any project. Both routes need [`uv`](https://docs.astral.sh/uv/) on\nyour PATH, since `uvx` is what fetches and runs the server.\n\n## Tools\n\n| Tool | What it does |\n| --- | --- |\n| `scan_repo(path)` | Scans a directory's source, CI/CD configs and infrastructure-as-code; returns findings and a summary |\n| `list_algorithms()` | The algorithm families the server recognises and how each is classified |\n\n## What it looks at\n\n**Chain and wallet code** — `secp256k1`, `ecrecover`, ethers, web3, bitcoinjs, `ECPair`,\n`btcec`, tweetnacl, `@solana/web3.js`, `solana_program`, `bls12-381`, blst, `@chainsafe/bls`,\nBIP340/Taproot Schnorr. Solidity (`.sol`), Rust (`.rs`), Move and Cairo are scanned alongside\nPython, Go, Java, JS/TS, Ruby, PHP, C/C++/C# — headers included — PowerShell, Perl and shell.\n\n**Classical crypto anywhere else** — RSA, DSA, DH, ECDSA and elliptic-curve usage, plus MD5,\nSHA-1, RC4 and DES/3DES.\n\n**Hybrids and composites** — the RFC 10024 TLS groups `X25519MLKEM768`,\n`SecP256r1MLKEM768` and `SecP384r1MLKEM1024`, OpenSSH 10's default `mlkem768x25519-sha256`,\nand the composite certificate algorithms of draft-ietf-lamps-pq-composite-sigs such as\n`id-MLDSA44-RSA2048-PSS-SHA256`. A hybrid holds if either half holds, so the post-quantum\nscheme leads — and the classical half is carried in `also_present` rather than dropped, since\nit is the component Shor breaks.\n\n**Post-quantum schemes, by family** — ML-KEM, ML-DSA, SLH-DSA, Falcon (FN-DSA), NTRU,\nClassic McEliece, BIKE, HQC, FrodoKEM, XMSS, and the stateful LMS/HSS of SP 800-208 that\nCNSA 2.0 requires for firmware signing. The nine schemes NIST advanced to its third\nadditional-signatures round in May 2026 — FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA,\nSQIsign, UOV — are recognised as candidates, and CROSS as dropped from that process.\n\nEach carries the mathematical family it rests on (structured or unstructured lattice,\ncode-based, hash-based, isogeny-based, multivariate, symmetric-based) and where it stands:\nstandardised, selected, candidate, withdrawn, eliminated or broken. SIKE is reported as broken\nand HAWK as withdrawn rather than counted as quantum-resistant — \"post-quantum\" is a category,\nnot an assessment.\n\n**Certificates and keys** — `.pem`, `.der`, `.crt`, `.cer`, `.cert`, `.csr`, `.key`, `.pub`,\n`.p12`, `.pfx`. Algorithms are resolved from the object identifiers inside the DER and from\nPEM labels and OpenSSH key types, and private key material is reported separately. This does\nnot parse X.509: it keeps only the identifiers already in the classifier, so a malformed\ncertificate yields nothing rather than nonsense.\n\n**Configuration** — `nginx.conf`, `sshd_config`, `openssl.cnf`, `swanctl.conf`, `.ini`,\n`.toml`, `.properties`, and any YAML that is not a manifest. This is where a TLS or SSH hybrid\ngroup is chosen: `X25519MLKEM768` and `mlkem768x25519-sha256` are almost never strings in code.\nIKE proposal syntax is read here too — `ecp384` is NIST P-384, `modp2048` is group 14.\n\n**Quantum-resistant mechanisms, not only algorithms** — RFC 8784 mixes a postquantum preshared\nkey into IKEv2 key derivation, so a tunnel resists a quantum adversary with no post-quantum\nalgorithm present. A scanner matching algorithm names cannot see that by construction, and\nwould report a protected deployment as `classical_only`. PPK is matched by the directives that\nswitch it on and classified as `quantum_resistant_mechanism` — deliberately not `pqc_ready`,\nbecause a preshared key is not ML-KEM. Whether it holds depends on the entropy of the key and\non out-of-band distribution, neither of which is visible in a file, and the finding says so.\n\n**CI/CD pipelines** — signing commands such as `gpg --sign`, `cosign sign`, `signtool`,\n`jarsigner`, `codesign`.\n\n**Infrastructure as code** — Terraform and Kubernetes key algorithms, and private key material\ncommitted by mistake.\n\nReal run against [OpenZeppelin's contracts](https://github.com/OpenZeppelin/openzeppelin-contracts)\n(711 files, about five seconds):\n\n```json\n{\n \"detected_algorithms\": [\"ECDSA\", \"RSA\"],\n \"summary\": {\n \"quantum_vulnerable_count\": 2,\n \"pqc_ready_count\": 0,\n \"highest_severity\": \"high\",\n \"pqc_readiness\": \"classical_only\"\n }\n}\n```\n\n## Why deterministic\n\nThere is no LLM inside this tool. The same input always produces the same output, and every\nfinding points at a file and a line you can open yourself.\n\nThat is the point of handing it to an agent: **the agent brings the language, the tool brings\nthe truth.** An agent guessing about your signing code is worse than nothing; an agent reading\na deterministic inventory can actually reason about it.\n\n## What it is not\n\nIt reads source, configuration, CI pipelines, infrastructure-as-code and Kubernetes\nmanifests. It does not read documentation, binaries or images.\n\nEvery file under the path is accounted for in one of three ways: **scanned**, **unreadable**,\nor **skipped because the tool does not claim that type** — the last counted by extension, so\nthe coverage figure has a base. `files_scanned + unreadable_files + files_skipped_by_type`\nalways equals `files_present`. A scan that read seven files out of nine is a different report\nfrom one that read seven out of four hundred, and only one of them is worth trusting.\n\nA **free inventory tool**, not a readiness assessment. It deliberately does not do:\n\n- risk scoring or prioritisation,\n- migration planning,\n- network or host scanning, or reading a system certificate store,\n- tracking change over time.\n\nThose live in the [Quantum Readiness Platform](https://quantumreadiness.eu), the product this\ntool is extracted from. Nothing here is crippled to push you there — what it does, it does\ncompletely.\n\nIt also does not tell you that you are about to be hacked. It tells you what you are using.\n\n## License\n\nApache-2.0.\n", "bytes": 7863, "sha": "3a96bdc5349a08ededa5dfe2863781971ca84ceb456b72a987fce4d771c1dff3", "repo_slug": "stanimirtenev/qrp-mcp", "fonte": "repo", "truncated": false, "api": "https://agentalog.com/api/listings/mcp_eu_quantumreadiness_qrp_mcp_e750f97d/readme" }