Vérifiez votre chiffrement de bout en bout en 3 actions, pour les familles

Famille vérifiant la sécurité du chiffrement

Le chiffrement de bout en bout (E2EE) garantit qu'un message ne peut être lu que par son expéditeur et son destinataire, jamais par le fournisseur du service ni par un intermédiaire sur le réseau, comme le rappelle Cloudflare. Ce que le protocole ne fait pas : masquer les métadonnées (qui parle à qui, quand) ni protéger un appareil déjà compromis. Un standard technique comme RFC9420 de l'IETF encadre désormais ces garanties pour les groupes de messagerie modernes.

En bref:

Le chiffrement de bout en bout ne protège pas contre la surveillance des métadonnées ou un appareil déjà compromis.

La vérification de l'authenticité des clés, via empreintes ou scans QR, reste essentielle pour éviter une interception.

La sauvegarde en clair annule la sécurité, il faut activer des sauvegardes chiffrées réellement protégées.

La mise en place de mécanismes comme le double ratchet et les pre-keys permet une messagerie asynchrone tout en conservant la forward secrecy.

Utiliser le E2EE pour des conversations sensibles limite considérablement le risque d'exposition, mais implique des compromis sur la recherche et la récupération de données.

Table des matières

Comment fonctionne le chiffrement de bout en bout, étape par étape
Confidentialité, intégrité, authenticité : ce que le E2EE vous garantit vraiment
Double ratchet, pre-keys : les mécanismes qui rendent le E2EE utilisable au quotidien
Ce que le chiffrement de bout en bout ne protège pas
Comment vérifier que votre chiffrement fonctionne vraiment
Quand activer le chiffrement de bout en bout, et à quel prix fonctionnel
L'approche de Nara pour chiffrer vos souvenirs partagés
L'essentiel à retenir et vos trois prochaines actions
Pourquoi nous refusons de faire de compromis sur le chiffrement
Conservez vos souvenirs sans jamais sacrifier leur confidentialité
Sources

Comment fonctionne le chiffrement de bout en bout, étape par étape

Vous avez sans doute déjà entendu dire que vos messages sont « chiffrés », sans jamais comprendre ce que cela signifie concrètement. Voici le mécanisme, débarrassé du jargon.

Tout commence sur votre appareil, pas sur un serveur distant. Votre téléphone ou votre ordinateur génère localement une paire de clés : une clé publique, que vous pouvez partager sans risque, et une clé privée, qui ne quitte jamais votre appareil. C'est cette séparation qui fait toute la différence avec un chiffrement classique géré côté serveur.

Le flux se déroule ensuite en quatre temps :

Génération locale des clés : votre application crée la paire clé publique/clé privée directement sur votre terminal, sans intervention du serveur.
Partage de la clé publique : le serveur agit comme un simple annuaire, transmettant votre clé publique au destinataire (et inversement) sans jamais voir vos clés privées.
Création d'une clé de session : votre appareil génère une clé symétrique temporaire, chiffrée à l'aide de la clé publique du destinataire, pour sécuriser l'échange effectif.
Transit et déchiffrement : le message chiffré (le « texte chiffré ») traverse les serveurs sous une forme illisible, puis seul l'appareil du destinataire, muni de sa clé privée, peut le déchiffrer.

Ce mélange n'est pas un hasard. Le chiffrement asymétrique (paire de clés publique/privée) est robuste mais lent à grande échelle ; le chiffrement symétrique (une seule clé partagée) est rapide mais pose un problème de distribution sécurisée. Les systèmes E2EE utilisent donc l'asymétrique uniquement pour échanger une clé de session, puis basculent sur du symétrique pour chiffrer le contenu réel, comme le détaille Proton dans sa description du procédé.

Concrètement, un fournisseur comme celui qui héberge votre messagerie ne détient à aucun moment les clés privées de ses utilisateurs. Même si ses serveurs étaient piratés demain, les messages qui y transitent resteraient du charabia mathématique sans valeur pour l'attaquant. C'est cette absence structurelle de clé côté serveur, et non une simple promesse contractuelle, qui distingue le E2EE d'un chiffrement classique.

Confidentialité, intégrité, authenticité : ce que le E2EE vous garantit vraiment

Un système E2EE bien conçu répond à quatre propriétés formelles, définies notamment dans les travaux académiques sur le sujet. Les comprendre vous évite de confondre marketing sécuritaire et garanties réelles.

Confidentialité : personne d'autre que l'expéditeur et le destinataire ne peut lire le contenu, même en interceptant le trafic réseau.
Intégrité : le message reçu est identique à celui envoyé ; toute altération en cours de route est détectable.
Authenticité : le destinataire peut vérifier que le message provient bien de la personne qu'il croit, et non d'un imposteur.
Forward secrecy (confidentialité persistante) : si une clé de session est compromise, seuls les messages chiffrés avec cette clé précise sont exposés, jamais l'historique complet.

Ces quatre propriétés, ainsi qu'un principe optionnel appelé sécurité post-compromission, constituent la définition formelle qu'un document technique publié sur IACR ePrint en 2024 établit pour qualifier un système de véritablement « bout en bout ».

Conseil de pro : La forward secrecy est la propriété la plus sous-estimée par le grand public. Sans elle, le vol d'une seule clé pourrait exposer des années de conversations passées. Avec elle, chaque message ou presque a sa propre clé jetable, ce qui limite les dégâts d'une fuite à une fenêtre très courte.

Le véritable apport du chiffrement de bout en bout n'est pas de vous demander de faire confiance au fournisseur qui promet de « ne pas lire vos données ». C'est de remplacer cette promesse par une garantie mathématique : tant que les clés privées restent privées, l'accès est structurellement impossible, comme le souligne Proton.

Cette bascule change la nature même de la confiance que vous accordez à un service. Vous ne croyez plus une entreprise sur parole ; vous vérifiez que son architecture rend la lecture de vos données impossible, même si elle le voulait.

Double ratchet, pre-keys : les mécanismes qui rendent le E2EE utilisable au quotidien

La théorie ci-dessus fonctionnerait mal si vous deviez être en ligne en même temps que votre correspondant pour échanger vos clés. Or vous envoyez des messages à des gens hors ligne, depuis plusieurs appareils, tous les jours. C'est là qu'interviennent des mécanismes plus fins, popularisés par les protocoles de messagerie chiffrée modernes.

Le principe des pre-keys (clés préalables) résout le problème de l'asynchronicité. Votre appareil génère un lot de clés temporaires et les dépose sur le serveur à l'avance. Quand un correspondant veut vous écrire alors que vous êtes hors ligne, il récupère l'une de ces pre-keys pour amorcer une session chiffrée immédiatement, sans attendre que vous soyez connecté. L'échange de clés s'appuie généralement sur un protocole Diffie-Hellman, qui permet à deux parties de dériver un secret partagé sans jamais le transmettre en clair.

Le double ratchet (double cliquet) prend ensuite le relais pour la durée de la conversation. Ce mécanisme fait tourner les clés de session à chaque message ou presque, un peu comme un cadenas à combinaison qui changerait de code après chaque usage. Concrètement :

Chaque nouveau message dérive une nouvelle clé à partir de la précédente, dans un sens impossible à inverser.
Une compromission ponctuelle n'expose donc qu'une fenêtre réduite de la conversation, souvent limitée à quelques échanges.
Le mécanisme fonctionne même si les deux parties ne sont pas synchronisées en temps réel, ce qui est indispensable pour la messagerie mobile.

Sur le plan cryptographique, les implémentations actuelles reposent sur des algorithmes désormais considérés comme des standards de fait : X25519 pour l'échange de clés, Ed25519 pour les signatures numériques, et AES ou ChaCha20 pour le chiffrement symétrique du contenu. Le flux typique enchaîne génération des clés, récupération du « bundle » public du destinataire, accord de clé, dérivation de la clé de session, chiffrement, transit, puis déchiffrement, selon la description détaillée de ce processus en sept étapes.

Pour les groupes et la messagerie multi-plateformes, l'IETF a normalisé ces approches avec RFC9420, un standard qui définit comment gérer les clés dans des conversations à plusieurs participants sans sacrifier la forward secrecy. C'est un jalon important : avant ce type de standard, chaque application réinventait sa propre logique de gestion de groupe, avec des niveaux de sécurité très inégaux.

Ce que le chiffrement de bout en bout ne protège pas

Voici où beaucoup d'explications s'arrêtent trop tôt, en laissant croire que le E2EE règle tout. Ce n'est pas le cas, et le savoir vous évite de fausses certitudes.

D'abord, les métadonnées échappent largement au chiffrement de contenu. Un fournisseur peut ignorer ce que vous dites, mais il sait souvent qui vous contactez, à quelle fréquence, depuis quel appareil et parfois la taille approximative des fichiers échangés, comme le rappelle l'entrée Wikipédia sur le sujet. Pour un journaliste ou un lanceur d'alerte, ce type d'information peut être presque aussi sensible que le contenu lui-même.

Ensuite, les sauvegardes non chiffrées représentent l'angle mort le plus fréquent. Vos messages voyagent chiffrés, mais si votre application les stocke ensuite en clair dans une sauvegarde cloud classique, cette protection s'effondre au moment de la copie de sauvegarde. Certains services de messagerie ont d'ailleurs dû ajouter, après coup, des options de sauvegarde chiffrée de bout en bout pour combler cette brèche, comme le note l'EFF dans son analyse approfondie du sujet.

Trois autres limites méritent votre attention :

La compromission de terminal : un logiciel malveillant installé sur votre téléphone peut lire vos messages après déchiffrement, quel que soit le niveau de chiffrement en transit.
Les attaques de l'homme du milieu (MITM) : si vous ne vérifiez jamais l'identité cryptographique de votre correspondant, un attaquant pourrait théoriquement s'interposer en se faisant passer pour lui.
La confusion avec le chiffrement en transit : le protocole TLS/HTTPS protège vos données pendant leur trajet réseau, mais le serveur peut souvent les déchiffrer à son arrivée. Ce n'est pas la même garantie que le E2EE, qui exclut structurellement le serveur de l'équation.

Ces deux derniers points se recoupent d'ailleurs : la protection contre le MITM dépend directement de votre capacité à vérifier les clés, ce qui nous amène à la question pratique suivante.

Comment vérifier que votre chiffrement fonctionne vraiment

La bonne nouvelle : vérifier l'authenticité d'une conversation chiffrée prend rarement plus de deux minutes. La moins bonne : presque personne ne le fait, alors que c'est précisément la méthode la plus fiable pour bloquer une attaque de l'homme du milieu, selon les recommandations de l'EFF.

Comparez les empreintes de clés (fingerprints) ou scannez un code QR avec votre correspondant, idéalement en face à face ou via un canal différent de celui que vous chiffrez (un appel téléphonique, par exemple).
Activez les alertes de changement de clé proposées par la plupart des applications sérieuses : elles vous préviennent si la clé publique de votre correspondant change soudainement, signe possible d'une interception.
Configurez des sauvegardes réellement chiffrées plutôt que la sauvegarde cloud par défaut de votre système d'exploitation, qui échappe souvent au périmètre du E2EE.
Maintenez vos applications à jour et gérez vos mots de passe avec un gestionnaire dédié : la meilleure cryptographie du monde ne protège rien sur un appareil laissé vulnérable.

Conseil de pro : Ne négligez pas l'étape de vérification simplement parce qu'elle paraît « paranoïaque ». Sur une application bien conçue, elle prend moins de temps que de choisir un émoji, et elle transforme une confiance aveugle en certitude vérifiable.

Notre checklist de sécurité pour évaluer une application de partage de photos détaille point par point ces vérifications si vous voulez auditer un service que vous utilisez déjà.

Quand activer le chiffrement de bout en bout, et à quel prix fonctionnel

Le E2EE n'est pas une case à cocher universelle. Il a un sens fort dans certains contextes, et un coût réel en fonctionnalités dans d'autres.

Activez-le sans hésiter pour les conversations sensibles : échanges médicaux, discussions financières, journaux personnels, ou tout contenu familial que vous ne voulez voir circuler nulle part ailleurs. Le RGPD valorise particulièrement ce type d'architecture, puisqu'un fournisseur qui ne détient pas les clés ne peut techniquement pas être contraint de livrer des données qu'il ne peut pas lire.

Le compromis fonctionnel existe pourtant, et il faut le connaître avant de s'étonner :

La recherche pleine texte côté serveur devient impossible : si le fournisseur ne peut pas lire vos données, il ne peut pas non plus les indexer pour une recherche instantanée à grande échelle.
Certaines fonctions d'intelligence artificielle côté serveur (suggestions automatiques, classement par thème) sont plus difficiles à implémenter sans affaiblir le chiffrement.
La récupération de compte se complique : sans clé maîtresse détenue par le fournisseur, perdre son appareil sans sauvegarde adéquate peut signifier perdre l'accès à ses données.

Pour un usage familial, comme un journal de souvenirs partagé entre plusieurs générations, ce compromis penche largement en faveur du chiffrement : vous échangez un peu de confort de recherche contre la certitude que des photos d'enfants ou des récits intimes ne seront jamais exploités par un tiers.

L'approche de Nara pour chiffrer vos souvenirs partagés

Un journal de souvenirs pose un défi particulier au E2EE : il ne s'agit pas d'un message ponctuel, mais d'un contenu enrichi dans le temps par plusieurs personnes, avec des photos et vidéos en qualité originale.

Nara applique le principe du chiffrement client, ce qui signifie que les clés de déchiffrement restent sous le contrôle des personnes qui contribuent au souvenir, jamais sur nos serveurs sous une forme exploitable. Concrètement, cela se traduit par trois choix structurants :

Les médias restent en qualité originale sans passer par une compression ou une analyse côté serveur qui exigerait de les déchiffrer temporairement.
Le partage sélectif permet d'inviter des proches précis à enrichir un souvenir commun sans exposer l'ensemble du journal à des tiers.
L'authentification des contributeurs encadre qui peut rejoindre un souvenir partagé, avec un contrôle d'accès pensé pour les usages familiaux plutôt que professionnels.

Pour des souvenirs numériques, conserver la qualité originale tout en chiffrant côté client réduit fortement le risque qu'un tiers puisse lire ou copier ces contenus sans autorisation, comme le détaille notre article sur l'importance du chiffrement des souvenirs personnels. Notre documentation sur l'authentification et l'accès à un journal privé explique plus en détail comment fonctionnent les invitations sécurisées entre contributeurs.

L'essentiel à retenir et vos trois prochaines actions

Trois garanties, trois limites, une conclusion simple. Le E2EE vous assure la confidentialité, l'intégrité et l'authenticité du contenu échangé, avec une forward secrecy qui limite les dégâts d'une clé compromise. Il ne protège en revanche pas vos métadonnées, ne sécurise pas un appareil déjà infecté, et perd toute valeur si vos sauvegardes restent en clair.

Trois actions à traiter dès aujourd'hui, sans attendre un incident pour vous en soucier :

Vérifiez les paramètres de chiffrement de vos applications de messagerie et de partage de photos actuelles, notamment leur politique de sauvegarde.
Activez une sauvegarde réellement chiffrée plutôt que la sauvegarde par défaut de votre téléphone ou de votre ordinateur.
Comparez les empreintes de clés avec vos correspondants les plus importants, au moins une fois, pour éliminer tout doute sur une éventuelle interception.

Pour approfondir, notre guide comparatif sur la sécurité et le partage de photos en famille détaille les critères à examiner avant de choisir une application, et notre article sur comment éviter la fuite de données de photos familiales recense les scénarios d'incidents les plus courants à connaître.

Pourquoi nous refusons de faire de compromis sur le chiffrement

Chez Nara, le chiffrement de bout en bout n'a jamais été une option marketing ajoutée après coup. Nous l'avons construit dans l'architecture dès le départ, parce qu'un souvenir de famille mérite exactement la même protection qu'un dossier médical, pas moins.

Ce choix a un coût : certaines fonctionnalités pratiques, comme la recherche instantanée sur le contenu de vos photos, demandent plus de travail d'ingénierie pour rester compatibles avec ce niveau de confidentialité. Nous préférons ce chemin plus lent à la facilité d'un chiffrement partiel qui rassurerait sans vraiment protéger.

Nous continuons à documenter publiquement nos choix de sécurité, y compris leurs limites actuelles, parce qu'un engagement de confidentialité qui ne peut pas être expliqué clairement n'en est pas vraiment un.

— Théo Rosen

Conservez vos souvenirs sans jamais sacrifier leur confidentialité

Nara est la solution pour les familles qui veulent partager des souvenirs sans jamais se demander qui peut y accéder. Contrairement à un album photo classique ou à une messagerie généraliste, chaque souvenir ajouté sur Nara reste protégé par un chiffrement client, tout en conservant la qualité originale des photos et vidéos, sans compression destructrice.

Vous pouvez inviter des proches précis à enrichir un souvenir commun, sans jamais exposer l'ensemble de votre journal à des personnes extérieures au cercle que vous avez choisi. Le mode de lecture immersif transforme ensuite ces contributions multiples en un récit cohérent, plutôt qu'en une pile de fichiers dispersés dans une galerie.

Si vous voulez commencer à documenter vos souvenirs familiaux avec cette garantie de confidentialité, créez votre premier journal sur Nara et invitez les proches avec qui vous voulez partager ce récit commun.