Chiffrement et protocoles

SecurQbit protège votre trafic avec une cryptographie moderne et conforme aux standards de l'industrie, construite sur TLS 1.3 — le même protocole éprouvé qui sécurise la banque en ligne et le HTTPS partout sur le web. Cela signifie des chiffrements AEAD authentifiés et un échange de clés à confidentialité persistante, sans mode hérité pour l'affaiblir. Cette page explique les primitives, la poignée de main et pourquoi ces choix ont été faits.

Chiffrements AEAD

SecurQbit chiffre le trafic avec les chiffrements AEAD (Authenticated Encryption with Associated Data) définis par TLS 1.3. L'AEAD chiffre et authentifie en une seule opération, de sorte que chaque paquet est à la fois confidentiel et protégé contre la falsification — un paquet modifié est détecté et rejeté.

• ChaCha20-Poly1305 — rapide et à temps constant en logiciel, idéal sur les processeurs mobiles dépourvus de matériel AES dédié. Souvent le choix par défaut sur les téléphones.
• AES-256-GCM — extrêmement rapide là où l'accélération matérielle AES est disponible (la plupart des appareils modernes), avec une clé de 256 bits.

Le client et le serveur négocient le meilleur chiffrement pour les capacités de votre appareil.

Confidentialité persistante

SecurQbit établit les clés de session avec un échange de clés Diffie-Hellman éphémère sur courbe elliptique via X25519 (Curve25519). Chaque session dérive de nouvelles clés à partir de valeurs éphémères de courte durée qui sont détruites à la fin de la session.

Cela offre la confidentialité persistante : même si une clé à long terme venait à être compromise à l'avenir, les sessions passées ne pourraient pas être déchiffrées rétroactivement, car les clés qui les protégeaient n'existent plus nulle part. Combiné aux serveurs uniquement en RAM, il n'y a rien de persisté à reprendre et à déverrouiller.

Aperçu de la poignée de main

La connexion s'exécute sur une véritable session TLS 1.3 sur le port TCP 443 — indiscernable sur le réseau du trafic web ordinaire.

1. Échange de clés — le client et le serveur génèrent chacun des paires de clés X25519 éphémères et échangent des valeurs publiques pendant la poignée de main TLS 1.3.
2. Secret partagé — les deux parties calculent le même secret partagé via Diffie-Hellman sur courbe elliptique ; il n'est jamais transmis.
3. Dérivation de clés — les clés de session sont dérivées du secret partagé à l'aide de HKDF, avec des clés distinctes par direction.
4. Authentification du serveur — le serveur prouve son identité avant qu'aucune donnée utilisateur ne circule, déjouant les tentatives d'attaque de l'intercepteur.
5. Tunnel AEAD — tout le trafic ultérieur est chiffré et authentifié avec le chiffrement AEAD négocié.

Parce que le support est un véritable TLS 1.3 plutôt qu'une imitation, la session se fond dans le HTTPS normal sans enveloppe distincte et identifiable. Consultez Contournement de pare-feu et obfuscation pour savoir comment cela déjoue l'inspection approfondie des paquets.

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

Les primitives en un coup d'œil

Pourquoi ces choix

• Construit sur TLS 1.3 — le transport sécurisé le plus scruté et le plus largement déployé au monde ; aucune rétrogradation vers des chiffrements hérités faibles n'est possible.
• AEAD plutôt que les anciens modes — le chiffrement authentifié en une seule passe élimine des classes entières d'attaques par oracle de remplissage et par falsification.
• Deux options de chiffrement — ChaCha20-Poly1305 garde rapides les téléphones sans matériel AES ; AES-256-GCM exploite l'accélération matérielle lorsqu'elle est présente.
• Échange de clés X25519 éphémère — rapide, résistant aux attaques par canal auxiliaire et à confidentialité persistante par conception.
• Pas de chiffrement redondant — le trafic déjà chiffré (comme le HTTPS que vous parcourez) est transporté efficacement sans une seconde couche de cryptographie en masse inutile, ce qui garde le tunnel rapide.
• Des primitives standard et bien analysées — SecurQbit privilégie une cryptographie largement auditée plutôt que des schémas inédits et non éprouvés.

Note : Le chiffrement protège ce que vous envoyez ; l'obfuscation cache le fait que vous utilisez un VPN. Consultez l'Architecture de sécurité pour savoir comment les couches se combinent.