How I saved gigabytes by deleting all RSA keys

Storing RSA keys for every user consumes gigabytes of disk space.

I have seen companies that use Mastodon point to this as a reason not to federate, and then delete those giant columns from the database.

To solve this problem, I first tried deterministic RSA. I generated the keypair from the user ID and a shared secret at runtime. This worked good for a year, until activity grew and it started destroying my CPU performance.

So here is the neat trick. You don’t need more than one RSA keypair at all. You can generate a keypair upfront, and then share a single keypair for all users.

This improved performance 10x for me over the deterministic method. Code is here: Use a shared RSA keypair for all users (!103) · Merge requests · Soapbox / Mostr · GitLab

There are basically no downsides. Any attack that would compromise one key would compromise all keys in either system. It’s fully backwards-compatible (each key still has a unique ID, they are all just the same). Maybe if people used C2S it would make sense to have separate keys, but they don’t. There is no reason not to do this. Big win IMO.

3 Likes

A fascinating property of draft-cavage-http-signatures is that it doesn’t sign the key ID (I’m not sure whether the newer versions do so, but we’re stuck at this old version regardless); this makes the authorization identity malleable if multiple users share a private key.

Is this exploitable? I have no idea.

3 Likes

This is a good idea! In a similar way Im planning to get rid of individual user/community inboxes on Lemmy, and only have a single shared inbox. I really dont see why Activitypub prescribes so much separation and duplication between users.

This is because ActivityPub is a peer-to-peer data exchange protocol, where “servers” only exist for the compatibility with the legacy Web. Technologies and standards that are needed to make ActivityPub work without servers simply didn’t exist in 2018… But now they do.

2 Likes