ClipHop blog

What your clipboard manager actually sees: a threat model

support@cliphop.org (Anshul Garg) — Thu, 23 Apr 2026 00:00:00 GMT

People often treat clipboard managers as utilities — something you install and forget. In practice, a clipboard manager has more privileged access to your personal data than most apps on your phone or laptop: links you're about to send, OTPs you just received, snippets of whatever you're writing, command-line arguments you don't want in shell history, private URLs, partial passwords.

This post walks through the realistic threat model for clipboard managers on both Android and macOS — what the operating system lets any app see, what a sync tool specifically adds, what attackers to actually worry about, and what ClipHop does differently.

It's not a fear piece. It's a factual map of the trust surface.

What the OS lets apps read

macOS

On macOS, the clipboard is essentially public to any app with foreground access. NSPasteboard / UIPasteboard APIs are available to any signed app — no special permission prompt. Apps can poll the clipboard continuously if they want (though aggressive polling is throttled by the system).

macOS 14 added user-visible toasts when an app reads the clipboard in a way that wasn't user-initiated, and some apps respect NSPasteboardTypeTransient and NSPasteboardTypeConcealed flags (used by password managers to signal "don't log this"). Those flags are advisory — a malicious app can ignore them.

Android

Pre-Android 10, any app could read the clipboard at any time, including in the background. Post-Android 10, background clipboard reads are blocked — only the foreground app can read. Post-Android 13, the system shows a "Content pasted" toast when an app reads the clipboard. Post-Android 13, there's also a paste-preview masking option (which ClipHop respects) to hide clipboard content from system keyboard paste suggestions.

The bottom line

The clipboard is less protected than, say, contacts or location. Any app you've trusted enough to install has a plausible way to observe what you copy. A clipboard manager voluntarily occupies that observer role so you can search / pin / sync your clipboard history — you're trading observation access for utility.

That's fine. The question is what the manager does with that access.

What a sync tool adds

A clipboard sync tool specifically does two things the OS clipboard doesn't:

Reads from the source device (like any clipboard manager).
Writes to the destination device (a capability the OS clipboard can't offer across device boundaries).

Both sides are in the trust surface. A compromised sync tool can:

Log every clip before sending.
Forward clips to a third party.
Inject arbitrary content into the destination clipboard (e.g., swap a bitcoin address mid-paste).
Read local history long after the clip was "forgotten."

None of those are hypothetical attacks — clipboard-swap malware is a documented real-world category, especially for cryptocurrency addresses.

The attacker classes worth modeling

For a clipboard sync tool, there are three plausible attacker classes:

1. The sync vendor itself

This is the attacker many people don't consciously model but should. If the sync tool routes your clipboard through the vendor's servers, the vendor has custody of your clipboard stream. That custody is subject to:

Compromise: credentials breach, server intrusion, backups leaking.
Subpoena: legal process forcing disclosure.
Policy change: terms-of-service updates, new parent company after acquisition.
Employee access: internal abuse by a rogue engineer.

Even "end-to-end encrypted" cloud services usually hold some metadata — who connected when, which devices are paired, session times. For a clipboard stream that routinely contains credentials, any custody position is substantial.

ClipHop's answer: there is no server. There is no vendor custody. Clipboard text and key material exist only on the two paired devices. We don't have the option to leak data we never receive.

2. A malicious app on one of your devices

If you install a malicious app on either device in the pair, the threat model degrades fast:

It can read the source clipboard directly (on-device).
It can potentially read the sync tool's local storage if the OS sandbox is breached.
On Android, it can try to listen for the sync tool's foreground service notification to infer activity timing (a side channel).

What sync tools can and can't do about this:

Can: store keys in hardware-backed secure storage (Keychain on Mac, Keystore on Android). Doesn't stop clipboard-level reads, but prevents key exfiltration.
Can: use the system's designated "transient" / "concealed" flags so other apps that respect them skip the paste.
Can't: prevent another legitimate app from reading the clipboard. That's the OS's design.
Can: bias the product toward manual send, so the clipboard leaves the device only when the user explicitly asks for it (see below).

3. A network observer between devices

If the sync tool transmits over a network, an observer on that network can attempt:

Passive eavesdropping (if encryption is weak).
MITM attacks (if identity authentication is weak).
Traffic analysis (timing, size, even on encrypted channels).

ClipHop's answer: transport is Bluetooth LE directly between two paired devices, not a network hop. The attacker has to be within Bluetooth radio range (~10–15 m) to observe traffic at all. Even then: AES-256-GCM with per-reconnect X25519 ECDH session keys, authenticated by Ed25519 long-term identity keys, with user-verifiable identity fingerprints. A passive attacker sees ciphertext. An active attacker has to break the ECDH or impersonate a key — both detected by fingerprint mismatch.

See How ClipHop encrypts your clipboard for the crypto detail.

The content-filtering claim: why it's mostly a lie

A common claim on competing clipboard tools is that they "automatically filter out password-manager pastes" so your passwords never sync. It sounds good. It's also hard to do reliably.

What "password filtering" typically means in practice:

Check if the macOS NSPasteboardTypeTransient / NSPasteboardTypeConcealed flags are set. Password managers that set these will be filtered. Ones that don't, won't.
On Android, check for the flag on the ClipData that newer password managers set. Older ones don't.
Pattern-match for "looks like a password" (high entropy, specific length). False-positive-prone — filters legit tokens, API keys, URLs. False-negative-prone — lets through long diceware passwords.

The result: content-filtering stops some password-manager paste leaks, but you cannot rely on it to catch all of them. OTPs in particular are often unflagged and unfiltered.

ClipHop's answer: we ship manual send by default. Every clipboard item sits in your history until you tap the ✈ send icon. Your clipboard doesn't leave the device unless you pick the item. There's an opt-in Auto-send beta that sends everything automatically — and the app itself warns that auto-send is unfiltered (including passwords and OTPs). We don't claim filtering we can't deliver; instead we design the default flow so you're the filter.

What you can actually check

Before installing any clipboard sync tool — not just ours — ask:

Where does the clipboard go? Server, peer-to-peer, local-only?
Who holds the keys? Vendor, device, neither?
Can you verify the pairing? Fingerprint, certificate, or just "it worked"?
What happens on account compromise? Is there even an account?
What's the send model? Auto-send everything, or opt-in per clip?
What's on disk? Clipboard history, session logs, forwarding queues?
What telemetry does it send? Analytics, crash reports, feature flags?

For ClipHop specifically: peer-to-peer only, keys in hardware-backed storage on each device, fingerprint-verifiable, no accounts, manual send by default, history + identity-only on disk, zero telemetry.

ClipHop vs KDE Connect: when to pick which for Android–Mac clipboard sync

support@cliphop.org (Anshul Garg) — Sun, 19 Apr 2026 00:00:00 GMT

If you use an Android phone with a Mac and care about clipboard sync, two serious non-cloud options exist: KDE Connect and ClipHop. They share almost nothing architecturally — KDE Connect runs over LAN / WiFi, ClipHop runs over Bluetooth LE — and each is the right answer for a different set of constraints.

This post is an honest side-by-side. We built ClipHop because we wanted something KDE Connect doesn't do; we still think KDE Connect is excellent for the scenarios it targets. Here's how to pick.

What each tool actually is

KDE Connect is a cross-platform sync framework from the KDE project. It's open-source, actively maintained, and does much more than clipboards — notifications, file transfer, media control, battery status, remote input, SMS mirroring, shared browser tabs. It runs as a long-lived service on both devices, speaks a JSON-over-TLS protocol, and discovers peers over mDNS on the local network.

ClipHop is a single-purpose tool that only does clipboard sync between one Android phone and one Mac. It runs over Bluetooth LE (no network required), uses X25519 ECDH for per-reconnect session keys on AES-256-GCM, and authenticates with Ed25519 identity keys stored in the Keychain / Keystore. See How ClipHop encrypts your clipboard for the cryptographic detail.

That "only does clipboard" choice is deliberate. Clipboards are the highest-value-per-byte data that moves between devices, and they deserve a focused tool.

Transport differences that actually matter

Criterion	KDE Connect	ClipHop
Transport	TCP/UDP over WiFi (LAN)	Bluetooth LE (L2CAP / GATT)
Works without WiFi	❌	✅
Works on captive-portal WiFi	❌ (no peer-to-peer)	✅
Works on airplanes	❌	✅ (Bluetooth only)
Works on client-isolated WiFi	❌	✅
Works across VLAN boundaries	❌	✅
Discovery	mDNS on local network	BLE scan / advertisement
Range	Whole network	~10–15 m line of sight
Throughput	High (WiFi speeds)	Moderate (~50–200 kbit/s sustained)

The LAN requirement is KDE Connect's one real limitation, and it's a bigger one than it used to be:

Home networks are now commonly mesh-based with client isolation between devices.
Hotel and coffee-shop WiFi almost always has client isolation on.
Corporate networks segment devices by role — personal phone and laptop often can't reach each other.
Travel workflows that cross networks break the pair constantly.

If you're always on the same stable WiFi (a home network with a simple router, say), KDE Connect works beautifully. If you cross networks regularly, it falls over.

BLE doesn't care about any of that. Two paired devices find each other and connect whenever they're in radio range. The trade is range (~10–15 m instead of whole-building) and throughput (fine for text, slow for large files).

Feature surface: broad vs focused

KDE Connect does a lot:

Clipboard sync (both directions)
Notification mirroring (phone → desktop)
File transfer
Remote input (use your phone as a trackpad)
Media control (pause/play on desktop from phone)
Battery level display
Remote commands / SMS mirroring / shared browsers on Linux
Ring-my-phone, find-my-device

ClipHop does one thing:

Clipboard sync (both directions)

That's it. Nothing else. No file transfer, no notifications, no remote control. If you want broad cross-device sync, KDE Connect's feature surface is probably what you want and ClipHop won't cover it.

If clipboard is your real pain point — the 80% of cross-device moves you actually do — a single-purpose tool has advantages: smaller attack surface, fewer permissions, clearer mental model, no "why is it using battery?" moments because the only background work is the clipboard.

Security model

Both tools are honest about their model but the details differ.

KDE Connect:

TLS 1.2+ between devices with certificate pinning (after first-pair).
Pairing is accept-prompt based ("Device X wants to pair").
Per-pair long-term certificates stored locally.
No external trust dependency — but also no user-visible fingerprint to re-verify ongoing.

ClipHop:

X25519 ECDH per reconnect produces a fresh AES-256-GCM session key via HKDF.
Ephemeral key exchange signed by long-term Ed25519 identity keys in the Keychain / Keystore.
Identity fingerprint displayed to user — verify at pair time and any time after from Paired Devices (Android) / Preferences → Security (Mac).
Forward secrecy across sessions.

The fingerprint-verification model is the one meaningful security difference. KDE Connect is secure enough for most threat models but doesn't give you a way to check cryptographically that today's peer is the same peer you paired with yesterday. ClipHop's fingerprint is exactly that check — ongoing MITM detection rather than a one-shot accept-and-trust.

Setup effort

KDE Connect: install both apps, they discover each other on the LAN, accept the pair prompt on both sides. Works immediately if you're on the right network.

ClipHop: install both apps, scan a QR code (or enter a 6-digit code) once, compare fingerprints, done. Pairing persists across restarts and reconnection is automatic.

Roughly equivalent setup friction. KDE Connect is slightly simpler if you're on a compatible network; ClipHop is slightly more explicit and gives you a fingerprint to verify.

Resource cost

On Android specifically, both tools need permissions that non-background apps don't:

KDE Connect runs a foreground service for notifications and maintains TCP connections. Moderate-to-high battery impact depending on activity.
ClipHop runs a foreground service to keep the BLE link alive across screen-off. BLE is radio-efficient relative to WiFi — real-world battery impact is minor.

On Mac, both are menu-bar apps with negligible CPU at idle.

When to pick which

Pick KDE Connect if:

You want broad cross-device sync (notifications, files, media control, remote input), not just clipboard.
Your devices are always on the same WiFi network.
You're comfortable with the "accept the pair prompt" trust model and don't need fingerprint verification.
You prefer fully-open-source, community-audited software today (KDE Connect is FOSS; ClipHop isn't open-source yet but the crypto is documented).

Pick ClipHop if:

Clipboard sync specifically is your pain point.
You travel, co-work, or use coffee-shop WiFi — anywhere that "same LAN" is unreliable.
You want end-to-end encrypted clipboard sync with a verifiable identity fingerprint.
You want a small tool that does one thing and doesn't sit in the background running protocols you don't use.

Run both if:

You can. They don't conflict. A common setup: KDE Connect at home for file transfer and notifications, ClipHop everywhere — including at home — because it works before the WiFi does, and the fingerprint model gives you stronger verification for the clipboard specifically.

The shortest version

KDE Connect is a cross-device sync framework that happens to include clipboards. ClipHop is a clipboard tool that happens to use Bluetooth. Pick the one whose shape fits your actual use.

If you decide ClipHop is worth trying: download the Mac app, grab the Android app from the Play Store, and the 60-second setup guide will have you pasting across devices in one cup of coffee. For the transport reasoning, see Why Bluetooth LE. For the comparison to Apple's side of the world, see Universal Clipboard for Android.

How to sync your clipboard between Android and Mac (without the cloud)

support@cliphop.org (Anshul Garg) — Wed, 15 Apr 2026 00:00:00 GMT

If you live between an Android phone and a Mac, clipboard sync is the boring feature that saves you dozens of paste-in-Messages round-trips a day. Apple's Universal Clipboard doesn't help — it only works between Apple devices. LAN-based tools only help when both devices are on the same WiFi. Cloud clipboards only help if you're willing to hand a copy of your clipboard to a third-party server.

This guide sets up two-way clipboard sync between Android and Mac with a single app pair that doesn't need any of that. You'll be copying-and-pasting across devices in about 60 seconds.

What you need

An Android phone running Android 10 (API 29) or newer, on real hardware. Emulators don't expose the host's Bluetooth radio, so they're not supported.
A Mac running macOS 13 Ventura or newer, Apple Silicon recommended.
Bluetooth turned on on both devices. No WiFi or cellular required.

That's it. No account, no sign-in, no server.

Step 1 — Install the apps

Install the Mac app from the download page — it's a standard .dmg. On first launch, right-click the app icon and choose Open (macOS Gatekeeper asks for this the first time with any direct download).

Install the Android app from the Google Play Store. On first launch the Android app walks you through three permissions: Bluetooth (required, to pair with the Mac), Notifications (for the persistent foreground-service notice), and Skip battery optimization (so Samsung, OnePlus, and Xiaomi skins don't kill the background service after ~15 minutes).

For detailed install guides: Install on Mac and Install on Android.

Step 2 — Pair the two devices

On the Mac: click the ClipHop icon in the menu bar and choose Pair a new device. The Mac shows a QR code and a 6-digit code.

On the Android phone: open ClipHop and tap Pair with Mac. Choose Scan QR (easier) or Enter code (if your camera can't see the Mac screen).

Under the hood, both devices perform an X25519 Elliptic-Curve Diffie-Hellman handshake, authenticated by their long-term Ed25519 identity keys. The output is a shared AES-256-GCM session key that lives in memory only — no server, no cloud, no account is involved. The pair guide walks through the process in more detail.

Step 3 — Verify the identity fingerprint

Once connected, both devices show a short identity fingerprint. Check that the short code on the Mac matches what the phone shows. If it does, your pairing is end-to-end encrypted to the device you actually have in your hand — nothing can MITM this pair.

You can re-verify the fingerprint any time:

On Android: open Paired Devices → tap the paired Mac.
On Mac: open Preferences → Security.

Ongoing verification matters because MITM attacks aren't always caught at pair time. If the fingerprint ever changes, something is wrong and you should unpair and re-pair.

Step 4 — Copy, paste, done

Now the routine part:

Copy anything on the phone (a URL, an OTP you typed out, a shell command) and it's on the Mac's clipboard in under a second.
Copy on the Mac and the Android clipboard updates the moment the clip arrives.

Both platforms have an auto-apply toggle that's on by default — incoming clips overwrite the local clipboard immediately, so you just paste normally (⌘V on Mac, long-press on Android). If you'd rather browse received items before they become your clipboard, you can turn Auto-apply off in settings and clips will sit in history until you pick one.

Sending is manual by default: you tap the ✈ send icon on any history item to push it to the other device. There's an opt-in Auto-send beta that sends every copy automatically, but the app itself warns that this is unfiltered — including passwords and OTPs — so default to manual unless you're in a deliberately-everything workflow.

Does it really work on a plane?

Yes. Bluetooth LE doesn't need WiFi, doesn't need cellular, doesn't need any network at all. The phone and the Mac talk directly to each other over a short-range radio. Airplane mode (without "Bluetooth off") leaves sync working fine. Same for hotel captive portals, coffee-shop networks you don't trust, or co-working spaces where the two devices are on different VLANs.

What clipboard content works?

In v0.1.0:

✅ Plain text
✅ URLs
🚧 Rich text (roadmap)
🚧 Images (roadmap — likely the next major type added)
🚧 Files (roadmap)

For most day-to-day clipboard traffic — links, shell commands, OTPs, notes — plain-text support covers the overwhelming majority of clips.

If something doesn't work

The most common issue isn't pairing — it's Android's aggressive battery killers. Samsung One UI, OnePlus OxygenOS, and Xiaomi MIUI all ship with OEM-level battery policies that stop background services after 10–15 minutes. If your pair drops when you put the phone in your pocket, go to:

Settings → Apps → ClipHop → Battery → Unrestricted (exact path varies by OEM).

Pixel and stock Android almost never need this. The Android install guide has the details.

Why "one phone, one Mac"?

v0.1.0 supports one active pair at a time. That's a deliberate privacy choice: your clipboard only reaches one trusted peer, not broadcast to every device you own. Multi-pair support is on the roadmap, but we wanted to get one-to-one right first — the fingerprint verification model depends on a clear mental picture of who you're connected to.

Under the hood (quick version)

If you want the engineering rationale — why Bluetooth LE over WiFi, iCloud, or LAN-based tools — that's in Why we chose Bluetooth LE for clipboard sync. And if you're curious about the cryptographic specifics (X25519, AES-256-GCM, Ed25519, HKDF) those are in a separate post coming up.

Grab the apps from the download page and copy-paste your way across devices.

Universal Clipboard for Android: what Apple left out (and how ClipHop fills the gap)

support@cliphop.org (Anshul Garg) — Sat, 11 Apr 2026 00:00:00 GMT

Apple's Universal Clipboard is one of those features that feels like magic — copy on your iPhone, paste on your Mac, no dialog, no app, no thought. If every device you own is made by Apple, it's the gold standard of cross-device clipboard sharing.

But the moment you use an Android phone with a Mac — one of the most common real-world setups — Universal Clipboard does exactly nothing for you. It's Apple-only, it always has been, and it always will be. This post walks through what Universal Clipboard actually does under the hood, why there's no Universal Clipboard for Android, what the third-party alternatives look like, and how ClipHop fills the specific Android ↔ Mac gap.

What Universal Clipboard actually does

Universal Clipboard is part of Apple's Continuity framework. When you copy on one signed-in Apple device, it becomes available on every other Apple device signed into the same Apple ID — as long as those devices are:

Running a recent enough OS.
Signed in to the same iCloud account.
Have Bluetooth turned on (used for proximity discovery).
Have WiFi turned on (used for the actual transfer).
Have Handoff enabled in Settings.

The clipboard itself is short-lived — items expire after about two minutes if not pasted. The actual data travels through iCloud (end-to-end encrypted, but still routed through Apple's infrastructure). Bluetooth is used only to discover nearby devices; the clipboard payload rides over a combination of iCloud and peer-to-peer WiFi.

This design works beautifully within Apple's ecosystem. It doesn't work outside it, by design.

Why there's no Universal Clipboard for Android

This is a structural reason, not a technical one. Apple's Continuity stack is deeply tied to the Apple ID, to iCloud, to Handoff, and to platform services that don't exist on Android. Even if Apple wanted to port it — and there's no evidence they do — the architecture assumes both devices are first-party.

The broader pattern: cross-ecosystem clipboard sharing is a gap every major platform has left open, because nobody running one ecosystem has a business reason to invest in integrating the other. The result is a market of third-party tools, each trading off different things.

The three categories of Android-to-Mac clipboard tools

Broadly, the tools that try to bridge Android and Mac clipboards fall into three camps:

1. Cloud clipboards

Apps like various "cross-device clipboard" or "cloud copy-paste" tools solve the platform problem by routing every clip through a third-party server. Pros:

Works anywhere with internet.
Cross-platform support is usually broad (iOS, Android, Mac, Windows, Linux).

Cons:

Account required. You sign up, log in on every device, trust their auth flow.
Your clipboard goes to someone else's server. Even if encrypted in transit, the custody question is real — a clipboard at rest on a third-party server is a subpoena target, a breach target, and a retention-policy target.
Fails without internet. On airplanes, on cellular-only iPads that haven't paid for data, behind captive-portal WiFi — it just doesn't work.

For something as sensitive as clipboard content, handing custody to a SaaS provider is a bad trade. It's the pattern Universal Clipboard also uses — but with Apple as the trusted custodian, which is a very different risk calculus from trusting an indie startup with a small team.

2. LAN-based tools (KDE Connect and friends)

KDE Connect is genuinely excellent software. It synchronizes clipboards, notifications, battery status, file transfers, and media control over a shared local network. If both your Android phone and your Mac are always on the same WiFi, it's the right answer.

Pros:

Open source, actively maintained.
No cloud, no account.
Works for a lot more than just clipboards.

Cons:

Requires shared WiFi. Both devices need to be on the same network with peer-to-peer routing allowed.
Client-isolated networks break it. Coffee shops, hotels, airports, and increasingly even home mesh routers default to isolating clients from each other.
Corporate / guest networks usually block it.
Travel and multi-network workflows are fragile — the moment you step out of your home WiFi, your pair silently stops syncing until you're back.

For users whose devices live on one stable WiFi and don't move, KDE Connect is hard to beat. For users who travel, co-work, or switch networks — it fails more often than it succeeds.

3. Direct-radio pairs (ClipHop)

The third option is what ClipHop does: Bluetooth LE directly between the phone and the Mac, with no server and no network involvement. Pros:

No cloud, no account, no internet. Works on airplanes, captive portals, unknown WiFi, or disconnected entirely.
Short-range and explicit. The two devices are paired and you know exactly which peer you're synced with.
End-to-end encrypted with AES-256-GCM, session keys derived per reconnect via X25519 ECDH, authenticated by Ed25519 long-term identity keys in the Keychain / Keystore.
Identity fingerprint verification to catch MITM — not just at pair time, but any time you want to recheck.

Cons (honest trade-offs):

BLE range is ~10–15 meters. If your phone is in the car two floors down, your pair can drop. For most people this is fine — the phone is on the desk or in the pocket, not across the building.
Throughput is lower than WiFi. For plain text and URLs you can't tell the difference. For large images or files (coming later) WiFi-based tools would be faster.
One-time pairing friction. You scan a QR or enter a 6-digit code once per pair. After that, reconnection is automatic.
v0.1.0 supports one active pair at a time. That's an intentional privacy default — your clipboard only reaches one trusted peer, not broadcast to every device you own.

The comparison at a glance

Criterion	Apple Universal Clipboard	Cloud clipboards	KDE Connect	ClipHop
Works on Android ↔ Mac	❌ Apple-only	✅	✅	✅
No account required	N/A (Apple ID)	❌	✅	✅
Works without internet	❌ iCloud required	❌	✅ LAN only	✅
Works on captive-portal WiFi	❌	Depends	❌	✅
Works on a plane	❌	❌	❌	✅
End-to-end encrypted	✅ via iCloud	Claimed	✅ TLS	✅ AES-256-GCM
No clipboard data on third-party servers	❌ iCloud routes	❌	✅	✅
Identity fingerprint verification	❌	❌	❌	✅
Open-source	❌	Varies	✅	🚧 On roadmap

When to pick what

If you're all-in on Apple, Universal Clipboard is already the right answer — you don't need a third-party tool. But that's not the audience reading this.

If your Android phone and Mac are always on the same WiFi and you want rich cross-device sync beyond just clipboards (notifications, file transfer, media control), KDE Connect is excellent — give it a try.

If you travel, work from coffee shops and co-working spaces, cross captive-portal WiFi regularly, or just want your clipboard to never touch someone else's server, ClipHop is built for exactly that use case.

Try it

ClipHop is free, the Mac app is a direct download, and the Android app is on the Play Store:

Setup takes about 60 seconds — the full walkthrough is in How to sync your clipboard between Android and Mac. If you want the engineering rationale for the transport choice, see Why we chose Bluetooth LE. For the cryptographic detail, there's How ClipHop encrypts your clipboard.

Universal Clipboard is the bar. For everyone outside the Apple ecosystem, the right answer looks different — and that difference is the whole point of ClipHop.

How ClipHop encrypts your clipboard: X25519, AES-256-GCM, and Ed25519

support@cliphop.org (Anshul Garg) — Tue, 07 Apr 2026 00:00:00 GMT

A clipboard is a small, short-lived piece of data that routinely carries passwords, one-time codes, private URLs, diff patches, and half-written messages. That makes end-to-end encryption a baseline requirement, not a marketing bullet — the moment a clipboard touches a third-party server or an untrusted link, it becomes a credential-leak channel.

This post is the complete cryptographic design of ClipHop — the algorithms, the key lifecycle, the storage, what we do to prevent MITM, and what we deliberately don't do. If you're evaluating a clipboard manager and "end-to-end encrypted" is the claim, this is the level of detail you should expect to see before trusting it.

Threat model

The design assumes an attacker who can:

Observe the Bluetooth LE radio traffic between your phone and your Mac.
Inject or modify packets on that radio.
Compromise one of your devices later (post-compromise impact).
Be physically present during pairing (proximity attack).

The design does not try to defend against:

An attacker who has full arbitrary code execution on one of your already-paired devices. At that point they have the session keys and the clipboard itself — no transport crypto saves you.
Side-channel attacks on the underlying cryptographic libraries (we use platform crypto: CryptoKit on macOS, Tink / Keystore-backed primitives on Android).

Everything below is about keeping the two trusted endpoints (your phone, your Mac) the only devices that can read your clipboard traffic, and catching any attempt to insert a third.

Long-term identity: Ed25519

The first time ClipHop launches on a device, it generates an Ed25519 keypair. Ed25519 is a modern elliptic-curve signature scheme (Curve25519 in the Edwards form) that's fast, standards-based, and widely attacked-and-survived.

On macOS, the private key is stored in the Keychain with access limited to the ClipHop app bundle.
On Android, the private key is stored in the Keystore with StrongBox / TEE-backed storage where the hardware supports it.

The private key never leaves the device. It isn't transmitted during pairing, isn't backed up to any cloud, and doesn't exist in any form outside the hardware-backed store on the device that generated it.

The public key is what gets exchanged with paired peers. That's what your peer means when it says "I trust device X": X's Ed25519 public key.

Pairing: authenticating the first exchange

Pairing is the trust-establishment step. You do it once per pair. ClipHop offers two methods:

QR code — the Mac renders a QR containing its device ID and Ed25519 public key (base64url-encoded, prefixed with a version tag). The phone decodes it, storing the Mac's public key as the identity of this pair.
6-digit code — the Mac displays a 6-digit number derived from its public key and the current UTC minute. The phone scans nearby Macs and connects to the one whose code matches. Codes rotate every minute so a stolen code has a small replay window.

In both methods, the phone ends up with one specific Ed25519 public key it trusts for this pair. Any future connection must be cryptographically authenticated as coming from the holder of the corresponding private key.

Session keys: X25519 ECDH + HKDF

Once pairing is complete, every subsequent connection derives a fresh session key. The steps:

Both devices generate ephemeral X25519 keypairs for this session. X25519 is Curve25519 in Montgomery form, used specifically for Elliptic-Curve Diffie-Hellman (ECDH) key agreement.
They exchange ephemeral public keys over the already-connected BLE link.
Each device signs its ephemeral public key with its long-term Ed25519 identity key. The peer verifies the signature against the Ed25519 public key it stored during pairing.
Both sides compute the X25519 ECDH shared secret.
HKDF (HMAC-based Key Derivation Function, RFC 5869) derives the actual session key from the ECDH shared secret plus a context string.

The result is an AES-256-GCM session key that exists only in memory, is scoped to this connection, and is unrelated to the keys from the previous session.

This gives us forward secrecy: if today's session key is compromised, yesterday's clipboard traffic is still undecryptable because the ephemeral X25519 key that produced yesterday's session key was discarded when yesterday's connection ended.

Data encryption: AES-256-GCM

Every clipboard payload and control message is wrapped in AES-256-GCM:

256-bit key (the session key from the step above).
96-bit nonce, unique per message.
Authenticated associated data (AAD) includes the message type and a monotonically increasing sequence number.
128-bit authentication tag.

GCM is authenticated encryption — if a single bit of the ciphertext, nonce, or AAD is modified, the receiver rejects the message. The sequence number in the AAD prevents replay attacks: if an attacker re-sends a previously-captured packet, the receiver's sequence tracking rejects it.

Fingerprint verification: MITM defense

The identity fingerprint you see in the app (two groups of hex codes: "Your phone" and "Paired Mac") is derived from the peer's Ed25519 public key using a keyed hash, truncated to a human-verifiable length.

At pair time, both devices show their view of the fingerprint. If they match, the identity public keys each side has are genuine — no MITM occurred during pairing.

Crucially, you can re-check the fingerprint at any time — not just at pair time:

On Android: Paired Devices → tap the paired Mac.
On Mac: Preferences → Security.

If the fingerprint ever changes for an already-paired peer, something is wrong — you should unpair and re-pair. This is why we treat fingerprint verification as ongoing MITM detection, not a one-shot check.

What we deliberately don't do

A few things that are common in other encrypted messaging / sync tools but deliberately absent here:

No cloud key escrow. Nothing in your keychain ever goes to a server. There's no recovery flow that restores keys from a cloud backup, because there's no cloud backup.
No shared long-term session key. Some older "paired" systems use a single symmetric key that never rotates. We derive fresh session keys per reconnect via ECDH so compromising one session doesn't compromise the rest.
No username/password. There's no account. The only credential is your Ed25519 identity keypair, held in the local secure store.
No clipboard logs on our servers. We don't operate servers. There are no logs to breach.
No telemetry. No crash reports, no analytics, no "which features did you use" beacons.

Storage on each device

What's in your device's secure store after you've paired:

Your device's Ed25519 private + public keypair (identity).
One entry per paired peer: the peer's Ed25519 public key, a friendly name, a timestamp.

What's on disk in app-support storage (not in the secure store):

Your local clipboard history. Plain local storage, protected by biometric lock on Android.

That's the full inventory. There is no other persisted secret, no session log, no forwarded-message queue.

Known limitations

Not yet independently audited. We want to commission a third-party review of the crypto and BLE stack before calling the product 1.0. That's on the roadmap, not done yet.
BLE link-layer security is in addition to, not relied on for, our E2E layer. Some BLE implementations have had bugs at the link layer (KNOB, BIAS, BLUFFS); our E2E encryption is designed to hold even if the BLE link-layer security is compromised, but we can't guarantee that posture without the audit.
Ed25519 and X25519 are classical-curve cryptography. If and when practical quantum computers arrive, they'll be vulnerable. We're watching the post-quantum key-exchange work (Kyber / ML-KEM specifically) and expect to migrate at some point after NIST's recommendations stabilize.

The short version

Identity: Ed25519 keypair per device, stored in Keychain / Keystore, never transmitted.
Session: X25519 ECDH per reconnect, signed with Ed25519 to prevent MITM.
Bulk encryption: AES-256-GCM with per-message nonces and sequence numbers.
Trust: fingerprint comparison at pair time and on demand.
Infrastructure: none. No server, no cloud, no account.

If you want the transport-layer rationale — why Bluetooth LE instead of WiFi, iCloud, or LAN — that's in Why we chose Bluetooth LE for clipboard sync. For the setup flow, see How to sync your clipboard between Android and Mac. To install, head to the download page.

Why we chose Bluetooth LE for clipboard sync (over WiFi, iCloud, and LAN)

support@cliphop.org (Anshul Garg) — Fri, 03 Apr 2026 00:00:00 GMT

If you've tried to move a link from your Android phone to your Mac recently, you already know the constraint: Apple's Universal Clipboard is Apple-only, LAN-based tools require shared WiFi, and cloud clipboards route your text through someone else's servers. Everything else I could find for Android-to-Mac clipboard sync failed on at least one of those three axes.

The clipboard is an unusually sensitive, unusually short-lived piece of data. It carries links, yes — but also passwords, OTPs, diff patches, private snippets, and half-written messages. The right transport has to be ambient, private, and not dependent on any network you don't control. After working through the options, Bluetooth Low Energy (BLE) was the only one that cleared all three.

Here's the rationale.

Option 1: iCloud-backed clipboards (Universal Clipboard)

Apple's Universal Clipboard uses Bluetooth LE for proximity discovery and then routes the actual clipboard text through iCloud. It's convenient, but it has two structural limitations that matter here:

It's Apple-only. No Android support, not now, not planned. If you're using an Android phone, Universal Clipboard does nothing for you.
Your clipboard travels through Apple servers. Apple's iCloud clipboard is end-to-end encrypted in the architectural sense, but it still requires iCloud to be signed in and available. On a plane? On a captive portal? Behind a corporate firewall with iCloud blocked? It stops working.

For Android-to-Mac clipboard sharing specifically, Universal Clipboard isn't a design option — it's ecosystem-locked.

Option 2: LAN-based tools (KDE Connect)

KDE Connect is excellent engineering. It synchronizes notifications, files, clipboards, battery status, and media across devices on the same local network. We used it for years before building ClipHop, and it's still the right answer for people whose devices are always on the same WiFi.

But "always on the same WiFi" is a much smaller set than it used to be. Consider:

Coffee shops and co-working spaces increasingly isolate clients from each other (for good reason). Your phone and your laptop can be on the same SSID and still not route packets between each other.
Hotel WiFi usually has client isolation on.
Enterprise networks segment devices by role — your personal phone and your corporate laptop may not share a subnet even on the same floor.
Airplanes often have WiFi but it's captive-portal-gated.
Travel, multiple residences, dual-SIM phones swapping between home and away networks — the assumption that both devices are on the same LAN degrades fast.

LAN clipboard tools also require both devices to have a known IP address, a reachable port, and the app to be running in the background. Every one of those is a potential source of "why isn't this working?" support.

Option 3: Cloud clipboards

A third category — "cloud clipboard apps" — solves the platform problem (they work everywhere) but asks you to hand over custody. You sign up, trust their encryption claims, agree to let your clips sit on their servers indefinitely, and hope they don't get breached.

For a thing as sensitive and short-lived as a clipboard, that's a bad trade. A cloud clipboard isn't really a clipboard anymore — it's a text-sharing SaaS with a clipboard-shaped interface.

Even for cloud clipboards that claim end-to-end encryption, you're trusting:

Their key-management implementation.
Their client apps not to exfiltrate.
Their business model not to change.
Their compliance posture to hold up under subpoena.

There's a material difference between "encrypted in transit" (most clipboards) and "your text never leaves the two devices you own" (what we wanted).

Option 4: Bluetooth LE

Bluetooth LE sits at the intersection of the constraints we actually have:

Ambient. No network required. The two devices just need to be within radio range of each other.
Private. Packets go directly between the two paired devices. No third party sees them, no server is involved, no account is required.
Universal. Available on essentially every Android phone and every Mac Apple ships. No special hardware.
Standards-based. BLE is a well-understood, well-attacked, well-specified stack with decades of public cryptanalysis.

That last point matters more than it looks. BLE is not an ad-hoc transport — it's in every consumer device, scrutinized by researchers, and has a stable pairing model that we build on top of (rather than inventing a new trust model).

The trade-offs we accepted

No decision is free. BLE's honest costs:

Range is about 10–15 meters in typical indoor conditions. If your phone is in the next room over, your pair can drop. For most of us this is fine — we want the clipboard to work when our phone is on the desk, not when it's in the car two floors down.
Throughput is much lower than WiFi. For plain text and URLs, you can't tell the difference — round-trip is sub-second. For large images or files (coming later), WiFi would be faster. We use L2CAP connection-oriented channels where the device supports them (Android 10+, macOS 13+) to move multi-kilobyte clips in a single frame, with a chunked GATT fallback on older hardware.
Pairing is a one-time cost. Users have to scan a QR or enter a 6-digit code the first time. After that, the pair re-establishes automatically whenever Bluetooth is on and the two devices are in range.
Two-device pair (for now). v0.1.0 supports one active pair at a time — one phone with one Mac. Multi-pair support is on the roadmap, but we made this an intentional privacy default: your clipboard only reaches one trusted peer, not broadcast to every device you own.

Head-to-head

Criterion	Apple Universal Clipboard	KDE Connect	Cloud clipboards	ClipHop (BLE)
Android ↔ Mac	❌ Apple only	✅	✅	✅
Works without internet	❌ iCloud required	✅ LAN only	❌	✅
Works on captive-portal WiFi	❌	❌	Depends	✅
Works on a plane	❌	❌	❌	✅
No account required	N/A	✅	❌	✅
End-to-end encrypted	✅ via iCloud	✅ TLS transport	Claimed	✅ AES-256-GCM
Clipboard stays between your two devices	❌ iCloud routes	✅	❌	✅
Identity fingerprint verification	❌	❌	❌	✅

What about WebRTC, Nearby Share, or [other transport]?

We looked. WebRTC requires a signaling server and TURN fallback — defeats the point. Nearby Share (Google's) is Android-only and doesn't target Mac. AirDrop is Apple-only. Wi-Fi Direct doesn't work cross-vendor reliably. Most "ad-hoc" transports assume identical OS stacks on both sides; BLE is the rare one that doesn't.

What's next

If the trade-offs above sound acceptable for your workflow, the setup guide walks through pairing in about 60 seconds. And if you want the cryptographic detail — how X25519 ECDH, HKDF, AES-256-GCM, and Ed25519 identity keys fit together in ClipHop — that's worth its own post (coming up next).

The short version of the rationale: Bluetooth LE is the only transport that lets your clipboard travel between two devices without depending on a network you don't control, an account you don't want, or a server you'd have to trust. That's why it's the one we chose.

Introducing ClipHop

support@cliphop.org (Anshul Garg) — Mon, 30 Mar 2026 00:00:00 GMT

If you live between an Android phone and a Mac, you already know the dance. Copy a link on the phone, open Messages on the Mac, text it to yourself, wait, paste. Or the reverse: copy a command, open WhatsApp Web, send it to a group where the only member is you.

ClipHop fixes that. Copy on either device, paste on the other. That's the whole product.

Why Bluetooth?

Because everything else leaks.

iCloud-backed clipboards only work between Apple devices and route your text through Apple's servers.
LAN-based tools like KDE Connect only work on networks you control — useless at a coffee shop, on airplane WiFi, or behind a captive portal.
"Cloud clipboard" apps ask you to create an account, trust their encryption claims, and keep sync history on someone else's server forever.

Bluetooth LE is ambient, no-config, and doesn't require either device to be on the same network — or any network at all. That's the right transport for something as short-lived and sensitive as a clipboard.

What's in v0.1.0

QR or 6-digit pairing between one phone and one Mac.
Clipboard sync over BLE, L2CAP where supported, with a GATT fallback.
AES-256-GCM session keys derived from an X25519 ECDH handshake, authenticated by Ed25519 identity keys in the Keychain / Keystore.
Identity fingerprint verification at pair time and any time after — re-open Paired Devices on Android or Preferences → Security on Mac to confirm your connection is still to the device you expect.
Local clipboard history on each device, biometric-locked on Android. On Android 13+, system keyboard paste suggestions can be masked.
Mac panel: hit Return on any history item to copy and auto-paste it back into the previous app (opt-in, requires Accessibility).

What's next

The things we want to earn trust on before calling this 1.0: a third-party audit of the crypto and BLE stack, iOS support (same protocol, different peripheral implementation), and richer file-type support (images first).

Grab it from the download page.

ClipHop blog

What your clipboard manager actually sees: a threat model

What the OS lets apps read

macOS

Android

The bottom line

What a sync tool adds

The attacker classes worth modeling

1. The sync vendor itself

2. A malicious app on one of your devices

3. A network observer between devices

The content-filtering claim: why it's mostly a lie

What you can actually check

Further reading

ClipHop vs KDE Connect: when to pick which for Android–Mac clipboard sync

What each tool actually is

Transport differences that actually matter

Feature surface: broad vs focused

Security model

Setup effort

Resource cost

When to pick which

The shortest version

How to sync your clipboard between Android and Mac (without the cloud)

What you need

Step 1 — Install the apps

Step 2 — Pair the two devices

Step 3 — Verify the identity fingerprint

Step 4 — Copy, paste, done

Does it really work on a plane?

What clipboard content works?

If something doesn't work

Why "one phone, one Mac"?

Under the hood (quick version)

Universal Clipboard for Android: what Apple left out (and how ClipHop fills the gap)

What Universal Clipboard actually does

Why there's no Universal Clipboard for Android

The three categories of Android-to-Mac clipboard tools

1. Cloud clipboards

2. LAN-based tools (KDE Connect and friends)

3. Direct-radio pairs (ClipHop)

The comparison at a glance

When to pick what

Try it

How ClipHop encrypts your clipboard: X25519, AES-256-GCM, and Ed25519

Threat model

Long-term identity: Ed25519

Pairing: authenticating the first exchange

Session keys: X25519 ECDH + HKDF

Data encryption: AES-256-GCM

Fingerprint verification: MITM defense

What we deliberately don't do

Storage on each device

Known limitations

The short version

Why we chose Bluetooth LE for clipboard sync (over WiFi, iCloud, and LAN)

Option 1: iCloud-backed clipboards (Universal Clipboard)

Option 2: LAN-based tools (KDE Connect)

Option 3: Cloud clipboards

Option 4: Bluetooth LE

The trade-offs we accepted

Head-to-head

What about WebRTC, Nearby Share, or [other transport]?

What's next

Introducing ClipHop

Why Bluetooth?

What's in v0.1.0

What's next