Encryption & Privacy Whitepaper

Last updated: January 2026

1. Why Clipboard Data Must Be Encrypted

Clipboard content is uniquely sensitive. It often contains:

• Passwords, verification codes, API tokens
• Private keys, configuration snippets
• Internal documents or unreleased content

Most clipboard tools treat this data as transient or harmless. In reality, it is one of the highest-risk data surfaces on any device.

UniClipboard was designed around a single premise:

Convenience should never require surrendering control over your data.

2. Core Security Principles

UniClipboard’s encryption system is built on four non-negotiable principles:

1. User-Controlled Encryption is initiated and owned by the user. Keys are derived from user input, not generated by the service.

2. End-to-End Encrypted Data is encrypted before it leaves the device and decrypted only on trusted devices.

3. Zero-Knowledge by Design UniClipboard cannot read your clipboard content—by architecture, not by policy.

4. Minimal Exposure Plaintext exists only where strictly necessary, and only for the shortest possible time.

3. High-Level Architecture

Once encryption is enabled, the data flow is straightforward:

Clipboard Content
   → Local Encryption (Client)
   → Encrypted Sync Channel
   → Local Decryption (Target Device)

Key implications:

• Sync servers and relay nodes only ever see encrypted payloads
• Network transport does not affect cryptographic guarantees
• Trust boundaries remain entirely on user devices

4. Key Management Model

4.1 Layered Key Design

UniClipboard uses a layered key hierarchy to avoid single-point compromise:

User Passphrase
        ↓
Key Encryption Key (KEK)
        ↓
Master Key
        ↓
Clipboard Data Encryption

Roles of each layer:

• User Passphrase Never uploaded. Never used directly for data encryption.

• KEK (Key Encryption Key) Derived from the passphrase. Used only to protect the master key.

• Master Key Encrypts clipboard data. Can be rotated or replaced without changing the passphrase.

4.2 Secure Local Storage

Encrypted keys are stored using platform-native secure storage whenever available:

• macOS Keychain
• Windows Credential Manager
• Linux Secret Service (with secure fallback)

Disk access alone is insufficient to recover plaintext data.

5. Clipboard Data Encryption Strategy

5.1 Encryption Granularity

Encryption is applied per clipboard entry, not as a monolithic database:

This design improves performance while preserving security boundaries.

6. Sync Security Model

6.1 Local Network Sync

• Encrypted payloads only
• Packet capture yields no usable content

6.2 Remote Sync

• Servers act purely as encrypted relays
• No access to master keys
• No ability to decrypt stored or in-transit data

UniClipboard does not rely on “trust us” claims—only on cryptographic constraints.

7. Threat Model

7.1 What UniClipboard Protects Against

7.2 Explicit Non-Goals

• Fully compromised devices
• User-leaked passphrases
• OS-level malware

Security is strongest when threat boundaries are stated clearly.

8. User Control & Transparency

Users can:

• Enable or disable encryption at any time
• Control what content is synchronized
• Pause syncing instantly
• Reset encryption (with intentional data invalidation)

Cryptographic logic and protocol design are publicly documented to support independent verification.

9. Conclusion

Encryption in UniClipboard is not an optional feature or a marketing checkbox.

It is the foundation of the product.

We believe:

• Your data belongs to you
• Sync does not imply custody
• Privacy should not be traded for convenience