KEIBIDROP: Building Post-Quantum Encrypted File Sync

Index

• Why Build This
• Cryptographic Choices
• Architecture
• FUSE Filesystem Challenges
• Cross-Platform Development
• Lessons Learned

Why Build This

Quantum computers will eventually break RSA and elliptic curve cryptography. That is not controversial. The question is when.

The real threat is "harvest now, decrypt later." Adversaries collect encrypted data today, knowing they can decrypt it once quantum computers arrive. If your data has long-term value, this matters now.

KEIBIDROP is a file sync tool that uses post-quantum cryptography. It lets you share files between devices with encryption that will remain secure even after quantum computers arrive.

Cryptographic Choices

We use a hybrid key exchange combining classical and post-quantum algorithms, with symmetric encryption for the transport layer:

• ML-KEM-1024: NIST standardized post-quantum key encapsulation mechanism (FIPS 203, formerly Kyber). Used for key exchange.
• X25519: Classical elliptic curve Diffie-Hellman. Also used for key exchange, as the classical half of the hybrid.
• ChaCha20-Poly1305: Symmetric authenticated encryption for the transport stream.
• HKDF-SHA512: Key derivation from the combined ML-KEM + X25519 shared secrets.

The hybrid approach provides defense in depth: if ML-KEM is broken (it is new), X25519 still protects you, and if X25519 is broken by quantum computers, ML-KEM still protects you.

Go 1.24 includes ML-KEM in the standard library (crypto/mlkem), which made implementation straightforward. For a deeper look at the handshake protocol, see Post-Quantum gRPC. For how keys rotate during long sessions, see Forward Secrecy and Automatic Key Rotation.

Architecture

KEIBIDROP has three components:

• Relay server: Exchanges ephemeral public keys between peers. Never sees file content. See How the Relay Works for the full privacy model.
• Go backend: Handles networking, cryptography, FUSE filesystem, and gRPC transport.
• Rust/Slint UI: Native cross-platform interface. No Electron.

The connection flow:

1. Both peers generate ML-KEM and X25519 keypairs
2. Public keys uploaded to relay server
3. Peers exchange fingerprints out-of-band (via chat, email, etc.)
4. Direct P2P connection established over IPv6
5. All file transfers encrypted end-to-end

We chose IPv6-only to avoid NAT traversal complexity. No STUN/TURN servers means no metadata leakage to third parties.

FUSE Filesystem Challenges

KEIBIDROP mounts as a folder on your computer. Drag files in, they appear on the peer. No special apps needed.

Building a FUSE filesystem was the hardest part. Some of the challenges:

• Deadlocks on Intel Macs: macFUSE has specific threading requirements that cause deadlocks on Intel hardware. See FUSE Deadlocks for the full story.
• Write ordering: Applications write files in unexpected ways. Handling partial writes, truncates, and renames correctly requires careful design. See Write/Release Race Conditions.
• Performance: Every file operation goes through userspace. Block size tuning matters; see Block Size and Performance.
• Cross-platform: macFUSE, WinFsp, and FUSE3 have different APIs and behaviors. cgofuse abstracts some of it, but not all.
• macOS Preview and Finder: Sandboxed apps require special handling of quarantine xattrs and per-file DirectIO control. See macOS Preview and FUSE.

Cross-Platform Development

One codebase runs on macOS (Intel + Apple Silicon), Windows, Linux, iOS, and Android.

The stack:

• Go: Cross-compiles easily. CGO adds complexity but is required for FUSE.
• Rust + Slint: Native UI that compiles to each platform.
• gomobile: Generates iOS and Android bindings from Go code.

The result is a 20MB binary. Compare that to Electron apps that ship ~150-200MB of Chromium.

Lessons Learned

• Go 1.24 ships ML-KEM in stdlib. No third-party crypto libraries needed.
• FUSE is harder than it looks; edge cases and platform quirks consume more time than the initial implementation.
• IPv6-only is limiting. Many networks still lack IPv6. Check yours.
• Hybrid crypto is the right choice. New algorithms need time to build trust.
• Testing P2P systems without external dependencies is possible with careful harness design. See Testing P2P Systems.
• An agent-friendly CLI opened up automation and scripting use cases we did not anticipate. See Building the kd CLI.

The codebase continues to grow. What started as a focused prototype is now a full cross-platform file sharing system with three interfaces (desktop GUI, interactive CLI, agent CLI), a FUSE virtual filesystem, and a post-quantum encrypted transport layer.