Longfellow’s New Home Changes the ZK Supply-Chain Question

Google has moved Longfellow ZK into a different kind of security conversation. On September 2, the company announced that it was donating the library to the Post-Quantum Cryptography Alliance (PQCA), a Linux Foundation Europe initiative. Google says the goal is vendor-neutral, open stewardship for a library aimed at privacy-preserving digital identity applications.

That matters because a zero-knowledge system is not only a proof equation. It is also a software supply chain: circuit definitions, transcript rules, parameter profiles, serialization formats, test vectors, compiler settings, release tags, and the people authorized to change them. Moving a project into an open alliance can broaden review, but it does not automatically make every implementation interoperable or every upgrade safe.

Longfellow’s current public materials make the implementation boundary visible. The GitHub repository describes the project as a zero-knowledge library for identity protocols and lists an Apache-2.0 license. Its build instructions depend on components including CMake, Clang, OpenSSL, zstd, GoogleTest, and Google Benchmark. The repository also points to independent security reviews and provides benchmarks and tests. For an ICP builder, these details are practical: a canister-facing service or verifier should pin the exact source revision, toolchain, circuit profile, and verification vectors it was audited against.

The accompanying September 3 Internet-Draft adds another important layer. It describes Longfellow as a succinct non-interactive ZK argument built from MPC-in-the-head, Ligero commitments, and sumcheck. The draft focuses on a design that does not require a common reference string and can be instantiated from a collision-resistant hash function, while defining a particular profile with SHA-256. It also lists supported parameter combinations intended to provide at least 115 bits of security according to the document’s latest analysis.

Those statements are useful engineering inputs, not permanent guarantees. A verifier deployed on ICP should not infer that “post-quantum” means every surrounding credential, signature, transport, or wallet is post-quantum. The proof system may protect a statement about an ECDSA-signed credential, while the credential’s signature scheme remains exposed to future quantum attacks. The security claim therefore belongs to a precisely defined profile and threat model.

The immediate lesson is to treat stewardship as part of the cryptographic interface. Before integrating a Longfellow-based verifier, teams should record:

• the repository commit and release tag;
• the circuit and parameter profile;
• the hash, transcript, and serialization rules;
• the toolchain and dependency versions;
• the test vectors used for acceptance testing; and
• the upgrade authority and rollback procedure.

Google’s announcement describes the intended vendor-neutral stewardship model, but it does not specify a maintainer charter, release-governance process, or migration timeline. Those operational details remain open questions. The IETF document is likewise a work in progress and warns that Internet-Drafts can be updated, replaced, or obsoleted.

For ICP developers, this is the new angle: the next risk is not simply whether a proof verifies today. It is whether an upgraded verifier, a changed circuit profile, and an independently maintained implementation still mean the same thing tomorrow. Open stewardship can improve that outlook—but only if integrations make those assumptions explicit and testable.