Two of Our Headline Features Rest on One Mathematical Assumption

The question nobody asks a vendor

Not "is your cryptography good". "How many independent assumptions is your system standing on?"

A system resting on four unrelated mathematical foundations degrades gracefully: a break in one costs you one capability. A system resting on one is a system where a single advance takes several things at once.

That is a concentration question, and it is answerable, which makes it unusually useful for a buyer who cannot evaluate cryptography directly.

Ours, answered

We use one mathematical family for two visible features.

Selective disclosure with unlinkability uses it. And the signature aggregation inside consensus, which compacts many validators' votes into one, uses the same family over the same curve.

So a serious weakening of that family would affect both our privacy story and our consensus efficiency at once. Those look unrelated on an architecture diagram, and underneath they share a foundation.

How worried to actually be

Less than that framing suggests, and not zero.

The curve involved is the standard choice for this work and is used in production by major systems well beyond us. It has had sustained academic attention. This is not an exotic selection.

But the published estimates for this family have moved before, and recently enough to matter. In 2016 a better variant of the number-field sieve cut the estimated security of the then-standard pairing curve from about 128 bits to roughly 100, and the ecosystem migrated to the curve we use now because of it. Nothing was broken. The estimate was corrected, and that is the normal life of a cryptographic assumption: when a margin moves, everything standing on it moves at once.

The honest position is that this is a well-chosen assumption we are more exposed to than a diversified system would be, and that the exposure is a design consequence rather than an oversight.

What is not concentrated

Worth saying, because a page of risk is not a description.

The default signature scheme on ordinary credentials is a different family entirely, the widely deployed, heavily scrutinised one used by SSH, TLS and most modern chains. A credential issued that way does not depend on the pairing assumption at all.

So the concentration is real for two specific features and not for the base case. A buyer whose requirement is signed, checkable credentials without unlinkability is standing on the more conservative foundation.

The part that matters more than the mathematics

In practice, implementation defects break systems far more often than mathematical assumptions do. The assumption has decades of scrutiny; our code has none.

So if you are pricing risk here, the ordering is: implementation first, by a wide margin, then concentration, then the underlying mathematics. We are weakest exactly where the risk is highest, and the audit that would address it is targeted and contingent on funding that has not been awarded.

What to ask any vendor about cryptographic risk

"How many independent assumptions does your system rest on?" A vendor who has never counted has not thought about correlated failure.

"Which features share a foundation?" The answer is rarely on the architecture diagram, because the diagram is drawn by function rather than by dependency.

"What has been independently reviewed, and what has not?" Implementation review matters more than primitive choice, and it is the question most vendors would rather answer last.

"What is your fallback if this assumption weakens?" For us: the base credential path does not depend on it, which is a partial answer rather than a plan.

Where this leaves a decision

If your risk framework requires reviewed cryptography, ours is not reviewed, and that is the first thing to weigh regardless of how well-chosen the underlying mathematics is.

If you are evaluating the design, the concentration above is real, it is confined to two features rather than the base case, and we would rather you know which parts of the system fall together than discover it from somebody else's paper.

The audit status of this implementation

The unlinkability implementation described here is unaudited.