Re: Major Security Issue with AP: Server-Stored Private Keys in ActivityPub

Hi Melvin

In no currently deployed major platform fpr the Fediverse is the Actor's keypair used for:
- End-to-End Encryption — "private mentions" in ActivityPub are NOT end-to-end encrypted
- The is no direct payments via ActivityPub, only via the ValueFlows FEP where payment happens in a side-channel (i.e., not dictated by the protocol)

Yes, the current implementations may be storing the private keys in plaintext in the database (due to legacy reasons in the case of Mastodon), but even then with encryption it'd be a server managed encryption key, since the current architecture of S2S servers is that the server is the custodian of the private keys — not the end-user.

That is to say: you'd need to completely change how you think about doing anything with the Actor's private keys to make it user-custodial, because the private key is used for signing outgoing requests that may happen in the background & it would necessarily make sense to send the users' active sessions a message going "hey, can you sign this HTTP request I need to make?" for HTTP Message Signatures.

So yes, whilst we should be encrypting private keys in databases with a server-custodial key, that won't make the Actor's private key useful for payments or E2EE.

That is to say, this isn't the four-alarm fire it may initially seem to be.

– Emelia

> On 12. Apr 2025, at 09:45, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
> 
> Hi All,
> 
> There’s a major security issue in the way most ActivityPub implementations work today: private keys are typically stored on the server, often in plain text or with minimal protection.
> 
> This means:
> 
> Server admins or attackers can fully impersonate any user.
> 
> There is no real cryptographic boundary between the user and their instance.
> 
> End-to-end encryption is fatally compromised — servers can decrypt or forge "private" messages.
> 
> Any financial use of ActivityPub (tipping, payments, tokens) is wide open to theft, since servers hold the keys that authorize transactions.
> 
> When the original Working Group formed, we didn’t yet know how implementations would evolve. But now that we do, we can’t keep saying that insecure defaults are a feature, not a bug. This is a core flaw that undermines the promise of secure federation.
> 
> If a new Working Group is formed, security issues such as this need be acknowledged and addressed — including exploring models where users control their own keys, not the servers.
> 
> Looking forward to hearing thoughts,
> 
> Melvin