Zero-Knowledge Encryption for Developer Tools: What It Means

Zero-knowledge encryption is a specific guarantee: the service provider cannot read your data. Not "chooses not to" or "promises not to" — cannot. The server stores encrypted blobs that are mathematically useless without your master password, and your master password never leaves your machine.

This is different from how most cloud services work. When you store files in Google Drive or secrets in a typical SaaS vault, the provider holds the encryption keys. They encrypt data at rest and in transit, but they can decrypt it whenever they want — to index it for search, to comply with a subpoena, or because an employee with database access is curious. Zero-knowledge eliminates that entire category of risk.

For developer tools specifically, this matters because the data being synced includes SSH private keys, API tokens, database credentials, and environment files. A breach of the sync service should not mean a breach of every system those credentials protect.

ConfigSync's encryption pipeline has three stages: key derivation, file encryption, and upload. Every cryptographic operation happens on your machine. The server only handles storing and retrieving encrypted bytes.

Key derivation. Your master password is transformed into an encryption key using PBKDF2 with 100,000 iterations and a randomly generated 32-byte salt. PBKDF2 is deliberately slow — those 100,000 iterations mean that even if an attacker obtains the salt, brute-forcing the master password takes orders of magnitude longer than attacking a raw password hash. The salt is unique per user and stored alongside the encrypted data (it is not secret; its purpose is to prevent precomputed attacks).

File encryption. Each file is encrypted with AES-256-GCM, a symmetric encryption algorithm that provides both confidentiality and integrity. A fresh 12-byte initialization vector (IV) is generated randomly for every encryption operation, so encrypting the same file twice produces completely different ciphertext. GCM mode also produces a 16-byte authentication tag that detects any tampering with the ciphertext.

Upload. The encrypted blob is uploaded to Cloudflare R2 object storage. The server receives ciphertext and metadata (file path, timestamp, blob size) but never the plaintext or the encryption key.

Every encrypted file stored in ConfigSync follows a fixed binary layout:

This format is self-contained. Given the derived key, any standards-compliant AES-256-GCM implementation can decrypt the blob. There is no proprietary encoding or lock-in.

Transparency matters. Here is exactly what ConfigSync's servers have access to and what they do not:

The server CAN see: your email address, machine names you have registered, the number and sizes of encrypted blobs, timestamps of push and pull operations, and file path metadata (which modules you sync, not file contents).

The server CANNOT see: your master password, your derived encryption key, the contents of any config file, SSH private keys, API tokens, .env file values, shell history, or any other plaintext data. The server stores ciphertext and has no mechanism to decrypt it.

Most dotfile managers and config sync tools handle encryption differently — or not at all:

Tools like chezmoi and yadm support encryption through external programs (age, GPG), but they do not provide a sync server — you bring your own git remote, which means the encrypted files live wherever you push them. Tools like Mackup sync through Dropbox or iCloud, which means the cloud provider holds the encryption keys and can access your data.

ConfigSync is the only tool that combines built-in encryption with a cloud sync layer where the server is cryptographically excluded from accessing your data.

Developer machines are high-value targets. A single developer's dotfiles can contain AWS credentials, database passwords, API keys for payment processors, SSH keys to production servers, and tokens for every SaaS tool the company uses. Syncing these files through a service that can read them creates a single point of compromise.

Zero-knowledge encryption means ConfigSync cannot become that single point of failure. The encryption is not a policy — it is a mathematical property of the system. There is no admin panel where a ConfigSync employee can view your files. There is no "break glass" key that decrypts everything. There is no way to comply with a request for your plaintext data because the plaintext does not exist on our servers.