Sécurité et confidentialité

Pas de comptes, pas de connexion

encrypt.click n'a ni comptes utilisateurs, ni connexions, ni profils. Vous n'avez pas besoin de vous inscrire ni de fournir d'informations personnelles pour utiliser les outils.

Outils dans le navigateur

Les outils de confidentialité (AES words, capsule temporelle, stéganographie, chiffrement photo et chiffrement spectral) s'exécutent dans votre navigateur via Web Crypto et d'autres API locales. Leurs entrées ne sont pas envoyées à encrypt.click pour traitement.

Lorsqu'un outil a besoin de données publiques que vous déclenchez (par ex. le hasard Drand pour Time Capsule via notre proxy same-origin), la requête n'inclut pas vos secrets en clair ni vos mots de passe.

Partage chiffré de messages et de fichiers

Encrypt & share exécute AES-GCM dans votre navigateur avant tout envoi. Le mot de passe reste sur votre appareil sauf si vous le copiez ou l'envoyez vous-même.

L'upload automatique préfère le stockage de ciphertext first-party (/upload sur ce site). Ce chemin est limité à environ 90 Mo et à un budget mensuel, et la disponibilité est garantie environ 24 heures. S'il est plein ou indisponible, nous vous demandons d'abord ; si vous acceptez, le navigateur n'envoie que du ciphertext à l'API d'upload d'encrypt.click, qui le relaie côté serveur vers des hôtes temporaires compatibles Send (fichiers jusqu'à 50 Mo). Ces hôtes devraient voir le ciphertext et la sortie serveur - pas un upload direct de clair depuis le navigateur.

Les destinataires ouvrent des liens sur encrypt.click (souvent /u). Le matériel chiffré peut être dans le fragment d'URL (non envoyé à nos serveurs lors d'un chargement normal) ou pointer vers un ciphertext uploadé. Un enrobage PNG optionnel peut cacher le lien dans une image pour un partage hors ligne.

Les envois sont gratuits, c'est pourquoi un usage automatisé ou inhabituellement intensif est contrôlé. Les envois normaux passent sans étape supplémentaire ; lorsqu'un envoi semble automatisé ou qu'un appareil a beaucoup envoyé, le navigateur doit d'abord résoudre une courte épreuve de calcul (proof-of-work). Elle s'exécute sur votre appareil, sans aucun tiers. Chaque épreuve supplémentaire dans l'heure prend deux fois plus de temps, et une épreuve résolue permet à l'appareil de continuer à envoyer pendant une heure, dans les mêmes limites quotidiennes fixes.

Chat, appels, tableau blanc et fichiers chiffrés

Les messages de chat, indicateurs de saisie et la signalisation d'appel sont chiffrés dans le navigateur (AES-GCM) avant d'atteindre le relais. Le relais transmet du ciphertext et ne stocke pas l'historique du chat, sauf pour les salons enregistrés, où il conserve les messages chiffrés (au plus 1000 par salon, dans l’Union européenne) jusqu’à ce qu’un membre supprime le salon ou qu’il reste 90 jours sans visite. Dans les salons sans historique sur le serveur, les messages bénéficient en plus de la confidentialité persistante : la clé d’envoi de chaque membre avance à chaque message et ne parvient aux autres que sous des clés issues de paires de clés éphémères jamais enregistrées, si bien que le trafic enregistré reste fermé même à quelqu’un qui apprend le mot de passe plus tard.

Les appels en direct utilisent WebRTC avec une politique ICE TURN-only afin de ne pas échanger directement les IP des pairs. En plus de DTLS-SRTP, chaque trame audio et vidéo est chiffrée de bout en bout dans le navigateur avec AES-256-GCM (insertable streams sur le modèle de SFrame, vidéo en VP8 ou VP9). La clé média de chaque émetteur est aléatoire, ne circule que dans le canal chiffré et signé du salon, est scellée à nouveau pour chaque destinataire avec une clé éphémère ECDH P-256 et est remplacée dès qu’un participant quitte l’appel. Comme les clés média ne passent jamais par la poignée de main DTLS, enregistrer aujourd’hui le trafic d’un appel puis casser cette poignée de main plus tard, par exemple avec un ordinateur quantique, n’expose pas les médias à qui ne connaît pas le secret du salon. Les navigateurs sans chiffrement des trames ne peuvent pas rejoindre d’appel. Les identifiants TURN viennent d'encrypt.click (/api/turn).

Les pièces jointes du chat sont chiffrées dans le navigateur avant l'envoi, comme dans Encrypt & share. Elles vont dans notre propre stockage et sont supprimées au bout de 24 heures, y compris dans les salons enregistrés. Si notre stockage n'est pas disponible, le fichier chiffré part à la place vers une instance Send publique dans l'UE, où il peut rester jusqu'à 7 jours.

Les nouveaux salons exigent toujours un mot de passe d'au moins 16 caractères qui passe un contrôle de robustesse, et ne peuvent être créés que via le formulaire. Le mot de passe ne fait jamais partie du lien, transmettez-le donc séparément.

Le tableau blanc utilise la même infrastructure temps réel pour les traits et l'état collaboratifs. Traitez l'accès comme pour le chat : mot de passe fort pour tout ce qui est sensible.

Les salons enregistrés utilisent une clé aléatoire portée par le fragment du lien, qui n’atteint jamais le serveur. Dans tous les salons, chaque message est signé dans le navigateur avec une clé propre au salon, afin que les autres membres repèrent un nom qui apparaît sous une autre clé, et le mode des messages est lié à la clé du salon, si bien que le serveur ne peut pas le modifier. Les salons enregistrés ajoutent à chaque message une signature ML-DSA-44 et enchaînent les messages enregistrés de chaque auteur, si bien que les navigateurs remarquent quand le serveur omet, réordonne ou retient des messages.

Raccourcissement des liens

Après le chiffrement, votre navigateur envoie le lien de partage à /api/shorten sur encrypt.click, qui le raccourcit avec notre propre service l.encrypt.click. Aucun raccourcisseur tiers n'est utilisé. Si le raccourcissement échoue, vous obtenez le lien complet.

Le lien court enregistre le lien complet, contenu chiffré compris, mais jamais le mot de passe. Il faut toujours le mot de passe pour l'ouvrir : utilisez la phrase de passe générée ou un autre mot de passe robuste.

Le lien court est créé automatiquement : le contenu chiffré de chaque partage est donc enregistré sur l.encrypt.click, quel que soit le lien que vous partagez au final. Le lien complet porte le contenu dans le fragment de l'URL, que le navigateur du destinataire n'envoie jamais à un serveur.

Cookies et stockage local

Le site dépose un seul cookie fonctionnel, ec-lang, et seulement après que vous avez choisi une langue dans le menu. Il contient uniquement le code de langue à deux lettres, rien d'autre, est conservé un an et ne sert pas au suivi. La première visite sans ce cookie est servie dans la langue de votre navigateur. Votre navigateur peut utiliser le localStorage pour le thème et, là où l'historique du chat est conservé, pour des messages chiffrés et, dans les salons enregistrés, pour savoir jusqu'où l'historique de chaque membre a été vérifié. Le stockage de session peut contenir brièvement le mot de passe d'un salon pendant que vous le rejoignez, et conserve la clé d'un salon reçue dans un lien tant que cet onglet reste ouvert, afin que la clé puisse disparaître de la barre d'adresse. IndexedDB contient la clé de signature que votre navigateur crée pour chaque salon de chat et chaque tableau et, pour les salons enregistrés, la graine de la clé de signature post-quantique, scellée sous une clé dérivée du lien du salon ; les clés privées ne quittent jamais l'appareil.

Cloudflare (hébergement) peut déposer des cookies de sécurité et anti-abus selon le trafic et les réglages du navigateur, selon les politiques de Cloudflare.

Sécurité réseau et transport

• Tout le trafic est servi en HTTPS avec un TLS moderne.
• HTTP Strict Transport Security (HSTS) est activé avec includeSubDomains et preload.
• Content Security Policy (CSP) restreint scripts, styles, polices et connexions ; des hashs de scripts inline remplacent un large unsafe-inline pour les scripts.
• Le framing est désactivé via frame-ancestors 'none' et X-Frame-Options: DENY.
• La vérification compare les fichiers téléchargés au manifeste du même serveur. Elle ne prouve pas l’authenticité du code exécuté dans le navigateur et ne protège pas contre un hébergement compromis.

Infrastructure tierce

Le site est hébergé sur Cloudflare Workers. Le chat et le tableau blanc temps réel sont relayés par des Durable Objects dans le même Worker (PartyServer). Le relais d'appel peut utiliser Cloudflare TURN et/ou d'autres fournisseurs TURN configurés. Des hôtes de ciphertext temporaires (instances compatibles Send) peuvent recevoir des blobs chiffrés si l'upload first-party est indisponible.

encrypt.click ne tient pas sa propre base des entrées des outils. La limitation d'abus des API utilise un hash salé d'IP en mémoire pour une courte fenêtre (environ 60 secondes). Cloudflare peut aussi appliquer des protections bot/challenge selon ses politiques.

Divulgation responsable

Si vous pensez avoir trouvé un problème de sécurité ou de confidentialité sur encrypt.click, écrivez à mail@encrypt.click. Donnez assez de détails pour reproduire et évitez les tests qui pourraient affecter d'autres utilisateurs.

Résumé non juridique

Cette page est un résumé lisible de la façon dont encrypt.click est conçu pour traiter les données. Ce n'est pas un contrat ni des conditions d'utilisation complètes. Aucune garantie de sécurité parfaite n'est donnée ; vous utilisez les outils à vos risques.