Chiffrement à clé publique et à clé privée : fonctionnement et cas d’usage

Une clé publique et une clé privée sont les deux moitiés d’une paire de clés utilisée dans le chiffrement asymétrique. La clé publique peut être partagée librement : elle sert à chiffrer des données ou à vérifier une signature numérique. La clé privée reste secrète : elle sert à déchiffrer des données ou à créer une signature. Le chiffrement symétrique fonctionne autrement : une seule clé secrète partagée chiffre et déchiffre, ce qui le rend rapide mais pose la question du partage sûr de cette clé. En pratique, les systèmes combinent les deux. La cryptographie à clé publique authentifie les parties et établit une clé de session, puis un chiffrement symétrique tel qu’AES-256 protège les données elles-mêmes.

Aucune des deux approches n’est « plus sûre » en général. La sécurité dépend de l’algorithme, de la taille de la clé, de l’implémentation et, avant tout, de la façon dont les clés sont générées, stockées, renouvelées et contrôlées. Les algorithmes à clé publique tels que RSA et la cryptographie sur courbes elliptiques sont aussi ceux qu’exposeront les futurs ordinateurs quantiques, ce qui explique que la transition vers des standards post-quantiques ait commencé. Kiteworks fournit un plan de contrôle pour l’échange sécurisé de données qui applique le chiffrement AES-256 avec des clés détenues par le client, prend en charge l’intégration de modules de sécurité matériels (HSM) et s’appuie sur une cryptographie validée pour protéger les données sensibles en transit et au repos.

Cette page fournit des informations générales et ne constitue pas un conseil juridique ou de conformité. Pour savoir comment les exigences de chiffrement et de gestion des clés s’appliquent à votre organisation, adressez-vous à votre équipe sécurité, juridique ou conformité.

Points clés à retenir

1. Une clé publique et une clé privée sont les deux moitiés d’une même paire

N’importe qui peut détenir la clé publique, mais seul son propriétaire doit détenir la clé privée. Les données chiffrées avec la clé publique ne peuvent être déchiffrées qu’avec la clé privée correspondante, et une signature créée avec la clé privée peut être vérifiée par toute personne disposant de la clé publique.

2. « Clé privée » ne veut pas dire « clé symétrique »

Dans la terminologie standard, une clé privée est la moitié secrète d’une paire asymétrique, et une clé symétrique se nomme clé secrète. De nombreux articles, surtout en anglais, désignent par abus le chiffrement symétrique comme du « chiffrement à clé privée », ce qui entretient la confusion sur les algorithmes et les propriétés qui relèvent de chaque famille.

3. Les systèmes modernes utilisent les deux ensemble

La cryptographie à clé publique authentifie et échange les clés, et le chiffrement symétrique protège le gros des données. Cette conception hybride est celle de TLS, SSH, S/MIME et PGP : elle associe les avantages de l’une pour la distribution des clés à la vitesse de l’autre.

4. La gestion des clés détermine la sécurité réelle

Un algorithme robuste ne compense pas une clé privée exposée ou mal contrôlée. Des référentiels tels que CMMC, HIPAA et le RGPD s’intéressent à la manière dont les clés sont générées, stockées, renouvelées et détruites, et à la personne qui les contrôle.

5. Les algorithmes à clé publique font face à une transition quantique

Des ordinateurs quantiques exécutant l’algorithme de Shor pourraient casser RSA, la cryptographie sur courbes elliptiques et Diffie-Hellman, tandis que l’AES-256 reste considéré comme sûr. Les organisations devraient recenser les usages de la cryptographie à clé publique et planifier la migration vers les standards post-quantiques.

Quelle est la différence entre une clé publique et une clé privée ?

Une clé publique chiffre des données ou vérifie une signature, et la clé privée correspondante déchiffre des données ou crée une signature. Les deux clés sont liées mathématiquement, mais connaître la clé publique ne permet à personne de retrouver la clé privée avec un effort réaliste, lorsque l’algorithme et la taille de clé sont adaptés.

Le « chiffrement à clé privée » est-il la même chose que le chiffrement symétrique ?

De façon informelle, de nombreuses sources emploient « chiffrement à clé privée » pour désigner le chiffrement symétrique, au motif que la clé partagée doit rester privée. En français, on parle plus volontiers de chiffrement à clé secrète, mais l’expression « clé privée » circule aussi par calque de l’anglais. Cet usage entre en conflit avec la terminologie cryptographique standard, où « clé privée » désigne la moitié secrète d’une paire de clés en cryptographie asymétrique. Cet article utilise les termes standard : le chiffrement symétrique repose sur une seule clé secrète, et le chiffrement asymétrique sur une clé publique et une clé privée. Par exemple, AES-256 utilise une clé secrète, pas une clé privée. Consultez notre guide sur le chiffrement AES-256 pour comprendre le fonctionnement de ce chiffrement.

Qu’est-ce que le chiffrement symétrique ?

Le chiffrement symétrique utilise la même clé secrète pour chiffrer et déchiffrer. Des algorithmes tels que l’AES sont rapides et efficaces : ils protègent donc la plupart des fichiers stockés, des contenus de bases de données et du trafic réseau. Sa faiblesse tient à la distribution des clés : les deux parties ont besoin de la même clé, et l’envoyer sur un réseau non fiable l’expose. C’est cette limite que résout la cryptographie à clé publique.

Qu’est-ce que le chiffrement asymétrique (à clé publique) et comment fonctionne-t-il ?

Le chiffrement asymétrique utilise une paire de clés. Le propriétaire génère la paire et publie la clé publique. Pour envoyer un message confidentiel, l’expéditeur le chiffre avec la clé publique du destinataire, et seule la clé privée du destinataire peut le déchiffrer. Pour prouver l’origine d’un message, le propriétaire le signe avec sa clé privée, et chacun peut vérifier la signature avec la clé publique.

Les principales familles d’algorithmes sont les suivantes :

• RSA : repose sur la difficulté de factoriser le produit de deux grands nombres premiers. Il prend en charge le chiffrement comme les signatures.
• Cryptographie sur courbes elliptiques (ECC) : repose sur la difficulté du problème du logarithme discret sur courbe elliptique. Elle offre une force comparable avec des clés bien plus petites et sert aux signatures (ECDSA, Ed25519) et à l’accord de clé (ECDH, X25519).
• Diffie-Hellman : un protocole d’accord de clé, et non un algorithme de chiffrement. Il permet à deux parties de dériver un secret partagé sur un canal ouvert.

Comme les opérations à clé publique sont lentes et ne traitent que de petites entrées, elles servent à protéger des clés et des empreintes, pas de gros fichiers.

Comment se comparent les tailles de clé selon les algorithmes ?

Les algorithmes n’exigent pas les mêmes longueurs de clé pour offrir la même force de sécurité. La norme NIST SP 800-57 donne les équivalences approximatives suivantes :

Comparer directement les longueurs de clé est trompeur. Une clé ECC de 256 bits offre à peu près la même force qu’une clé RSA de 3 072 bits et qu’une clé AES de 128 bits, et non celle d’une clé AES de 256 bits.

Comment fonctionnent les signatures numériques et les certificats ?

Une signature numérique commence par l’empreinte (hash) du message. Le signataire signe cette empreinte avec sa clé privée, et le destinataire vérifie la signature avec la clé publique. Une signature valide montre que le message provient du détenteur de la clé privée et qu’il n’a pas été modifié ; dans un système correctement encadré, elle contribue à la non-répudiation. Le chiffrement seul n’apporte pas ces garanties : l’intégrité et l’authenticité exigent donc des signatures, des codes d’authentification de message ou un chiffrement authentifié.

Reste à savoir comment s’assurer qu’une clé publique appartient bien à la partie qu’elle prétend représenter. Une autorité de certification (AC) y répond en délivrant un certificat numérique qui lie une clé publique à une identité, puis en signant ce certificat avec sa propre clé privée. Le titulaire du certificat, par exemple un serveur web, détient la clé privée correspondante. Les navigateurs et les systèmes d’exploitation font confiance à un ensemble d’AC racines, et une chaîne de certificats relie chaque certificat à l’une d’elles. Des listes de révocation et des vérifications d’état en ligne permettent aux AC de retirer les certificats dont les clés ont été compromises. L’ensemble de ces éléments constitue une infrastructure à clé publique (PKI).

Comment les clés publique et privée fonctionnent-elles avec l’AES ?

La plupart des systèmes sécurisés reposent sur une conception hybride. Une connexion TLS 1.3 classique, le protocole qui sous-tend HTTPS, se déroule ainsi :

1. Le client contacte le serveur, et les deux s’accordent sur les suites de chiffrement.
2. Ils exécutent un échange de clés Diffie-Hellman éphémère sur courbe elliptique pour dériver un secret partagé. Les clés étant éphémères, le trafic enregistré ne peut pas être déchiffré ultérieurement si une clé à long terme est compromise (confidentialité persistante, ou forward secrecy).
3. Le serveur présente son certificat et prouve qu’il possède la clé privée correspondante en signant la négociation (handshake). Le client valide la chaîne de certificats.
4. Les deux parties dérivent des clés de session symétriques, et un chiffrement authentifié tel qu’AES-GCM protège le reste de la session.

Le même schéma se retrouve ailleurs. SSH, les VPN IPsec, S/MIME et PGP utilisent tous la cryptographie à clé publique pour authentifier les parties et pour protéger ou convenir d’une clé de session ou de message, puis un chiffrement symétrique pour protéger les données. Dans le chiffrement de fichiers, on parle souvent de chiffrement par enveloppe : une clé de données aléatoire chiffre le fichier, et une clé de chiffrement de clé ou une clé publique protège cette clé de données. Pour comprendre en détail la partie symétrique, lisez notre article sur la protection au-delà de l’AES-256, et découvrez des exemples concrets de chiffrement de bout en bout.

Quel type de chiffrement utiliser ?

Il est rare de devoir choisir l’un ou l’autre. Associez chaque outil à son usage :

• Données volumineuses au repos ou en transit : utilisez un chiffrement symétrique tel qu’AES-256, de préférence dans un mode authentifié.
• Premier contact avec une partie avec laquelle vous n’avez jamais échangé de clés : utilisez la cryptographie à clé publique pour l’authentifier et établir une clé de session.
• Preuve d’origine ou d’intégrité : utilisez des signatures numériques.
• Envoi d’un fichier à un destinataire sans partager de secret au préalable : utilisez une conception hybride qui protège une clé de données symétrique avec la clé publique du destinataire.

Notre guide des bonnes pratiques de chiffrement des données explique comment appliquer ces choix aux fichiers et aux courriels.

Quel chiffrement est le plus sûr : à clé publique ou symétrique ?

Aucun n’est plus sûr par nature. Chacun est sûr lorsque l’algorithme est à jour, que la taille de clé correspond à la force requise, que l’implémentation est saine et que les clés sont bien protégées. Les algorithmes à clé publique exigent des clés beaucoup plus grandes que les chiffrements symétriques pour la même force, et ce sont eux qui sont exposés aux attaques quantiques. Les clés symétriques, de leur côté, doivent être partagées ou dérivées de façon sûre. En pratique, la plupart des incidents proviennent de clés volées, d’une génération d’aléa faible, d’une validation de certificats mal configurée ou de failles d’implémentation, plutôt que d’une rupture des mathématiques sous-jacentes.

Quelles menaces pèsent sur les clés publiques et privées ?

• Attaques de l’homme du milieu : un attaquant intercepte une connexion et se fait passer pour l’une des parties. Ces attaques aboutissent lorsque l’authentification est absente ou que les contrôles de certificats sont ignorés, et non par l’extraction de clés privées. La validation des certificats et le recours à des AC de confiance s’en protègent. Pour en savoir plus, lisez notre article sur les attaques de l’homme du milieu.
• Attaques par force brute : essayer toutes les clés possibles est irréalisable avec les tailles de clé actuelles, pour les algorithmes symétriques comme asymétriques. Voir les attaques par force brute.
• Attaques cryptanalytiques et d’implémentation : des failles dans les schémas de bourrage (padding), des canaux auxiliaires, des générateurs de nombres aléatoires prévisibles ou des nonces réutilisés peuvent exposer des clés ou des données en clair, même lorsque l’algorithme est sûr.
• Compromission de clé : le vol d’une clé privée par un logiciel malveillant, un stockage mal configuré, un accès interne ou des contrôles d’accès faibles permet à un attaquant de déchiffrer des données ou d’usurper l’identité du propriétaire.
• Informatique quantique : un ordinateur quantique suffisamment puissant exécutant l’algorithme de Shor pourrait dériver les clés privées à partir des clés publiques pour RSA, l’ECC et Diffie-Hellman. L’algorithme de Grover n’affaiblit les clés symétriques que d’environ la moitié de leur longueur en bits : l’AES-256 reste donc considéré comme sûr. Lisez notre analyse de la menace du calcul quantique sur le chiffrement.

Quelles sont les bonnes pratiques de gestion des clés ?

• Protégez les clés privées dans du matériel. Conservez-les dans un module de sécurité matériel (HSM) ou un service de gestion de clés, et rendez-les non exportables lorsque c’est possible. Consultez notre guide sur la protection des clés par HSM.
• Générez correctement les clés. Utilisez un générateur de nombres aléatoires cryptographiquement sûr et une taille de clé approuvée.
• Renouvelez les clés et faites-les expirer. Remplacez les clés selon un calendrier défini et immédiatement après toute exposition suspectée. Lisez notre article sur les stratégies de rotation des clés de chiffrement.
• Limitez les accès. Appliquez le moindre privilège et la séparation des tâches afin qu’aucun administrateur ne puisse utiliser ou exporter une clé sans être observé. Consultez notre guide sur les contrôles d’accès.
• Sauvegardez et récupérez en toute sécurité. Conservez des sauvegardes protégées pour que les données restent récupérables, et testez la restauration.
• Révoquez et détruisez. Révoquez rapidement les certificats compromis et détruisez les clés en fin de vie.
• Décidez qui détient les clés. Découvrez pourquoi les clés de chiffrement détenues par le client comptent pour la protection de la vie privée et la conformité.

Qu’attendent les référentiels de conformité de la gestion des clés ?

• CMMC et NIST SP 800-171 : exigent des mécanismes cryptographiques pour protéger les informations non classifiées contrôlées en transit (3.13.8) et au repos (3.13.16), la gestion des clés cryptographiques (3.13.10) et une cryptographie validée FIPS (3.13.11). Voir comment AES-256 soutient la conformité CMMC.
• HIPAA : traite le chiffrement comme une mesure de protection « adressable », et des données chiffrées ne peuvent bénéficier de la dérogation (safe harbor) à l’obligation de notification des violations que si les clés restent protégées. Lisez notre guide sur la dérogation HIPAA liée au chiffrement.
• RGPD : l’article 32 cite le chiffrement comme exemple de mesure technique appropriée. Le contrôle des clés influe aussi sur l’exposition aux demandes d’accès émanant de l’étranger.
• PCI DSS : exige une cryptographie robuste et une gestion des clés documentée pour les données de compte stockées.
• FIPS 140-3 : valide le module cryptographique dans son ensemble, y compris la génération et le stockage des clés, et pas seulement l’algorithme. Pour en savoir plus, consultez FIPS et la conformité FIPS sur la plateforme Kiteworks.

Quatre questions aident à évaluer la solidité d’une architecture. Qui détient les clés, et le fournisseur peut-il déchiffrer vos données ? Le module cryptographique est-il validé ? L’échange de clés est-il protégé par des protocoles actuels, avec TLS 1.2 au minimum et TLS 1.3 de préférence ? Le chiffrement est-il appliqué de manière cohérente sur la messagerie, le partage de fichiers, les transferts et les API ?

Situation actuelle : la transition post-quantique

Cette section est révisée et mise à jour séparément du reste de la page. Dernière révision : octobre 2026.

Le NIST a publié ses premiers standards de cryptographie post-quantique en août 2024 : FIPS 203 (ML-KEM) pour l’établissement de clés, FIPS 204 (ML-DSA) pour les signatures numériques et FIPS 205 (SLH-DSA) comme alternative de signature fondée sur les fonctions de hachage. Ils sont conçus pour remplacer RSA, l’ECC et Diffie-Hellman dans les usages où les ordinateurs quantiques représentent une menace.

Les recommandations CNSA 2.0 de la NSA fixent des jalons de transition pour les systèmes de sécurité nationale. Elles prévoient l’usage exclusif d’algorithmes résistants aux attaques quantiques pour la signature des logiciels et des micrologiciels d’ici 2030, et pour les navigateurs web, les serveurs et les services cloud d’ici 2033, la transition plus large s’alignant sur un objectif fédéral fixé à 2035. Les données dont la durée de confidentialité est longue sont exposées à la collecte de type « récolter maintenant, déchiffrer plus tard » : un adversaire enregistre aujourd’hui du trafic chiffré et le déchiffre dès qu’un ordinateur quantique suffisamment puissant existe. L’AES-256 n’a pas besoin d’évoluer.

Une première étape pratique consiste à recenser les endroits où vos systèmes utilisent RSA, l’ECC et Diffie-Hellman, puis à prioriser pour la migration les données à longue durée de vie et les clés de signature.

Comment Kiteworks protège les données sensibles grâce à une gestion rigoureuse des clés

Kiteworks fournit un plan de contrôle pour l’échange sécurisé de données, qui applique le chiffrement de manière cohérente sur la messagerie, le partage de fichiers, le transfert de fichiers géré et les API. La plateforme prend en charge les pratiques ci-dessus de plusieurs façons :

• Double chiffrement. Chaque fichier est chiffré au niveau du fichier, puis de nouveau au niveau du disque, avec des clés distinctes. Pour en savoir plus, consultez notre fiche sur le double chiffrement.
• Clés détenues par le client. Les clients détiennent leurs clés de chiffrement : le personnel de Kiteworks ne peut donc pas déchiffrer les données d’un client.
• Intégration des HSM. Les organisations peuvent stocker et gérer leurs clés en dehors de la plateforme avec des modules de sécurité matériels pris en charge, dont les HSM réseau Thales Luna et AWS Key Management Service.
• Cryptographie validée. Le module cryptographique de Kiteworks est validé FIPS 140-3 dans le cadre du CMVP du NIST, certificat n° 4980.
• Contrôles de sécurité du transport. Les administrateurs choisissent les versions de TLS et les suites de chiffrement acceptées, et gèrent les certificats.
• Chiffrement automatique des courriels. Le Kiteworks Email Protection Gateway peut appliquer le chiffrement aux messages sortants qui contiennent des données sensibles, et la plateforme étend la même protection au chiffrement des courriels, au partage de fichiers sécurisé et au transfert de fichiers géré.

Découvrez le plan de contrôle des données Kiteworks, ou lisez notre présentation de SFTP et des autres canaux qu’il encadre.