Forward-secret messaging over AT Proto identity — feedback on the bridge, and pointers to crypto review

I’m building GhostBox, an open-source (AGPL) zero-identity dead-drop messaging protocol. It leans on AT Proto for the part AT Proto is good at, decentralized identity and discovery, and provides the encrypted, unlinkable transport AT Proto doesn’t offer natively. An identity publishes and resolves a GhostBox address through an AT Proto record (lexicon: com.ghostbox.identity); the messaging itself runs off-protocol over a dead-drop with a forward-secret ratchet.

I just wired forward secrecy into the transport (a symmetric ratchet routed through a committing AEAD), and I want eyes on it before anyone relies on it. Two asks, because they’re different audiences.

For this community specifically:

  1. The bridge design. The ATproto-bridge publishes a locator plus an X25519 key to a public record so an ATproto handle resolves to a GhostBox address. That’s discoverability bought at the cost of the address’s own anonymity, and I’ve documented it as a deliberate tradeoff. Does the lexicon and record design look sane to people who know AT Proto identity well? Anything about PDS records, DID rotation, or handle resolution that breaks my assumptions?

  2. Unlinkability. Publishing to a public PDS record is an obvious correlation surface. I’d value scrutiny on what it leaks beyond what I’ve already named.

The bigger ask: the ratchet and the triple-DH handshake need an actual cryptographer’s review, and I know that isn’t most people’s lane here. If you do that kind of work, or know who in the AT Proto orbit does, a pointer would mean a lot.

Honest status: tests pass, nothing is audited, and I’m treating “unaudited” as a banner that stays up until someone qualified signs off.

Spec and code: [repo link]. SPECIFICATION.md and SECURITY.md lay out the threat model and the properties I do and don’t claim. Runs with npm ci && npm run test:all (TypeScript canonical, Python reference peer for the identity layer).

Tear into it. I’ll answer anything, or at least try, I’m new to this, and have been only working on this project for a few months now. This may be all just a house of cards. who knows.

1 Like

This is interesting, @coryottenwess.com

I’m still digging in, but maybe you can short-cut one question I have. How are you think about supporting multiple devices? (Like Signal does)

Also, any interest in a non-AGPL version?