The comparison table scores Signal wrong on the post-quantum ratchet #11

New Issue

2026-08-31T21:12:14Z

paulhitt commented

2026-08-31 21:12:14 +00:00

(Migrated from gitlab.com)

/comparison scores Signal No on "post-quantum in the ongoing ratchet". Signal shipped exactly that in 2025 — a sparse post-quantum ratchet running alongside the Double Ratchet — so the row is wrong, and wrong in the direction that flatters us.

The page's own closing paragraph invites reports of "a row that is out of date or unfair to one of the others" and calls that a bug. This is one, found by us rather than reported, which does not make it less of one.

Knock-on: "Reading the table fairly" says Apple is ahead of everyone on post-quantum. Signal is there too, and that sentence has to say so.

Source: signal.org/blog/spqr/ (2025).

`/comparison` scores Signal **No** on "post-quantum in the ongoing ratchet". Signal shipped exactly that in 2025 — a sparse post-quantum ratchet running alongside the Double Ratchet — so the row is wrong, and wrong in the direction that flatters us. The page's own closing paragraph invites reports of "a row that is out of date or unfair to one of the others" and calls that a bug. This is one, found by us rather than reported, which does not make it less of one. Knock-on: "Reading the table fairly" says Apple is ahead of everyone on post-quantum. Signal is there too, and that sentence has to say so. Source: signal.org/blog/spqr/ (2025).

paulhitt commented

2026-08-31 21:12:34 +00:00

(Migrated from gitlab.com)

mentioned in commit 71231003d7

mentioned in commit 71231003d79e502a245386e8437048bc073f5c68

paulhitt commented

2026-08-31 21:12:44 +00:00

(Migrated from gitlab.com)

mentioned in merge request !10

paulhitt commented

2026-09-05 00:29:30 +00:00

(Migrated from gitlab.com)

Fixed (!54). You were right, and I verified it from signal.org/blog/spqr rather than from memory — the whole problem with that row was somebody being confident.

Signal's Sparse Post-Quantum Ratchet shipped 2025-10-02, combined with their Double Ratchet as the "Triple Ratchet": continuous post-quantum key agreement, not just PQXDH's initial handshake. Their own framing — "over the lifetime of a session we keep generating new shared secrets and mixing those keys into our encryption keys" — is exactly what that row asks about.

The row now reads Yes, with the mechanism, the date and the fact that it is rolling out gradually rather than universally deployed.

The knock-on sentence went with it. "Apple is ahead of everyone here on post-quantum" was only true while Signal's cell said No. It now says we are not ahead of anyone on that row, names both, and names the date this page was wrong — a page that invites people to report an unfair row should say when it carried one.

⚠️ I expected to correct our own cells too, and they are right

Going in I assumed "Android now" on both PQ rows was the overstatement, because PARITY.md said the opposite: iOS's PQ files inert, Android with no ML-KEM, "neither client does post-quantum anything today".

Checked, and the page is accurate:

Android's ML-KEM-768 is BouncyCastle's FIPS 203 implementation, shipped in the engine — not a stub.
iOS's is CryptoKit MLKEM768, unconditional since the deployment target moved to 26.0; the runtime gate that made those files inert is gone.
The cross-engine harness proves it end to end, both directions: "Android picks v3 for an iPhone peer", "the first Android envelope carries a PQ ratchet step", "a v3 session survives being archived and restored mid-conversation".

So PARITY.md was the stale one, understating shipped work — the same direction as this ticket, pointed inward instead of outward. Corrected in android!63.

Two pages wrong about the same subject in opposite directions on the same day is worth noticing: nobody had re-measured post-quantum anywhere.

**Fixed (!54).** You were right, and I verified it from signal.org/blog/spqr rather than from memory — the whole problem with that row was somebody being confident. Signal's **Sparse Post-Quantum Ratchet** shipped 2025-10-02, combined with their Double Ratchet as the "Triple Ratchet": continuous post-quantum key agreement, not just PQXDH's initial handshake. Their own framing — *"over the lifetime of a session we keep generating new shared secrets and mixing those keys into our encryption keys"* — is exactly what that row asks about. The row now reads **Yes**, with the mechanism, the date and the fact that it is rolling out gradually rather than universally deployed. The knock-on sentence went with it. *"Apple is ahead of everyone here on post-quantum"* was only true while Signal's cell said No. It now says we are not ahead of anyone on that row, names both, **and names the date this page was wrong** — a page that invites people to report an unfair row should say when it carried one. ### ⚠️ I expected to correct our own cells too, and they are right Going in I assumed "Android now" on both PQ rows was the overstatement, because `PARITY.md` said the opposite: iOS's PQ files inert, Android with no ML-KEM, *"neither client does post-quantum anything today"*. Checked, and the page is accurate: - Android's ML-KEM-768 is BouncyCastle's FIPS 203 implementation, shipped in the engine — not a stub. - iOS's is CryptoKit `MLKEM768`, **unconditional** since the deployment target moved to 26.0; the runtime gate that made those files inert is gone. - The cross-engine harness proves it end to end, both directions: *"Android picks v3 for an iPhone peer"*, *"the first Android envelope carries a PQ ratchet step"*, *"a v3 session survives being archived and restored mid-conversation"*. **So `PARITY.md` was the stale one**, understating shipped work — the same direction as this ticket, pointed inward instead of outward. Corrected in android!63. Two pages wrong about the same subject in opposite directions on the same day is worth noticing: nobody had re-measured post-quantum anywhere.

paulhitt (Migrated from gitlab.com) closed this issue

2026-09-05 00:29:30 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-relay#11