Security

Release status, key handling, operator rules and how to report a vulnerability.

Release status

Arkognito is experimental and runs on the Arkiv Tiramisu testnet only. The protocol is version 0.x and may change in ways that are not backward compatible. The cryptography has not had an outside audit. Do not use it to protect data whose exposure would cause real harm.

What is tested: unit tests for derivation, envelopes, tags, encryption, padding, proofs and OHTTP encapsulation; a browser test of the key worker; and on-chain tests on Tiramisu covering the full write and read paths, misbehaving relayers, failover, blind tokens, issuer equivocation, the linkage experiment and a 27-check edge-case suite. See the edge-case register.

Report a vulnerability

Report privately through GitHub’s private vulnerability reporting, not a public issue. Include steps to reproduce and the commit you tested.

In scope: anything that lets someone

• link records to each other or to a wallet;
• read an encrypted payload;
• forge a record or an ownership proof;
• spend a rate-limit token twice;
• make a relayer write something its owner did not sign;
• make an OHTTP relay forward somewhere it should not.

The known, documented limits are in the threat model.

Keys and secrets

Secret	Where it lives	Never
User’s wallet signature for key derivation	Handed to the key worker, then dropped	Stored, logged or sent anywhere
Root key and one-time keys	Inside the key worker (browser) or the client process (Node)	Leaves the worker; written to Arkiv
Random-root recovery code	With the user, like a seed phrase	Stored by the app
Relayer and issuer wallet keys	Environment variables of each service	Committed, shared between services, pasted in chats or issues
ISSUER_RSA_SEED	Issuer’s environment	Changed during a UTC day, shared
ARKIV_ACCESS_KEY	Server-side environment	Shipped to browsers

Nothing secret, and nothing personal, is ever written to Arkiv: only one-time addresses, encrypted tags, random token ids, the app’s own data and public issuer keys.

Rules for operators

• One wallet per process. Never run two relayers (or a relayer and a test) on the same wallet. Their transactions and key predictions collide.
• Separate wallets for relay-1, relay-2 and the issuer.
• No logs of IPs or bodies. The services log batch summaries only. Configure any reverse proxy the same way, especially in front of an OHTTP relay.
• HTTPS everywhere public. Clients and OHTTP relays use only https relayers.
• Run the OHTTP relay under a different operator than the relayers, or it protects nothing.
• Keep OHTTP_ALLOW_LOCAL off on any public relay.
• Watch balances. A relayer out of gas stops writing; /healthz reports balanceGlm.
• Keep the issuer seed stable within a day. A changed seed publishes a second key, and every client then refuses the issuer as equivocating.

Rules for app builders

• Load no third-party analytics, session replay or error reporters on pages that use Arkognito. They can read the wallet and everything the page sees.
• Keep attributes coarse and put personal content in encrypted payloads.
• Treat a hostile frontend as out of scope: the key worker stops leaks and arbitrary signing, but a page you do not trust can still request Arkognito signatures and ownership proofs.