why i built pqc-tools

start with what is actually there

qScan looks for candidate uses of cryptography in source, configuration and dependencies. it produces findings that can be reviewed, exported and compared over time. machine-readable formats make those findings useful outside a terminal: a code review, an inventory, an assessment or a migration plan

i wanted the tools to preserve the difference between key exchange and signatures. a use that can expose recorded confidential data has a different urgency and failure mode from a signature used to authenticate an artifact. collapsing both into a single warning makes prioritization harder

the scanner is lexical. it can find patterns worth investigating; it cannot prove that a call executes, that a detector found every use, or that a proposed replacement is correct for the protocol. the project's objectives and scope keep that limitation explicit

make it part of ordinary development

a one-off scan becomes stale. i wanted the same findings to be available where changes happen

the command-line tool supports local inspection. the GitHub Action brings checks into CI, using baselines to distinguish existing findings from new ones. the MCP interface makes the tooling available to coding agents. these surfaces share an engine so they do not each invent a different definition of the same finding

optional model-assisted triage and fix proposals sit apart from the deterministic checks. an explanation can help someone understand a finding, but it should not become the authority that declares its own patch safe. the changes still need review and validation appropriate to the code and protocol

this is also why a readiness score needs context. a useful summary can help track a defined set of findings. a high score cannot establish that an entire application, deployment or organization is quantum-safe

check the replacement as well

finding classical cryptography is one part of the job. checking the proposed replacement is another

Sieve provides a harness for testing other implementations of ML-KEM, ML-DSA and SLH-DSA. it does not implement those cryptographic primitives itself. exact known-answer testing requires supplied official vectors; missing vectors must result in a skipped check, not invented expected values. the Sieve documentation describes that boundary

runtime behavior needs its own evidence too. qProbe adds active checks against authorized TLS and SSH endpoints. a source scan and a completed connection answer different questions, and a probe only describes the endpoint and configuration it actually tested

none of those checks is a substitute for cryptographic review or formal module validation. they give engineers evidence to work with and failure cases to investigate

why the tools are open

i wanted people to be able to inspect the detectors, challenge classifications and reproduce results. a migration recommendation is more useful when the reasoning behind it can be checked

the project uses an Apache-2.0 license, a shared TypeScript core and Node built-ins without third-party runtime dependencies. keeping the runtime dependency set small reduces what has to be maintained and reviewed; it does not remove the need to trust and inspect the tools themselves

the public repository includes the source, package documentation and examples. the liboqs migration walkthrough shows how discovery, a replacement library and verification can fit together

i built pqc-tools because i wanted the research to lead to something a developer could run, question and improve. the useful result is a clearer view of what needs attention, with enough detail to decide what to do next