Adopted audited cryptography for the key layer

Taking the mathematics from one library

On 30 September we decided that nothing cryptographic will be designed here any more. Both standards the key layer needs now come from one library, @noble/curves 2.3.0, pinned to that exact version: RFC 9497, the published standard for the 2019 method named in our entry of 23 September, and the key generation that accompanies RFC 9591, the FROST standard. According to the library's own security notes, Trail of Bits audited it in full in August 2026. The report is not yet published, so we can say nothing about its contents. Trail of Bits audited the library. They have not looked at this platform.

It is the platform's first runtime dependency; everything before it is a development tool. It has no native code, so it can be read in full, and any upgrade will be reviewed afresh against the scope of the audit.

On it we built the threshold evaluation. Each service runs the standard step on its piece of the key and proves that it did so. The browser checks every proof, names any service whose proof fails, and combines any 3 valid answers. Its 9 tests show all 10 sets of 3 services giving the same answer, and a result equal to the standard single-key output. This is library code with tests. There are no running key services; the tests run all 5 in one process on one machine.

• noble-curves security notes, Paul Miller, 2026
• RFC 9497, Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups, IETF, 2023
• RFC 9591, The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures, IETF, 2024

Choosing how the pieces are refreshed

The library has no resharing, the step that gives the services new pieces of the same key so that a piece stolen last year is useless today, and that lets the group grow. On 23 September we wrote that this was ours to write. It was not. We chose it.

A search produced 28 candidates, eliminated in order against 9 criteria drawn from the specification and our own rules, each leaving at the first criterion it failed. One remained: verifiable secret redistribution, published by Desmedt and Jajodia in 1997, with the checks Wong, Wang and Wing proved sufficient in 2002. It is what drand, Obol's charon and Binance's tss-lib run for the same job. Of the others, one changes the key itself, so every stored record would need reprocessing, and one tolerates 1 dishonest service in 5 where the design assumes 2.

It is built from 2 calls the audited library already has and 2 equality checks. Published audits of other implementations became rules in our code: Trail of Bits on charon and tss-lib, and Kudelski Security on ING's library. The ING lesson mattered most. A final instruction to delete old pieces can be sent differently to different parties, so half delete and half keep. Here old pieces are destroyed only against a certificate every service has signed.

Its 14 tests grow the services from 5 to 7 at a threshold of 4, with every set of 4 giving the old answer. How often to refresh is not decided; we have proposed 30 days.

• Verifiable secret redistribution for archive systems, Wong, Wang, Wing, 2002
• DV Labs Charon Pedersen DKG Security Review, Trail of Bits, 2026
• Disclosing Shamir's Secret Sharing vulnerabilities, Trail of Bits, 2021
• Audit of ING's Threshold ECDSA Library, Kudelski Security

How the services agree

Of the 16 places where the services must hold the same running value, 3 were settled on 23 September. A revision of the specification on 30 September covers the other 13. None of the answers is an agreement protocol. Each is evidence merged from every service, a number the browser computes and takes from no single service, or a quorum of 4 of the 5, so that any two decisions share an honest service.

It took 4 review passes, and drew 24 findings, 4 of them serious. In one, a single service could make a desk's records permanently unreadable. In another, the fix for the order in which messages arrive let former members approve changes. The rule that remained treats admission and removal differently, on purpose. Admission is judged strictly against today's roster; removal against every member a service has ever held. The stated price: former members working with one corrupt service can remove people but never admit them.

A second revision that night specifies the 7 places where the services run a ceremony, a bounded session with a record, on one common procedure.

1. 01

   A proposal is made

2. 02

   Each service contributes

3. 03

   Every service checks the record

4. 04

   Every service signs a certificate of the outcome

5. 05

   Old material is destroyed only against that certificate

Any step can end in an abort that names the service at fault. None of it is built.

The adversarial review

Overnight into 1 October, 3 of our own reviewers, working blind and each on a different target, reviewed the ceremonies and the refresh code. They returned 47 findings. Two were critical, and both were fixed the same night.

The first was in the code. During a refresh, each service publishes check values for the pieces it hands out, and the code copied them forward after confirming only that they existed. One corrupt service could publish a false value for an honest one, and every service would certify it. The honest service's proofs would then fail at every browser, and at the next refresh it would be expelled as the liar. Every check value is now verified against the sender's own commitments, and 5 tests were added, 4 of them building a bad set of pieces by hand.

The second was in the specification. It said nothing about keeping the pieces confidential in transit. Read literally, every service would see every other service's piece of the key. Each piece is now encrypted to its receiver.

We had also overclaimed. On 30 September we wrote that a 2025 paper by Baecker, Gerhart, Rausch and Schröder covered our refresh outright. Two reviewers, independently, said that was asserted rather than inherited. They were right. The paper covers a refresh producing the same pieces as ours among an unchanged set of services, but its refresh publishes no check values, so its proof never sees the extra material ours publishes. We believe that material gives nothing away. We have not shown it. Growing the group is not covered at all. The claim stood for about 3 hours, and every document that made it, the architecture page included, now says what is covered and what is not.

No reviewer reported a working attack on the mathematics; what failed was the procedure around it. A second blind round on the rewritten procedure is owed. Questions 1, 3 and 5 of the 5 published on 23 September are unanswered, nothing in the platform is encrypted today, and nothing has gone to an outside cryptographer.

• A Fully-Adaptive Threshold Partially-Oblivious PRF, Baecker, Gerhart, Rausch, Schröder, 2025

Reading one PDF on one machine

The document reader can now be shown working before the platform exists. A single command reads one club PDF and prints every figure with its page and the printed text it came from, and every field it could not evidence, with the reason. Nothing is written and nothing leaves the machine.

We also measured the per-club readers as one figure for the first time. They reproduce 1,069 of the 1,072 verified values, with no wrong values and nothing extra. Our entry of 4 September said they reproduce all of them. That was wrong. Of the 3 misses, 2 are expected answers that paraphrase clause text where the reader returns the printed text, and the third is a Swedish Club name the reader deliberately refuses.

It runs on the 51 specimen documents and on any PDF a person points it at on their own machine. It is not in the platform, there is no upload and nothing is stored. Real club documents it has never seen have not been measured.