X25519 Chiffrer & Déchiffrer

Outil en ligne gratuit X25519 Chiffrer & Déchiffrer. Traitement 100% local — vos données ne quittent jamais votre appareil.

National Standards
Other
Sortie

Le résultat sera affiché ici...

Entrée → Chiffrer

Usage Guide

À propos de X25519 (Curve25519 ECDH)

X25519 est la fonction d'échange de clés Diffie-Hellman basée sur Curve25519, standardisée dans la RFC 7748. C'est l'algorithme d'échange de clés à courbe elliptique le plus largement déployé au monde — utilisé comme échange de clés par défaut dans TLS 1.3, WireGuard VPN, Signal Protocol et le Noise Protocol Framework. X25519 offre ~128 bits de sécurité avec des clés de 32 octets, est conçu pour résister aux attaques par canal auxiliaire et a été créé par Daniel J. Bernstein.

Échange de clés — pas de chiffrement : X25519 effectue uniquement un accord de clés. Il produit un secret partagé que les deux parties peuvent calculer indépendamment — il ne chiffre ni ne déchiffre aucune donnée par lui-même. Vous devez utiliser le secret partagé résultant comme clé pour un chiffrement symétrique tel que ChaCha20-Poly1305 ou AES-256-GCM pour atteindre la confidentialité.

Étapes d'utilisation

Cet outil calcule le secret partagé Diffie-Hellman X25519 à partir de votre clé privée et de la clé publique de votre correspondant :

•
1. Générer une paire de clésCliquez sur 'Générer une paire de clés' pour créer une nouvelle paire de clés X25519. La clé privée (64 caractères hexadécimaux) est remplie dans le champ 'Ma clé privée'. La clé publique correspondante est stockée en interne — copiez-la et partagez-la avec votre correspondant par un autre canal.
•
2. Échanger les clés publiquesEnvoyez votre clé publique (64 caractères hexadécimaux) à votre correspondant. Recevez la sienne et collez-la dans le champ 'Clé publique du correspondant (Hex)'. Cet échange peut se faire via n'importe quel canal — la clé publique n'est pas secrète.
•
3. Calculer le secret partagéCliquez sur 'Chiffrer'. L'outil effectue DH(votre_clé_privée, clé_publique_correspondant) et affiche un secret partagé hexadécimal de 64 caractères (32 octets). Votre correspondant effectue la même opération en sens inverse et obtient le secret partagé identique.
•
4. Utiliser le secret partagé pour chiffrerIntroduisez le secret partagé (ou une clé dérivée par KDF) dans un chiffrement symétrique comme AES-256-GCM ou ChaCha20-Poly1305. Dans les systèmes de production, le secret partagé ne doit pas être utilisé directement comme clé de chiffrement sans dérivation de clé (ex. HKDF).
Navigateur uniquement : Toutes les opérations de génération de clés et de calcul DH s'exécutent entièrement dans votre navigateur via l'API WebCrypto. Aucune clé n'est jamais transmise à un serveur.

Format des clés

Les clés X25519 dans cet outil utilisent un format hexadécimal compact :

•
Clé privée64 caractères hexadécimaux = 32 octets. Une valeur scalaire aléatoire. À garder secrète. Exemple : a3f1e2d4c5b6a7f8e9d0c1b2a3f4e5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2
•
Clé publique64 caractères hexadécimaux = 32 octets. Le résultat de la multiplication du point de base sur Curve25519 par le scalaire privé. Peut être partagée publiquement. Exemple : 5b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8
•
Secret partagé64 caractères hexadécimaux = 32 octets. Calculé comme DH(ma_privée, publique_correspondant) = DH(privée_correspondant, ma_publique). Cette égalité est le fondement mathématique de l'échange de clés Diffie-Hellman.
•
Clés non interchangeablesLes clés X25519 et Ed25519 semblent identiques (64 caractères hex, 32 octets) mais utilisent des représentations internes différentes et NE sont PAS interchangeables. N'utilisez jamais une clé privée Ed25519 comme clé privée X25519 ni l'inverse.

X25519 vs. EdDSA (Ed25519)

X25519 et Ed25519 sont tous deux basés sur Curve25519 mais servent des objectifs cryptographiques complètement différents :

•
ObjectifX25519 : échange de clés (Diffie-Hellman). Ed25519 : signatures numériques (authentification). Ils ne peuvent pas se substituer l'un à l'autre.
•
Forme mathématiqueX25519 utilise la forme de Montgomery de Curve25519 pour une multiplication scalaire efficace. Ed25519 utilise la forme d'Edwards tordue. Bien que birationnellement équivalentes, les encodages de clés diffèrent.
•
Clés non interchangeablesLes clés NE sont PAS interchangeables malgré la même longueur en octets. Utiliser une paire de clés Ed25519 pour X25519 DH est un usage cryptographique abusif pouvant compromettre la sécurité.
•
Usage combinéEn pratique, des protocoles comme Signal utilisent les deux ensemble : X25519 pour l'accord de clés (établissement de la clé de session) et Ed25519 pour l'authentification (signature de l'échange de clés pour prévenir les attaques MITM).
Outils associés : Pour les signatures numériques, utilisez l'outil EdDSA (Ed25519). Pour le chiffrement symétrique avec le secret partagé, utilisez ChaCha20-Poly1305 ou AES-256-GCM.

FAQ

Q: Quelle est la différence entre X25519 et ECDH ?

A: X25519 est ECDH — plus précisément, Diffie-Hellman à courbe elliptique instancié sur Curve25519, défini dans la RFC 7748. Comparé à ECDH sur les courbes NIST (P-256, P-384), X25519 est plus rapide, a une implémentation plus simple et plus sûre (pas de problèmes de cofacteur, pas de validation de points requise pour les entrées typiques), et a été conçu dès le départ pour résister aux attaques d'implémentation. Quand les gens disent "ECDH avec Curve25519", ils parlent de X25519.

Q: Les clés X25519 et Ed25519 peuvent-elles être utilisées de manière interchangeable ?

A: Non. Bien que X25519 et Ed25519 soient tous deux basés sur Curve25519, ils utilisent des représentations mathématiques différentes (forme de Montgomery vs. forme d'Edwards tordue) et des encodages de clés différents. Une clé privée X25519 est un scalaire brut de 32 octets ; une clé privée Ed25519 est une graine de 32 octets qui est hachée (SHA-512) avant utilisation. Bien que des formules de conversion existent, les utiliser de manière interchangeable sans conversion explicite est cryptographiquement incorrect et peut divulguer des informations ou produire des résultats invalides. Générez toujours des paires de clés séparées pour chaque usage.

Q: Comment chiffrer des données avec le secret partagé ?

A: Le secret partagé X25519 de 32 octets doit être passé dans une Fonction de Dérivation de Clé (KDF) avant d'être utilisé comme clé de chiffrement. En pratique, HKDF-SHA256 est le choix le plus courant (utilisé dans TLS 1.3, Signal). Passez le secret brut comme matériau de clé d'entrée, incluez un sel et une chaîne d'info spécifiques au protocole, et dérivez 32 octets pour AES-256-GCM ou ChaCha20-Poly1305. Pour les cas simples, vous pouvez utiliser le secret directement comme clé AES-256 de 32 octets, mais HKDF est fortement recommandé en production.

Q: X25519 offre-t-il la confidentialité persistante (forward secrecy) ?

A: Oui — lorsqu'il est utilisé avec des paires de clés éphémères. La confidentialité persistante (également appelée Perfect Forward Secrecy, PFS) signifie que compromettre une clé long terme n'expose pas les clés de session passées. Dans TLS 1.3, les deux parties génèrent de nouvelles paires de clés X25519 pour chaque handshake (DH éphémère). Même si un attaquant obtient ultérieurement la clé privée long terme d'un serveur, il ne peut pas déchiffrer le trafic enregistré précédemment car les clés X25519 éphémères ont été supprimées après le handshake. Les clés X25519 statiques (réutilisées) ne fournissent pas de confidentialité persistante.

Q: X25519 est-il résistant aux attaques quantiques ?

A: Non — pas face à un ordinateur quantique suffisamment puissant. Un ordinateur quantique exécutant l'algorithme de Shor pourrait casser X25519 en résolvant le problème du logarithme discret sur courbe elliptique en temps polynomial. Cela s'applique également à tous les schémas Diffie-Hellman sur courbe elliptique et corps fini. Cependant, l'ordinateur quantique requis (des milliers de qubits logiques corrigés d'erreurs) n'existe pas encore. Pour l'échange de clés post-quantique, le NIST a standardisé ML-KEM (anciennement CRYSTALS-Kyber). TLS 1.3 dans Chrome et Firefox déploie déjà l'échange de clés hybride X25519+ML-KEM.

Use Cases

Recommandé : Échange de clés TLS 1.3

X25519 est l'algorithme d'échange de clés préféré dans TLS 1.3 (RFC 8446) et est supporté par tous les principaux navigateurs et serveurs. Dans TLS 1.3, le client et le serveur génèrent chacun des paires de clés X25519 éphémères, échangent des clés publiques dans ClientHello/ServerHello et dérivent les clés de handshake avec HKDF. Cela fournit la confidentialité persistante et se complète en un seul aller-retour. X25519 a remplacé l'échange de clés RSA et les variantes ECDH plus anciennes dans la suite de chiffrement obligatoire de TLS 1.3.

Recommended Configuration:
  • ✅ Activer TLS 1.3 sur tous les serveurs — X25519 est inclus automatiquement
  • ✅ X25519 fournit la confidentialité persistante à chaque handshake TLS 1.3
  • ✅ Supporté nativement dans OpenSSL, BoringSSL, NSS et toutes les principales bibliothèques TLS
  • ❌ Ne pas utiliser l'échange de clés RSA TLS 1.2 — manque de confidentialité persistante
Recommandé : WireGuard VPN

WireGuard utilise X25519 comme seul mécanisme d'échange de clés. Chaque pair WireGuard possède une paire de clés X25519 statique (pour l'authentification) et génère des paires de clés X25519 éphémères pour chaque handshake (pour la confidentialité persistante). Le protocole utilise également X25519 pour le mélange de clés pré-partagées et emploie le Noise Protocol Framework. La conception minimaliste de WireGuard — un algorithme d'échange de clés, un chiffrement symétrique (ChaCha20-Poly1305), un hash (BLAKE2s) — le rend vérifiable et rapide.

Recommended Configuration:
  • ✅ X25519 est le seul échange de clés dans WireGuard — rien à configurer
  • ✅ Générer une paire de clés statique : wg genkey | tee private.key | wg pubkey > public.key
  • ✅ WireGuard fournit automatiquement la confidentialité persistante via des paires de clés éphémères
  • 💡 WireGuard combine : X25519 (échange de clés) + ChaCha20-Poly1305 (chiffrement) + BLAKE2s (hash)
Recommandé : Messagerie chiffrée de bout en bout (Signal, WhatsApp)

Le Signal Protocol (utilisé par Signal, WhatsApp et bien d'autres) utilise X25519 intensivement dans son algorithme Double Ratchet et l'accord de clés X3DH (Extended Triple Diffie-Hellman). X3DH utilise plusieurs opérations DH X25519 pour établir des clés partagées initiales entre des parties pouvant être hors ligne. Le Double Ratchet dérive ensuite continuellement de nouvelles clés du cliquet X25519, offrant à la fois la confidentialité persistante et la récupération après intrusion. Cela est considéré comme l'étalon-or pour la messagerie sécurisée.

Recommended Configuration:
  • ✅ X25519 est le fondement de l'accord de clés du Signal Protocol
  • ✅ X3DH permet l'établissement asynchrone de clés (une partie peut être hors ligne)
  • ✅ Double Ratchet + X25519 offre confidentialité persistante et sécurité post-compromission
  • 💡 WhatsApp, Wire, Facebook Messenger chats secrets utilisent tous Signal Protocol
Recommandé : Chiffrement hybride (encapsulation de clés)

Le chiffrement hybride utilise X25519 pour établir un secret partagé, puis chiffre les données réelles avec un chiffrement symétrique. Ce modèle (appelé ECIES ou HPKE — Hybrid Public Key Encryption, RFC 9180) permet à quiconque possédant la clé publique X25519 du destinataire d'envoyer des données chiffrées sans secrets partagés préalables. L'expéditeur génère une paire de clés X25519 éphémère, calcule un secret partagé avec la clé publique du destinataire, dérive une clé symétrique via HKDF, chiffre les données avec ChaCha20-Poly1305 et envoie la clé publique éphémère avec le texte chiffré.

Recommended Configuration:
  • ✅ Utiliser HPKE (RFC 9180) pour le chiffrement hybride standardisé avec X25519
  • ✅ La paire de clés éphémère de l'expéditeur garantit la confidentialité persistante pour chaque message
  • ✅ Combiner : X25519 (échange de clés) + HKDF (dérivation de clé) + AES-256-GCM (chiffrement)
  • 💡 Ce modèle est utilisé par age (outil de chiffrement de fichiers) et la bibliothèque Tink
Déconseillé : Utiliser X25519 seul pour la confidentialité

X25519 produit uniquement un secret partagé — il ne chiffre aucune donnée. Le secret partagé lui-même n'est pas un texte chiffré ; toute partie effectuant le même calcul DH (avec les bonnes clés) l'obtient. Sans chiffrement symétrique appliqué par-dessus, vos données restent en clair. C'est un usage fondamentalement incorrect de l'algorithme. Combinez toujours X25519 avec AES-256-GCM ou ChaCha20-Poly1305 pour réellement protéger les données.

Recommended Configuration:
  • ❌ Ne pas traiter le secret partagé X25519 comme un texte chiffré — c'est une clé, pas des données chiffrées
  • ❌ Ne pas omettre la dérivation de clé — traiter le secret avec HKDF avant de l'utiliser comme clé de chiffrement
  • ✅ X25519 + HKDF + AES-256-GCM est le modèle correct de chiffrement hybride
  • 💡 X25519 résout le problème de distribution de clés ; le chiffrement symétrique résout la confidentialité des données

Résumé des bonnes pratiques

  • X25519 est un algorithme d'échange de clés — il produit un secret partagé, pas un texte chiffré. Toujours le combiner avec AES-256-GCM ou ChaCha20-Poly1305 pour chiffrer les données réelles.
  • Traiter le secret partagé X25519 via HKDF-SHA256 avant de l'utiliser comme clé de chiffrement symétrique dans les systèmes de production.
  • Utiliser des paires de clés X25519 éphémères (générer une nouvelle paire par session) pour atteindre la confidentialité persistante.
  • Ne pas utiliser les clés X25519 comme clés de signature Ed25519 ni l'inverse — bien que toutes deux soient de 32 octets, les représentations internes diffèrent.
  • X25519 est le standard pour TLS 1.3, WireGuard et Signal Protocol — le préférer à l'ancien ECDH avec courbes NIST pour les nouvelles implémentations.

Discussion et commentaires

0 commentaires
Moi