How Cachy encrypts clipboard sync

The encryption boundary

Clipboard data is unusually sensitive. A copied item can be a password, a private link, a customer record, an image, or a file. Cachy treats synced clipboard content as files inside a local-first workspace, then encrypts those files on the sending device before they are uploaded.

Encrypted sync is the default path. The desktop client uses encrypted endpoints unless a plaintext compatibility flag is explicitly enabled, and the cloud rejects plaintext sync unless its matching server flag is also enabled. The model below describes the encrypted path used by normal Cachy Cloud sync.

1. Your device

   Cachy saves the copied text, image, file, and source context in its local workspace.

2. Client-side encryption

   The desktop app encrypts content and path metadata with keys derived from a random workspace key.

3. Cachy Cloud

   The sync service stores ciphertext, opaque path identifiers, versions, and the metadata needed to converge devices.

4. Your other device

   An authenticated device obtains the wrapped workspace key, decrypts locally, and verifies the result before applying it.

What is encrypted before upload

Each synced file is sealed with AES-256-GCM and a fresh random nonce. The authentication data binds the ciphertext to its workspace, key version, opaque path identifier, and keyed sync hash, so moving or altering an encrypted object causes verification to fail.

Paths do not go to the server as filenames. Cachy creates a stable opaque path identifier with HMAC-SHA-256, and it encrypts the filename, normalized path, parent path, MIME type, mergeability, plaintext size, plaintext hash, schema, and file body inside client-side envelopes. Clipboard item records therefore protect copied text, image and file payloads, filenames, source-app details, and source icons together.

• Separate derived keys

  One random workspace key derives independent keys for file encryption, metadata encryption, opaque path IDs, and sync hashes.

• Keyed sync hashes

  The server compares versions without receiving a reusable plaintext SHA-256 hash of the clipboard content.

• Authenticated envelopes

  The receiving device checks the GCM tag, plaintext size and hash, path identity, and keyed sync hash before accepting a file.

How another device gets the key

Cachy creates a random 256-bit workspace data key. Your account password is processed locally with scrypt to derive a separate wrapping key. The workspace key is encrypted with that wrapping key, and only the encrypted envelope is stored in Cachy Cloud. A new signed-in device can download the envelope and unwrap it after you enter the same account password.

The account password also goes to Cachy’s authentication service over TLS during today’s email-and-password sign-in. The authentication service verifies it but does not intentionally persist the plaintext password. This means the current design protects against a passive database or object-storage disclosure, but it is not zero-knowledge against an actively malicious authentication service that captures a future sign-in password.

Encryption and sync integrity work together

Authenticated encryption detects modified ciphertext. Keyed path IDs and content hashes let devices compare state without revealing the corresponding plaintext. Cachy’s Merkle tree then finds which opaque branch changed, while realtime messages act as a doorbell that tells another device to fetch and verify the durable encrypted state.

This protects the confidentiality and integrity of individual encrypted objects. It does not guarantee availability: a cloud outage or malicious service can still delay, withhold, or delete data. The current protocol also does not claim perfect rollback resistance against a service that can present an older self-consistent snapshot.

Where the current design can break

End-to-end encryption narrows the systems that must be trusted. It does not make Cachy, your devices, or the surrounding software impossible to compromise. These are the boundaries we think users should know.

• A compromised endpoint can read plaintext

  Malware or another process acting as your signed-in OS user may read local clipboard data and keys while Cachy can use them. E2E encryption cannot protect data after an authorized device decrypts it.

• The local workspace key needs stronger storage

  Today the sync workspace key is cached in Cachy’s local app-data directory and relies on the OS account boundary and full-disk encryption. Moving it into the OS credential store or hardware-backed storage is a planned hardening step.

• The active authentication service is still trusted

  Because today’s password sign-in sends the password to the authentication service over TLS, a malicious version of that service could capture it and derive the workspace wrapping key. A zero-knowledge password protocol would remove this trust.

• Metadata still tells a story

  Encryption hides content and names, not the fact that a device synchronized, the approximate amount of data, or the relationship and timing of opaque changes.

• This implementation has not completed an independent security audit

  Internal tests cover encryption, tamper rejection, and sync behavior. Independent review and a clearer vulnerability-disclosure process are still work to do.

A smaller note on Remote SSH

Remote SSH uses a separate security model. It is off by default on every device, requires local opt-in and password-confirmed account approval, and runs SSH2 over outbound WebSockets instead of opening an inbound port or changing the system SSH server.

Each device has separate ECDSA P-384 host and client identities. Their private keys are exported as password-encrypted PKCS#8 and stored, with independent random passphrases, in the operating system credential store. Only public keys and SHA-256 fingerprints reach Cachy Cloud. One-use 256-bit relay tickets expire after 60 seconds, while SSH provides encryption, host authentication, client authentication, and transport integrity end to end.

The host accepts bounded exec requests only: no interactive shell, PTY, password login, agent forwarding, TCP forwarding, X11 forwarding, or arbitrary environment requests. Commands still run as the existing local OS user, so approving a device grants powerful remote code execution within those limits.

What we are hardening next

The highest-value next steps are moving the local sync key into OS-protected storage, replacing password-visible authentication with a zero-knowledge password flow, adding independently verified device-key pinning, and commissioning an external review. We will update this post when those boundaries change.

Security reports are welcome at hi@cachy.space. Please include the affected surface, reproduction steps, likely impact, and any evidence that does not expose another user’s data.