Future-Proofing Software Supply Chain Security: Post-Quantum Cryptography for Sigstore
Post-quantum cryptography (PQC) is rapidly transitioning from a theoretical exploration to an immediate infrastructure necessity. With recent advancements accelerating the estimated arrival of cryptographically relevant quantum computers (CRQCs), industry leaders like Google and Cloudflare have expedited their migration timelines to 2029, and governments have pushed up timelines to 2030 as well.
To stay ahead of this threat, Sigstore is adjusting our timeline to support PQC algorithms immediately. Sigstore will not only integrate quantum-resistant algorithms but also seize this opportunity to fundamentally streamline its core architecture.
To learn more, review the design document (join sigstore-dev to view).
We will be publishing more blog posts in the coming months as we continue to make progress. If you have any questions, please reach out on Slack or create an issue or question on one of Sigstore’s GitHub repositories.
Rethinking Architecture for PQC
Simply swapping classical algorithms (like ECDSA or Ed25519) for PQC (specifically ML-DSA) introduces operational friction. ML-DSA signatures and public keys are drastically larger than classical signatures and keys, which directly translates to increased storage demands, higher egress costs, and larger signature bundles.
Furthermore, introducing any breaking cryptographic change to an expansive ecosystem that includes package registries and enterprise organizations is a complex challenge. The project recognized that if an ecosystem-wide breaking change is required to adopt PQC, it presents the perfect opportunity to implement five years of operational learnings and solidify Sigstore’s design.
Core Innovations in PQC Sigstore
The proposed changes maintains Sigstore’s robust security guarantees and threat model while drastically reducing complexity and addressing ecosystem feedback for users of the public infrastructure.
- Log Proof as a Keyless Signature: The default “keyless” signing flow will truly be “keyless”, without an ephemeral key, short-lived certificate, or timestamp. Instead, the transparency log will directly accept, verify, and extract relevant claims from OpenID Connect (OIDC) identity tokens, returning an independently witnessed and timestamped log proof.
- The public deployment will continue to accept signatures generated by managed keys as well.
- Privacy-Conscious Log Entries: To combat the threat of log spam/poisoning, improve data privacy and reduce the size of log entries, Rekor will implement the Identity-based Transparency Log Specification. All user-provided data, including emails, workload identifiers, and private repository names, will be stored as cryptographic hashes, preventing sensitive identifiers from being public. Monitors will audit the log by searching for the hashes of user data.
- Alignment with Transparency Standards: In addition to the above specification for the leaf format, Sigstore will leverage c2sp.org/tlog-proof structures in the new bundle format revision, so that tooling can be shared with the transparency community.
- Strict Algorithm Isolation: Classical and post-quantum algorithms will not be intermingled in client SDKs and the infrastructure. Signature verification tools such as Cosign will support verification of any supported signature algorithm while providing user configuration for the permitted algorithms, with client tooling eventually switching to a default of enforcing only ML-DSA.
What This Means for Users and Deployers
A guiding principle of this migration is ensuring existing workflows remain completely unbroken.
- Independent Infrastructure: PQC Sigstore will launch as an entirely separate infrastructure stack, with trust rooted in a new, ML-DSA-signed TUF repository.
- Opt-In Rollout: Adoption will be completely opt-in initially, allowing verifiers and signers to transition independently.
- Public Instance Timeline: A production-ready PQC public instance is targeted for mid-2027, with major client revisions supporting PQC. The classical public instance will remain fully operational and supported until a future turndown, tentatively scheduled for 2029 or 2030 to align with PQC mandates.
- Simplified Private Deployments: Organizations running private Sigstore instances can achieve private code signing simply by deploying a private transparency log that is not publicly witnessed. For organizations that do not want to operate a transparency log, client SDKs will also support an infrastructure deployment option using a certificate authority and timestamp authority. Both of these options provide the same strong security guarantees around PQC.
- Rekor v2 Rollout Pause: Sigstore maintainers will focus on developing a PQC-ready Rekor, and so Rekor v1 will remain the default log. See the previous blog post for more information.
By tackling algorithmic migration and structural simplification simultaneously, Sigstore is paving a clean, highly scalable path toward a quantum-resistant software supply chain. If you have any questions or feedback, please reach out on Slack.