Found while implementing, not stated in any of the four documents.
The Anchor must draw $a', b', t'$ freshly per session. If a Client can induce reuse of $t'$ and $a'$ across two sessions, it submits two different challenges $e'_1 \neq e'_2$ and receives:
r'_1 = t' + e'_1 a' x
r'_2 = t' + e'_2 a' x
Subtracting: $r'_1 - r'_2 = (e'_1 - e'_2) a' x$, which solves for $a'x$. And $a'$ is sent to the Client in the clear in exchange two. So $x$ — the Anchor's long-term secret key — falls out with one division.
Consequences for implementations:
- Nonces MUST NOT be derived deterministically from the request. This is the opposite of the usual advice (RFC 6979, Ed25519), which makes it a live footgun: deterministic nonces are what a careful implementer reaches for by default. In this crate it is why
ExpAnchor holds an RNG behind a RefCell rather than deriving from (sk, request_body) — IhatAnchor::sign takes &self, so the obvious workaround is the dangerous one.
- Anchor state MUST be single-use.
IhatAnchor::prove taking Self::State by value enforces this at the type level.
Upstream gap: draft-jms-mole-protocols-00 §4.1.2 tells the Client "It MUST NOT retry with the same state" and says nothing to the Anchor. The crypto draft says nothing about nonce generation at all. Both should.
This is worth reporting to the draft authors.
Update — upstream PR #39 (open, unmerged): still unaddressed, and there is now a section for it
PR #39 adds a Security Considerations section to the crypto draft. In full:
Endorsements can only be shown once while preserving unlinkability. Unlinkability holds even if attackers have quantum computers, but an attacker with a quantum computer can recover the public key.
That is the whole section. It says nothing about Anchor nonce generation.
Two things this changes:
-
The finding stands. Nothing in PR #39 constrains a', b', t' freshness, and the AnchorSecondMessage struct it introduces confirms that aprime and bprime are sent to the Client in the clear — which is the half of the attack that makes the subtraction usable:
struct { rprime Scalar aprime Scalar bprime Scalar } AnchorSecondMessage
-
There is now an obvious home for it. Before PR #39 the crypto draft had no security considerations section at all, so reporting this meant asking for one. Now it is a paragraph added to an existing section, which is a much easier contribution to land.
The draft is also now authored — PR #39 replaces the John Doe / ACME placeholder with Watson Ladd (Akamai), so there is a specific person to raise it with.
Found while implementing, not stated in any of the four documents.
The Anchor must draw$a', b', t'$ freshly per session. If a Client can induce reuse of $t'$ and $a'$ across two sessions, it submits two different challenges $e'_1 \neq e'_2$ and receives:
Subtracting:$r'_1 - r'_2 = (e'_1 - e'_2) a' x$ , which solves for $a'x$ . And $a'$ is sent to the Client in the clear in exchange two. So $x$ — the Anchor's long-term secret key — falls out with one division.
Consequences for implementations:
ExpAnchorholds an RNG behind aRefCellrather than deriving from(sk, request_body)—IhatAnchor::signtakes&self, so the obvious workaround is the dangerous one.IhatAnchor::provetakingSelf::Stateby value enforces this at the type level.Upstream gap:
draft-jms-mole-protocols-00§4.1.2 tells the Client "It MUST NOT retry with the same state" and says nothing to the Anchor. The crypto draft says nothing about nonce generation at all. Both should.This is worth reporting to the draft authors.
Update — upstream PR #39 (open, unmerged): still unaddressed, and there is now a section for it
PR #39 adds a Security Considerations section to the crypto draft. In full:
That is the whole section. It says nothing about Anchor nonce generation.
Two things this changes:
The finding stands. Nothing in PR #39 constrains
a',b',t'freshness, and theAnchorSecondMessagestruct it introduces confirms thataprimeandbprimeare sent to the Client in the clear — which is the half of the attack that makes the subtraction usable:There is now an obvious home for it. Before PR #39 the crypto draft had no security considerations section at all, so reporting this meant asking for one. Now it is a paragraph added to an existing section, which is a much easier contribution to land.
The draft is also now authored — PR #39 replaces the
John Doe / ACMEplaceholder with Watson Ladd (Akamai), so there is a specific person to raise it with.