noble rejects multiply(0n) exactly as libsodium rejects a zero scalar, and
the TypeScript SDK read the refusal as an invalid opening the same way
Python did. Both now multiply a zero scalar to the identity by hand.
gtank/ristretto255 accepts it, so the Go module was correct all along. Three
implementations: two agreed with each other and both were wrong, and the one
that matched the Rust core stood alone. That is the argument for a shared
corpus rather than per-language tests -- two implementations agreeing is not
evidence.
The zero vector is now consumed by all three, so the coverage contract holds
every client to it: 27 of 27 in Python, Go and TypeScript.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The eight private-numeric vectors were a declared boundary: verifying them needs
ristretto255 scalar arithmetic no SDK carried. Adding one everywhere would have
cost something real — the Go and TypeScript SDKs have *zero* dependencies, which
is a property their consumers get for free today.
So it is optional in each, and the shape differs per ecosystem: a `attesto[zk]`
extra in Python, an optional peer dependency in TypeScript, and a separate
`go.attesto.eu/sdk/zk` module in Go. A consumer who never opens a private
numeric inherits nothing. `not_checked` now means "this installation did not
check" rather than "nobody can", which is a better answer to the same question.
Each was verified against a real Rust commitment before being chosen: pysodium
over libsodium, @noble/curves, and gtank/ristretto255 all reproduce the core's
bytes exactly. PyNaCl was tried first and ruled out — 1.6.2 exposes no
ristretto255 bindings at all.
This closes Pedersen opening verification, not range proofs. A range proof needs
a full bulletproofs implementation, not curve arithmetic, and stays the core's
job.
Two things the last vector forced:
* A value outside the descriptor's declared domain now returns invalid for the
right reason. The commitment would fail to match anyway, but attributing that
to the arithmetic when the real answer is "that value is outside the declared
domain" blames the wrong layer. All three match the Rust core here.
* A skipped suite is a gate that proves nothing, so CI sets
ATTESTO_REQUIRE_ZK_EXTRA and an environment that was supposed to install the
dependency and did not now fails instead of reporting green over skips.
Corpus coverage is 25/25 and 12/12 in all three languages, with no exemption
left. The exemption mechanism is removed rather than emptied: reintroducing one
should be a visible decision, not a constant someone left lying around.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The dependency scan reported 14 high/critical findings across the backend and
the marketplace frontend. All of them are now closed, and the scan is green for
the first time.
**Bumped, with the suite as the check.** aiohttp 3.14.1 -> 3.14.3, pyasn1 0.6.3
-> 0.6.4, pydantic-settings 2.14.1 -> 2.15.0, and cryptography 48.0.1 -> 50.0.0.
That last one crosses two majors, which is why it was flagged as blast radius
rather than a routine bump; the full backend suite passes unchanged. nanoid and
postcss in the marketplace frontend are patched and the frontend still builds.
**ecdsa has no fix and never will.** CVE-2024-23342 is a Minerva timing attack on
P-256, and the project considers side channels out of scope. It arrives through
python-jose, and only signing, key generation and ECDH are affected —
verification is not. The backend signs tenant tokens with the symmetric
JWT_SECRET, so only HMAC families are coherent there anyway.
That was true by habit, not by construction: `jwt_algorithm` had no validation at
all, so JWT_ALGORITHM=ES256 would have signed through the vulnerable path with
nothing to say so. app/core/security.py now refuses any algorithm outside
HS256/HS384/HS512, on both the encode and decode paths, and
tests/test_jwt_algorithm_guard.py fails if that control is removed. `none` is
refused alongside ES*: an unsigned token is not a lesser problem than a badly
signed one.
The advisory is accepted by exact ID with that control named, using a mechanism
added here rather than by silencing the tool. A new advisory on ecdsa still
fails, and a package whose every finding is accepted stops being listed as
vulnerable so the field keeps meaning something.
Backend 1419 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
