Encrypted Clipboard Backups Explained: AES-256-GCM and PBKDF2

Local-first software has a simple privacy story: your data stays on your PC. But sooner or later you'll want a backup, a copy you can move to a USB drive, an external disk or a new computer. The moment a backup exists, it's a portable file containing everything you saved, and that file needs real protection.

This article explains how QuickPaste encrypts exported backups, what each technical choice means in plain English, and what the encryption can and can't do. If you'd like the bigger picture on why local storage matters, start with local-first vs cloud clipboard managers.

Why backups need encryption

A clipboard manager can hold snippets, links, identities, notes and sensitive items. An unencrypted export would be a single file containing all of it. If that file were lost, copied or left on a shared drive, anyone could read it.

Encryption turns the backup into unreadable data that only someone with the right secret can open. It's the difference between leaving your papers on a desk and locking them in a safe.

QuickPaste's backup encryption at a glance

Here is how the pieces connect:

Let's take each one in turn.

AES-256-GCM: encryption that also checks for tampering

AES (Advanced Encryption Standard) is the world's most widely used symmetric cipher. "256" refers to the size of the key in bits: a 256-bit key has an astronomically large number of possibilities, far beyond the reach of brute force.

GCM (Galois/Counter Mode) is the mode in which AES runs. Its special property is that it's an authenticated encryption mode. Alongside the encrypted data, it produces an authentication tag. When you decrypt, the tag is checked. If the encrypted data or the tag itself has been modified, the check fails and decryption is refused.

That matters because plain encryption alone only hides data. It doesn't tell you whether someone altered it. With GCM, you get two guarantees at once:

• Confidentiality: nobody can read the backup without the key
• Integrity: nobody can modify the backup without detection

GCM is standardized by NIST in Special Publication 800-38D and is used widely, including in modern TLS.

PBKDF2: turning a backup password into a proper key

AES needs a 256-bit key, and a human-chosen backup password is not one by itself. QuickPaste uses a key derivation function called PBKDF2 (Password-Based Key Derivation Function 2) to turn that password into a strong key.

PBKDF2 takes the backup password, mixes in a random salt, and repeats a hashing operation (here, HMAC with SHA-256) many times, 600,000 iterations in QuickPaste's case. That repetition is deliberate: it's a cost dial. Legitimate use needs the calculation once, so it is a small delay for you. An attacker guessing passwords has to pay that cost for every guess, which slows them down dramatically.

QuickPaste uses PBKDF2-HMAC-SHA256 with 600,000 iterations, in line with the current guidance for that construction in the OWASP Password Storage Cheat Sheet. The work factor is deliberately expensive to slow down password guessing. Iteration-count guidance is revised over time as hardware improves, so it is worth checking the OWASP page for the latest figure.

A fresh salt for every export

A salt is random data that's mixed into the key derivation. QuickPaste generates a fresh 16-byte (128-bit) random salt for each export. That has three benefits:

1. Unique keys. The same backup password produces a different key for every backup, so exporting twice never produces two backups protected by the same key.
2. No precomputed attacks. An attacker can't build a lookup table of password-to-key results in advance, because the salt is unknown until they hold the file.
3. Isolation. Cracking one backup doesn't help with another.

The salt isn't secret. It's stored alongside the backup, because the app needs it to re-derive the key. Its job is uniqueness, not secrecy.

A fresh IV for every export

GCM also requires an initialization vector (IV), sometimes called a nonce: a value that must be unique for each encryption under a given key. GCM's standard recommendation is a 12-byte (96-bit) IV, which is what QuickPaste uses, freshly generated at random for every export.

The reason it matters: repeating an IV with the same key in GCM can undermine its security guarantees. QuickPaste avoids that risk twice over. The key changes with every export (because the salt changes) and the IV is new each time.

Authenticated decryption: a wrong backup password or altered data fails

When you restore a backup, QuickPaste re-derives the key from your backup password and the stored salt, then decrypts and verifies the authentication tag.

• Wrong backup password? The derived key is wrong, the tag check fails, and the restore is rejected.
• Encrypted data or tag modified or corrupted? The tag check fails, and the restore is rejected.
• Correct backup password and unmodified data? Decryption succeeds.

This is important behavior. A weaker design could "decrypt" with the wrong key and hand back garbage, or accept modified data without noticing. Authenticated decryption gives a clean yes-or-no answer.

Browser-native Web Crypto: no home-made cryptography

A cardinal rule of security engineering is never invent your own crypto. QuickPaste's backup encryption uses the Web Crypto API, the cryptography interface built into the platform, rather than a hand-rolled implementation. The MDN documentation for SubtleCrypto describes the primitives it exposes, including AES-GCM and PBKDF2.

Relying on well-reviewed, native implementations means the hard parts (block cipher math, constant-time operations, secure random numbers) aren't reimplemented from scratch. And because it all runs on your device, the encryption happens locally. Your backup isn't uploaded anywhere to be encrypted.

What encryption can and can't do

Being honest about limits is part of good security writing.

What it protects against

• Someone finding or copying your backup file
• A lost USB drive or misplaced disk
• Accidental exposure on a shared drive
• Undetected modification of the backup

What it can't do

• Compensate for a weak secret. Any password-based scheme is only as strong as the secret you choose. Short, guessable passwords have relatively few combinations. QuickPaste enforces a minimum backup-password length and recommends at least 6 characters, but a longer, unique password is better.
• Protect against malware on your PC that can read data while the app is open
• Help if you share your backup password or store it next to the backup

Because the key is derived from your backup password and a random salt, decrypting a backup depends on knowing that password. Keep it somewhere safe.

Practical tips

1. Choose a long, unique backup password (QuickPaste recommends at least 6 characters, but longer is better) and don't reuse one from elsewhere.
2. Store the backup and the backup password separately.
3. Keep more than one backup, on different media.
4. Test a restore now and then, so you know it works before you need it.
5. Store secrets in the vault, not the general history. See our guide to clipboard security for passwords and API keys.

Why this matters for local-first

Local-first tools ask you to trust your own device rather than a company's servers. Encrypted backups are what make that practical: you can move your data around, or keep a copy safe, without turning it into a plaintext liability. It's one more reason QuickPaste can offer a free, no-account, one-time-payment app without your clipboard ever needing to touch a cloud. For the wider privacy argument, read how clipboard apps handle your data