Feature · Encryption
Encrypted on every link. End to end.
Speedify encrypts every packet at the device using standards-based cryptography, then distributes the encrypted traffic across every available link. DTLS 1.2 transport, AES-256-GCM or ChaCha20-Poly1305 depending on what your hardware can accelerate, Google's BoringSSL under the hood, and a strict no-logs policy on every server.
Benefits
CONFIDENTIALITY
Every packet, on every link, secured by default.
All your traffic is encrypted at the device before it leaves: web sessions, API calls, file transfers, voice and video, remote desktop. Your ISP, the venue's Wi-Fi operator, the cellular carrier, and anything else on the path see ciphertext.
COMPLIANCE
Industry-standard cryptography, top to bottom.
DTLS 1.2 (RFC 6347), AES-256-GCM, ChaCha20-Poly1305 (RFC 7539, RFC 7905), TLS_ECDHE_PSK key exchange, implemented with Google's BoringSSL. The same primitives that protect Gmail, Chrome, and the rest of the modern web.
PERFORMANCE
Hardware-accelerated where it can be.
Modern desktops, laptops, servers, and phones use built-in CPU instructions for AES with near-zero overhead. Older or constrained devices fall back to ChaCha20-Poly1305, roughly three times faster than software AES on the same hardware.
01 · The Basics
Standard cryptography. Unique integration.
The cryptographic primitives Speedify uses are the same ones that protect every HTTPS website you visit. What's different is where they sit. In a standard VPN, encryption wraps a single tunnel running over a single network path. In Speedify, encryption is integrated with the bonding protocol itself. Every packet is encrypted at the device, then distributed across every available link, then reassembled and decrypted at the Speed Server.
| DTLS 1.2 over UDP | AEAD ciphers | Encrypted across every link | Hardware-adaptive cipher | Strict no-logs policy | |
|---|---|---|---|---|---|
|
SPEEDIFY
Encryption
Encryption is integrated with the bonding protocol. Every packet is encrypted at the device, split across every available link, and reassembled at the server. Cipher choice adapts to hardware. |
|||||
|
Standard VPN
A single encrypted tunnel runs over a single network path. The cipher, transport, and policy depend on the implementation. Link changes typically force a reconnect. |
Deep Dive · Watch
How Speedify's channel bonding technology actually works.
Walk through the protocol, the per-packet distribution model, the failover logic, and the encryption layer in one detailed explainer. The architecture and the engineering tradeoffs that make Speedify different from a load-balancer or a regular VPN.
02 · Under the Hood
Encrypted at the device. Distributed across every link.
Encryption happens before the bonding split, not after. Your device wraps every outbound packet in a DTLS frame using either AES-256-GCM or ChaCha20-Poly1305, depending on what its CPU can accelerate. Only then is the encrypted traffic distributed across Wi-Fi, cellular, satellite, and any other available links. Each link carries ciphertext. The Speed Server reassembles and decrypts. Anyone observing any single link, or all of them, sees only encrypted packets.
ENCRYPTED MULTI-PATH SESSION · LIVE
Encrypted packet · ciphertext in flight
Public link · any provider, any medium
Session origin · DTLS handshake endpoint
Built on standards
No proprietary cryptography.
01
DTLS 1.2 transport
Datagram TLS over UDP (RFC 6347). The same handshake and key derivation that protects HTTPS, but built to tolerate packet loss and reordering across multiple network paths.
02
AEAD ciphers
AES-256-GCM or ChaCha20-Poly1305. Both are authenticated encryption with associated data, meaning every packet is confidential and integrity-protected. Forgeries are detected and dropped.
03
Forward secrecy
Each session uses ephemeral keys via TLS_ECDHE_PSK. Compromising a long-term credential does not let an attacker decrypt past sessions, even if they recorded the ciphertext.
04
BoringSSL implementation
The same TLS library that ships in Google Chrome. Continuously fuzzed, audited, and patched by Google's security team. Speedify gets the same vulnerability response cadence as the world's most-shipped browser.
03 · Modes
Two ciphers. One automatic decision.
The right cipher depends on what your hardware can do. Modern CPUs include native AES instructions that make AES-256-GCM almost free. Older or constrained devices don't, and on those, software AES is the bottleneck. Speedify detects what's available at session start and picks the cipher that runs fastest while delivering equivalent cryptographic strength. The decision is automatic and per-device.
CIPHER 01 · MODERN HARDWARE
AES-256-GCM
The Advanced Encryption Standard with a 256-bit key in Galois/Counter Mode. Authenticated encryption with associated data. On any CPU with AES-NI or equivalent hardware support (most desktops, laptops, servers, and phones built in the last decade), encryption and decryption run as a few CPU instructions per block. Overhead is negligible.
AES-256-GCM
· CIPHER SPEC
Key size
256-bit
Mode
GCM · AEAD
Acceleration
AES-NI · hardware
Standard
NIST FIPS 197
Negotiated as
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384
CIPHER 02 · OLDER / EMBEDDED
ChaCha20-Poly1305
A stream cipher designed for speed on hardware without AES acceleration. Authenticated via Poly1305 MAC. On older phones, low-power IoT, and other software-only environments, ChaCha20-Poly1305 runs roughly three times faster than software AES at the same security level. Cloudflare published the benchmarks that made it standard.
ChaCha20-Poly1305
· CIPHER SPEC
Key size
256-bit
Mode
Stream + Poly1305 MAC
Acceleration
Software-optimized
Standard
RFC 7539 · RFC 7905
Negotiated as
TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
04 · Deployment
Where Speedify installs.
Encryption is part of the core protocol, not an optional add-on. Wherever Speedify runs, the same DTLS tunnel and the same cipher selection logic apply. No certificate provisioning, no IPsec policy templates, no platform-specific configuration drift across the fleet.
A · Device Level
Run Speedify as an app.
Install the Speedify app on Windows, macOS, Linux, iOS, or Android. The device handles its own DTLS handshake, picks its own cipher based on the local CPU, and encrypts every packet before it goes out over any link the device is using.
Licensing
For businesses, this is provided through a Speedify Teams subscription, which centralizes billing, user provisioning, permissions, and usage analytics across your organization.
Best For
Mobile workforces, remote employees on public Wi-Fi, traveling executives, livestream and creator rigs, and individual workstations with multiple WAN sources.
B · Network Level
Run Speedify on a router.
Run Speedify on a supported router and every device on the LAN gets the same DTLS-protected uplink automatically, with no per-device install. The router handles encryption upstream, devices behind it stay unmodified.
Licensing
Network-level deployment is licensed via Speedify for Routers, available two ways:
Speedify for Routers
Add Speedify to a supported OpenWrt router you already own.
Powered by Speedify routers
Hardware with Speedify preinstalled and licensed out of the box. Miri, GL.iNET, and other partners.
Best For
Offices, branch locations, retail sites, vessels, aircraft, remote camps, and any deployment with multiple users or unmanaged devices that need encrypted uplinks without per-device provisioning.
Note
Many businesses run both at once. A router covers everyone in the building. The app travels with people who leave it. For OEMs and software vendors, Speedify's channel bonding can also be licensed as an SDK that embeds into your own iOS, Android, Windows, macOS, or Linux product. See Powered by Speedify.
04 · In production
Where Speedify earns its keep.
Encryption matters most where the network you're using isn't one you control: someone else's Wi-Fi, someone else's cellular, someone else's satellite. A short list of where Speedify's encryption is already protecting traffic today.
Spotlight
Speedify Self-Hosted Servers
For organizations with data residency, compliance, or sovereignty requirements, self-hosted Speedify servers let you control both ends of the encrypted tunnel. The same DTLS 1.2 transport and AEAD ciphers, terminating inside your own infrastructure, in a location and jurisdiction of your choosing.
Learn more →
SESSION · LIVE
Transport
DTLS 1.2 / UDP
Cipher
AES-256-GCM
Key exchange
ECDHE-PSK
Server
Your data center
Logs retained
None
Maritime
Encrypted comms over Starlink and cellular
Crew traffic, operational data, and vessel telemetry encrypted before it hits any satellite or cellular network. Carriers and satellite operators see ciphertext, not your fleet's business.
Learn more →
Aviation
Air-to-ground encrypted boundary
Bonded Ku/Ka, Starlink Aero, and ATG links carry encrypted traffic only. The encrypted boundary holds across satellite handoffs, regional transitions, and link degradation at altitude.
Learn more →
Remote Operations
Mining, oil & gas, construction, defense
Sensitive operational data, telemetry, and field communications protected end-to-end over whatever carrier, satellite, or microwave link is available. Encryption that holds at sites without fixed infrastructure.
Learn more →
Live Broadcast
Encrypted source-to-server video
Field crews uploading high-bitrate video over bonded cellular and satellite. Source feeds encrypted before they leave the camera bag, decrypted only at the broadcast facility's server.
Learn more →
Get in touch with Speedify
Get in touch today to discuss your business’s needs and discover how Speedify can help deliver, faster, more reliable, and more secure online experiences.