Encryption & Protocols

SecurQbit protects your traffic with modern, industry-standard cryptography built on TLS 1.3 — the same proven protocol that secures online banking and HTTPS across the web. That means authenticated AEAD ciphers and a forward-secret key exchange, with no legacy modes to weaken. This page explains the primitives, the handshake, and why these choices were made.

AEAD ciphers

SecurQbit encrypts traffic with the AEAD (Authenticated Encryption with Associated Data) ciphers defined by TLS 1.3. AEAD encrypts and authenticates in a single operation, so every packet is both confidential and tamper-evident — a modified packet is detected and dropped.

• ChaCha20-Poly1305 — fast and constant-time in software, ideal on mobile CPUs without dedicated AES hardware. Often the default on phones.
• AES-256-GCM — extremely fast where hardware AES acceleration is available (most modern devices), with a 256-bit key.

The client and server negotiate the best cipher for your device's capabilities.

Forward secrecy

SecurQbit establishes session keys with an ephemeral elliptic-curve Diffie-Hellman key exchange over X25519 (Curve25519). Each session derives fresh keys from short-lived ephemeral values that are discarded when the session ends.

This provides forward secrecy: even if a long-term key were ever compromised in the future, past sessions could not be retroactively decrypted, because the keys that protected them no longer exist anywhere. Combined with RAM-only servers, there is nothing persisted to go back and unlock.

Handshake overview

The connection runs over a genuine TLS 1.3 session on TCP port 443 — indistinguishable on the wire from ordinary web traffic.

1. Key exchange — client and server each generate ephemeral X25519 key pairs and exchange public values during the TLS 1.3 handshake.
2. Shared secret — both sides compute the same shared secret via elliptic-curve Diffie-Hellman; it is never transmitted.
3. Key derivation — session keys are derived from the shared secret using HKDF, with separate keys per direction.
4. Server authentication — the server proves its identity before any user data flows, defeating man-in-the-middle attempts.
5. AEAD tunnel — all subsequent traffic is encrypted and authenticated with the negotiated AEAD cipher.

Because the carrier is real TLS 1.3 rather than an imitation of it, the session blends into normal HTTPS without a separate, fingerprintable wrapper. See Firewall Bypass & Obfuscation for how that defeats deep packet inspection.

Client ── ephemeral X25519 pubkey ──▶ Server   (TLS 1.3 / TCP 443)
Client ◀── ephemeral X25519 pubkey ── Server
both:  ECDH → shared secret → HKDF → per-direction AEAD keys
data:  AEAD(ChaCha20-Poly1305 | AES-256-GCM) over genuine TLS 1.3

Primitives at a glance

Why these choices

• Built on TLS 1.3 — the most scrutinized, widely deployed secure transport in the world; no downgrade to weak legacy ciphers is possible.
• AEAD over older modes — single-pass authenticated encryption eliminates whole classes of padding-oracle and tampering attacks.
• Two cipher options — ChaCha20-Poly1305 keeps phones without AES hardware fast; AES-256-GCM exploits hardware acceleration where present.
• Ephemeral X25519 key exchange — fast, side-channel-resistant, and forward-secret by design.
• No redundant encryption — already-encrypted traffic (such as the HTTPS you browse) is carried efficiently without a wasteful second layer of bulk crypto, keeping the tunnel fast.
• Standard, well-analyzed primitives — SecurQbit favors widely audited cryptography over novel, unproven schemes.

Note: Encryption protects what you send; obfuscation hides that you're using a VPN. See the Security Architecture for how the layers combine.