Encryption Overview
SwiftDrop uses modern, peer-reviewed cryptography throughout the transfer pipeline. Encryption is applied at every layer with no performance trade-offs.
Summary
| Layer | Algorithm | Key size | Notes |
|---|---|---|---|
| Key exchange | X25519 ECDH | 256-bit | Ephemeral per session |
| Session key derivation | HKDF-SHA256 | 256-bit | Forward secrecy |
| Data encryption | AES-256-GCM | 256-bit | Authenticated encryption |
| Integrity | GCM authentication tag | 128-bit | Per frame |
Key exchange
Before any file data is transmitted, both devices perform an Elliptic Curve Diffie-Hellman key exchange using Curve25519 (X25519):
- Each device generates a fresh ephemeral key pair for the session.
- Public keys are exchanged over the transfer control channel.
- Both sides independently compute the same shared secret using their own private key and the peer's public key.
- The shared secret is fed into HKDF-SHA256 to derive the final session key.
Because key pairs are ephemeral (generated fresh per transfer), compromising a device's long-term key does not compromise past transfers. This is perfect forward secrecy.
Data encryption
File data is sent in frames. Each frame is encrypted with AES-256-GCM:
- A unique nonce is generated for each frame using the frame counter.
- The entire frame payload is encrypted and authenticated.
- GCM produces an authentication tag that detects any tampering in transit.
Relay transparency
When using Office Tunnel relay:
- The relay creates a virtual pipe between two devices and forwards encrypted frames.
- The relay cannot read file contents or metadata — it only sees binary ciphertext.
- Session key exchange happens device-to-device, not device-to-relay.
What Zashiron does not receive
SwiftDrop does not send file names, sizes, or content to Zashiron's servers. The only data the backend receives is device IDs and org membership (for access control) and aggregated transfer volumes (for billing).