Architecture

What this page is

We publish the architecture rather than describing it in general terms. A design that only holds while it is secret is not one we would put a client's book behind, so this page sets out how the platform is built and where it is open.

It describes what is designed. Nothing here is running yet, and where a part exists only on paper we say so in the same sentence that describes it.

The two planes

Manifest holds two kinds of information and treats them differently.

• The public plane. What any observer of shipping can already establish: that a vessel exists, its identifiers, its type and its build. Held in the clear, because it is already in the clear.

• The private plane. Which vessels sit on AJG's book, what they are rated at, and everything a broker writes about them. Encrypted, and readable only through the steps below.

The line between the two is the product. Anyone reading our database learns which vessels exist in the world, which they could establish anyway, and nothing about whose book they sit on.

Where the parts run

Each part is arranged to be useless on its own. The store holds every record and can compute nothing from any of them. The custodian services can compute and hold none of the book.

The store is not trusted with the book, and it does not need to be. That is the whole of the arrangement.

Opening one record

A broker holds proof of who they are and no key material. The key for a record is worked out at the moment it is used, from a public starting point and the help of three services, and it exists nowhere before or after.

There is no partial progress below the threshold. Two custodians short of a quorum are exactly as far from the key as none at all. Each custodian also returns a proof that it used the share it has published, so a custodian can refuse to help but cannot quietly hand back a wrong answer, which would leave a record that never opens again.

The mathematics, and where it comes from

The method above is not ours. It is a threshold oblivious evaluation, published in 2019 and examined several times since, and the paper that sets it out describes this use of it as well: keys worked out on demand instead of stored in a wrapped form, one independent key for each thing being protected, and key rotation that leaves the archive where it is.

We designed ours first and found it in the literature afterwards, which cost us several weeks. What we run cites the construction by name, and the work it rests on is listed below for anyone who wants to read it instead of taking our word.

• TOPPSS, the threshold oblivious evaluation, Jarecki, Kiayias, Krawczyk and Xu, 2017
• Threshold Partially-Oblivious PRFs with Applications to Key Management, Jarecki, Krawczyk and Resch, 2019
• RFC 9497, the oblivious evaluation as a published standard
• RFC 9380, how a label becomes the point the method starts from
• A closer analysis of the same method against a dishonest client, 2024
• The same method with scheduled key refresh, 2025

What limits how much can be read

Most descriptions of designs like ours get this part wrong. Ours did too, until recently.

The labels the method starts from are public. They have to be, because a custodian checks that a request is for what it says it is for. So the mathematics gives nothing at all against someone who is entitled to ask and simply asks: three custodians answering is any key they are allowed to reach.

What bounds how much of the book one person can take is therefore not the cryptography. It is who is allowed to ask, how often they may ask, and the fact that every request is recorded and attributed at three services the store's operator does not run. Those are ordinary controls doing real work, and we would sooner say so than let a reader credit the mathematics with it.

Withdrawing access

Access is a row held at the custodian services rather than a key in someone's hands, so withdrawing it is a single write that completes on its own and cannot be stalled by anything else.

That closes the future completely. It does not reach backwards into records nobody has touched since, and we would rather state that here than have a reviewer find it. Those records close as brokers edit them in the normal course, and a deliberate pass over the archive closes the remainder.

Erasing a person

A contact at an owner or a manager may ask us to erase their details, and the ordinary answer is to delete some rows. We are not doing that, because deleting rows leaves every backup taken before the request still holding the person.

Instead each person's details sit under a key of their own, held in pieces across the custodian services. Erasing them destroys those pieces, so a backup of the book taken years ago holds something nobody can open.

That has a limit, and it is recent news to us. It is a limit of the mathematics and not of our engineering. Nothing proves that data has been deleted, because data that has been copied cannot be uncopied. What we can build, and what we will claim, is that an attempt to put a custodian service back to how it stood before the request is detected, refused and recorded. For the backups themselves the argument is the regulator's own: material that is held and not used, until retention replaces it.

What it would take to read the book

• A quorum of the custodian services

• The value the derivation starts from

• The stored ciphertext

Only with all three together does the book open

Microsoft cannot read the book. Azure holds the ciphertext and the request log and can compute nothing from either. That holds provided the custodian services run apart from the application and the store, under separate credentials, which is a deployment requirement rather than a preference.

Gallagher can. We operate all three, so the three parts sit inside one company, and an organisation that decided to combine them would read everything. The obligation not to is contractual and sits with the legal team. That is a normal enterprise arrangement, and it is a contractual control. We will not dress it up as a mathematical one.

• A breach of the store on its own yields nothing readable.

• One compromised service is contained, because the custodians answer separately.

• Reading a record leaves an attributable trace at services the store's operator does not run.

The code in the browser

The page that opens a record reaches the broker over the web. If that code is altered before it arrives, it can act as the broker, and no rule written inside that code changes it. This is the open gap in the design and we would rather name it than leave it to be found.

The answer we agree with is a browser extension holding the pinned custodian set and making the calls itself, which leaves the page as a shell nobody has to trust. It is deferred, because it carries regulatory and logistics work that this stage of the build should not take on. What we ship is the web application and an installable version of it, and installing it is not a security measure: same origin, same certificate and same update path as a bookmarked tab.

What is designed and not built

None of this is running. The evaluation and the refresh exist as library code with tests, run in one process on one machine. No custodian service exists, and nothing in our repository is encrypted today.

The scheduled refresh of the custodians' shares is no longer ours to write. It is verifiable secret redistribution, a published construction, built from calls the audited library already has. Whether it is safe alongside the evaluation is still open: published work covers a refresh among an unchanged set of custodians, but not the check values ours publishes, and not a set that grows.

The page does not carry the deployment: regions, the thresholds in force, hostnames. Those are configuration, and publishing them helps an attacker and not a reviewer.

What we have not settled

Five questions about the key layer are open. We have written them up in full, with what we believe in each case and what we would do with either answer, and the short version sits here so that anyone assessing us can see the gaps without having to ask for the document.

• One asks whether the short way of setting the custodians up is safe for us

• Two ask about scale: many keys made at once, and many keys held at once

• One asks whether the scheduled refresh of the shares is safe alongside the evaluation

• One asks whether an attack published in 2025 on a related scheme reaches us

None of them is settled by us reading the papers again, which is why they are questions and not work items

The first decides the most, so it is the one to read if you read only one. Setting the custodians up has a short version and a long one. The short version lets a dishonest party nudge the result, and published work argues that this particular nudge is harmless for methods built like ours. What we cannot confirm is that the argument reaches the exact property we depend on. If it does, two rounds and the setup is settled. If it does not, we take on a construction nobody has implemented for us, and then we own it.

The second and third are questions about scale. We need several hundred keys made in one session, because the agreement step is what costs, and the published analysis covers a session that makes one. We have since fixed the session so that it either produces every key or none, which is the shape that analysis speaks to, and the question that remains is narrower than it was. We also need one set of custodians to hold thousands of unrelated keys at once, and the standard that describes the evaluation says in terms that nobody has analysed that case. Neither is an alarm. Both change what a working process looks like.

The fourth has narrowed, in the direction we hoped, and we overstated it for a day. We read the 2025 paper in full. Its result covers a refresh of the same shape as ours among an unchanged set of custodians, which is most of what we wanted. What it does not cover is the extra material our refresh publishes so that each custodian can check the others, and we believe that material gives nothing away but have not shown it. The rarer case where the set of custodians grows is not covered at all. Our own review caught the first version of this paragraph claiming more than that, and we have corrected it here rather than quietly.

The fifth we believe does not reach us. The attack concerns a different primitive and bites at hundreds of participants; at five the margin is enormous. We have put it on the list because the structure is close enough that we would sooner be corrected than be right by accident.

We have written all five up in full, with what we believe in each case and what either answer would change. We will publish the answers here as they arrive, including any we do not like.