Encrypted Backups

Backups are protected with AES-256-GCM. AES — the Advanced Encryption Standard — is the encryption trusted by governments, banks, and security researchers around the world. The "256" is the size of the key that locks the data: there are more possible 256-bit keys than there are atoms in the observable universe, which is why no one can simply try them all. The "GCM" part is what makes AES not only secret but also tamper-evident, which we come back to below.

In precise terms, GCM stands for Galois/Counter Mode, and it makes AES an authenticated cipher (an "AEAD" — authenticated encryption with associated data). Each backup is encrypted with a fresh random 96-bit (12-byte) nonce — a number used once — so that encrypting the same data twice never produces the same output, and it is sealed with a 128-bit (16-byte) authentication tag. The nonce and tag are stored alongside the ciphertext; neither is secret, and neither helps an attacker without the key. What you end up with is a file that is simultaneously unreadable and tamper-proof, using one well-studied algorithm rather than two bolted together.

The obvious question is: where does the key come from, and where is it kept? The answer is that it is never kept anywhere. Instead, the key is calculated from a passphrase you choose, at the moment you make or restore a backup, using a process called PBKDF2 with SHA-256, run 100,000 times. Two details make this strong. First, a unique random value called a salt is mixed in, so that even two people who pick the exact same passphrase end up with completely different keys — this defeats attackers who work from precomputed tables of common passwords. Second, repeating the calculation 100,000 times makes it deliberately slow: your own device does this once and never notices, but an attacker trying to guess billions of passphrases is slowed to a crawl. Because the key only ever exists for the moment it's needed and is then discarded, there is nothing on disk for anyone to steal.

Concretely, the derivation uses a 256-bit random salt per backup and 100,000 rounds of PBKDF2 with HMAC-SHA-256 to stretch your passphrase into a 256-bit AES key. The salt is stored with the backup (it doesn't need to be secret — its job is only to make every backup's key unique), while the key itself is never written anywhere. If you're curious why "100,000 rounds" is the number: it's a deliberate cost. Each guess an attacker makes has to pay that same computational toll, so a rate that's invisible to you (one derivation when you make or restore a backup) turns billions of offline guesses into an impractically slow grind.

Because AES-256-GCM is an authenticated cipher, every backup carries a small built-in cryptographic tag that works like a wax seal on an envelope. When you restore, RSocial recomputes that tag and checks it. If even a single byte of the file has changed — whether from disk corruption or a deliberate edit — the seal no longer matches, and the backup is refused rather than quietly loaded with hidden changes inside. This is the "integrity check" made concrete: it's not a separate scan you have to run, it's built into the act of decrypting.

It helps to picture what's actually inside a backup. When one is created, RSocial gathers the pieces that make up your instance — the SQLite databases holding your accounts and media metadata, and a dump of the RDF graph holding your posts, comments, and likes — and packages them into a single compressed archive (a tar.gz). A manifest lists each entry along with a checksum, and then that whole archive is what gets encrypted with AES-256-GCM. So there are two layers of integrity working together: the manifest checksums catch corruption of any individual piece, and the GCM authentication tag guarantees the encrypted archive as a whole hasn't been altered by so much as a single bit. Restoring simply reverses the process: verify the tag, decrypt, check the manifest, then put each piece back.

One honest consequence follows from the design above: since the key is derived only from your passphrase and is never stored, losing that passphrase means losing access to that backup. There is no master key and no "reset link," because a reset link would be exactly the back door this whole design exists to avoid — if we could reset it, so could an attacker. Treat your backup passphrase like the one key to a safe: write it down somewhere secure, or keep it in a password manager. The upside of that strictness is complete confidence that no one but you can ever open your backups.