# C2SP/wycheproof: the cryptographic test vectors that moved the burden off library authors

> A community managed repository of JSON test vectors, each paired with a JSON schema that CI enforces, covering the post-quantum algorithms alongside AES-GCM and ECDSA.

**C2SP/wycheproof** — Project Wycheproof tests crypto libraries against known attacks.

- Repository: https://github.com/C2SP/wycheproof
- Stars: 3,119 · Forks: 334
- Language: Go
- License: Apache-2.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/c2sp-wycheproof

## A data repository, not a test suite

The opening paragraph sets the scope precisely. Project Wycheproof is a community managed repository of test vectors that cryptography library developers can use to test against known attacks, specification inconsistencies and other implementation bugs.

The mechanism is deliberately narrow. Test vectors are maintained as JSON test vector data, with accompanying JSON schema files that document the structure of that data. No code, no language bindings, no build step for consumers. What you get is a directory of JSON files and a directory of schemas describing them.

That constraint is the point, and the README explains why later on in a way that reframes the whole project. Historically Wycheproof included test harnesses for Java and JavaScript implementations that tested attacks directly against those implementations. Since transitioning to community support, those harnesses have been removed, and they exist only in git history at commit `cd27d64`.

The reasoning given for removing them is a security argument rather than a maintenance-budget one. Testing third party cryptography libraries directly means flaws are only uncovered after they have been committed, and potentially released, by the projects under test. Vectors instead get consumed by the library's own CI, which catches flaws before they can become CVEs, tests new features immediately, and spreads the maintenance burden so the Wycheproof maintainers can concentrate on vectors rather than tracking downstream development across many projects.

## Coverage runs from AES-GCM to ML-DSA

The algorithm list is the best single answer to whether this repository is relevant to you, and it has widened well past the classics.

On the symmetric and AEAD side: AEGIS, AES-EAX, AES-FF1, AES-GCM, AES-SIV, ARIA, Camellia, ChaCha20-Poly1305, XChaCha20-Poly1305, ASCON v1.2 AEAD covering Ascon-128, Ascon-128a and Ascon-80pq marked pre-standardization, NIST SP 800-232 Ascon-AEAD128, SM4, SipHash, KMAC, VMAC and MORUS. Chunked encryption is listed as Cobblestone, and there is a C2SP specification link for it.

On signatures and key agreement: DSA, ECDSA, EdDSA, ECDH, DHIES, ECIES, SEED, RSA with its own doc page, HKDF, HMAC, PBKDF2, X25519 and X448.

And then the post-quantum entries, which is where the list has clearly moved: BLS-12-381, ML-KEM which is CRYSTALS-Kyber, and ML-DSA which is CRYSTALS-Dilithium, with a dedicated doc page.

Several algorithms link to per-algorithm documentation, including chunked encryption, DH, DSA, ECDH, RSA and ML-DSA. That pattern suggests the coverage is not uniformly deep, and the natural question for a given algorithm is whether the vectors are exhaustive or a representative subset.

What the vectors are for is stated as detecting whether a library is vulnerable to many attacks, with invalid curve attacks, biased nonces in digital signature schemes, and all of Bleichenbacher's attacks named explicitly, and the README claims over 80 test cases along with many more.

## Schemas enforced in CI are the load-bearing detail

Because this is a JSON data repository with no consumer code, the only thing standing between a typo and a silently weakened vector set is schema validation. That is handled explicitly.

The README's guidance on documentation is to prefer referencing the schema files in `schemas/`, since those are tested in CI to ensure vector file contents match their advertised schema. The link points at a vectorlint workflow. Older documentation for files, formats and types exists in `doc/`, but is described as not necessarily in-sync with the current test vector state, which is an unusually direct warning about the project's own docs and worth respecting.

The module file shows the tooling behind that workflow. It is a small dependency set, and both JSON schema libraries are present.

```go
module github.com/c2sp/wycheproof

go 1.26.4

require (
	filippo.io/edwards25519 v1.1.0
	github.com/atombender/go-jsonschema v0.22.0
	github.com/santhosh-tekuri/jsonschema/v6 v6.0.1
)
```

`atombender/go-jsonschema` generates code from schemas, `santhosh-tekuri/jsonschema/v6` validates them, and `filippo.io/edwards25519` is there because Ed25519 test vectors involve curve arithmetic that needs exact big integer behaviour. The remaining seven are indirect dependencies of the schema tooling, none of which is part of the vector data itself.

The tree also has `vectorgen/` for generation, `tools/` for the tooling, `testvectors.go` at the root, `CONTRIBUTING.md`, a `composer.json`, and a `doc/` directory. Notably `doc/bugs.md` is pointed at from the FAQ as the place to read about notable historic bugs found using Wycheproof harnesses or vector data.

## The testvectors_v1 migration is the one thing to check first

The FAQ answers a question that catches people out, which is where the `testvectors/` directory went. The answer is that the `testvectors/` and `testvectors_v1/` directories have recently been combined into a single unified directory with one consistent approach to schemas.

The escape hatch is explicit. Users who need the original v0 vector data can clone from the `wycheproof-v0-vectors` tag, though they are encouraged to consider updating to use `testvectors_v1/` for future updates. If specific features or test coverage from the old directory are missing in the new one, the instruction is to open an issue describing the need.

So the current tree shows `testvectors_v1/` and `schemas/` alongside the Go tooling, and the practical advice for an integrator is to pin deliberately. If your build needs a stable set of vectors for a given algorithm, a release tag is the right anchor. If you want current coverage, the default branch is, at the cost of tracking a directory layout that the project has already moved once.

The five-step getting started sequence is written for the same audience. Clone the repository, optionally as a git submodule or with automation to track changes over time. Write, or generate from the schema files, code to load the vector data for your language. Map the inputs and outputs of your crypto API back to what the vectors provide. Iterate through applicable vectors comparing your results to expected. And wire the whole thing into continuous integration so tests run for all new contributions and changes.

## Twenty downstream projects, named without ordering

The FAQ on adopters is the most persuasive paragraph in the README, because it is a list of projects with an explicit invitation to be added to it.

The list runs OpenSSL, BoringSSL, aws-lc, LibreSSL and NSS on the native side; pyca/cryptography, Botan, Go cryptography, swift-crypto, RustCrypto, Graviola, Tink and PyCryptdome on the library side; and OpenTitan, Zig, liboqs, bc-rust and leancrypto among the language runtimes and efforts built on top of them.

Twenty names, in no particular order, covering four languages and both a browser engine and a hardware root of trust. That spread explains why the data is implementation-agnostic. A vector that only expressed an attack through one language's API shape would not be usable across this range.

It also explains the JSON-plus-schema decision. A C library, a Rust crate and a Python module all need to read the same vectors, and JSON with a published schema is the lowest common denominator that still carries enough structure to validate.

For context on scale: 3,111 stars, 333 forks, 17 open issues, Apache-2.0 licensed, Go as the language of the tooling, `main` as the default branch, not archived, and a last push on 2026-09-02. No tagged releases are published beyond the `wycheproof-v0-vectors` tag referenced in the FAQ.

The naming story is also on the page. Wycheproof is named after Mount Wycheproof, described as the smallest mountain in the world, and the stated motivation was to have a goal that is achievable. The smaller the mountain, the more likely it is to be able to climb it. That is a fitting description of a project that has just handed its remaining work to the people best placed to do it.

## What revitalization means in practice

The Development Priorities section is short and says something a reader should not skip. The project is in the process of revitalizing development and maintenance as a C2SP project with a renewed focus on the test vector data, and the immediate priority is adding additional algorithm and test case coverage to that data.

So the direction is unambiguous. Coverage is the goal, breadth first. Nothing in that section promises new harnesses, new integrations or a new format, and the removal of the harnesses plus the schema-enforcement emphasis both point the same way.

What this means for a consumer is that the value of the repository will show up as the algorithm you care about getting added, rather than as tooling getting easier. If your algorithm is on the list, the work for you is the CI integration and the v1 directory migration. If it is not, the contribution path is the one the README describes: pull requests for new test vector data and algorithms, with `CONTRIBUTING.md` as the reference and GitHub issues for requesting new tests.

The remaining gap worth naming is depth. The README claims over 80 test cases and many more attacks, across more than thirty algorithms. That average is thin by construction, and the per-algorithm doc pages exist partly because coverage is uneven. The vectors are a floor for your test suite, not a substitute for one.

## Conclusion

Wycheproof's current form is a data project with a governance story attached, and both halves matter. The vectors span symmetric ciphers, signatures, key agreement and the post-quantum algorithms that ML-KEM and ML-DSA names reflect, and the schema-plus-CI pairing means a malformed vector cannot quietly land. What makes the recent direction worth knowing is the removal of the language-specific harnesses and the move toward implementation-agnostic vectors that downstream projects consume in their own CI, which pushes bug discovery earlier and distributes the maintenance load. For a reader deciding whether to depend on it, check three things: whether your algorithm is in the coverage list, whether the schema in `schemas/` matches the shape your language can parse, and whether the `testvectors_v1/` migration affects you. The adopter list on the README is long enough that the answer to the last question is usually fine.

## FAQ

### What is Project Wycheproof used for?

It is a repository of JSON test vectors that cryptography library developers use to check their implementations against known attacks, specification inconsistencies and implementation bugs. The vectors are paired with JSON schema files that are validated in CI, so a vector file whose contents do not match its advertised schema fails the build.

### Which cryptography libraries and projects use Wycheproof test vectors?

The README names around twenty, including OpenSSL, BoringSSL, aws-lc, LibreSSL, NSS, pyca/cryptography, Botan, Go cryptography, swift-crypto, RustCrypto, Tink, OpenTitan, Zig and liboqs. Projects that use the vectors are invited to open a pull request to be added to the list.

### What happened to the Wycheproof test harnesses and the testvectors directory?

The language-specific harnesses have been removed since the project moved to community support and remain only in git history at commit cd27d64, because the current focus is implementation-agnostic vectors. The `testvectors/` and `testvectors_v1/` directories were also combined into one unified directory, and anyone needing the original v0 data is pointed at the `wycheproof-v0-vectors` tag.

## Sources

- [C2SP/wycheproof on GitHub](https://github.com/C2SP/wycheproof)
- [Issues](https://github.com/C2SP/wycheproof/issues)
- [License: Apache-2.0](https://github.com/C2SP/wycheproof/blob/main/LICENSE)
- [README](https://github.com/C2SP/wycheproof/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/c2sp-wycheproof