Lien Chiffré
Outil de partage de secrets en mode navigateur. Tapez votre secret, obtenez un lien qui chiffre tout côté client avec AES-GCM 256 bits via la Web Crypto API. La clé de chiffrement vit dans le fragment URL (après le #) — conformément à la spécification HTTP, les navigateurs n'incluent jamais les fragments dans les requêtes réseau, donc la clé reste dans le navigateur du destinataire. Aucun compte requis. Le compromis par rapport aux services de type Privnote : cet outil ne maintient pas de base de données de secrets en mode navigateur, nous ne pouvons donc pas appliquer une règle « voir une fois et supprimer » — le lien se déchiffrera autant de fois que quiconque le possède essaiera.
Mode d’emploi
Jusqu’à 4 Ko tiennent dans l’URL.
Second facteur.
Envoyez par canal de confiance.
Pas d’installation, pas de compte.
Envoyez un secret à quelqu’un via un lien chiffré — le chiffrement s’exécute dans le navigateur, sans compte
Options
Comment cela fonctionne (et ce qu’il NE FAIT PAS)
- Chiffrement AES-GCM 256 bits avec clé aléatoire générée dans votre navigateur.
- La clé vit dans le fragment URL (après #). Par spécification W3C, les navigateurs n'envoient pas le fragment dans les requêtes HTTP — la clé n'est vue que par celui qui ouvre le lien.
- Pas de compte, de BDD, de service tiers : quiconque a le lien peut déchiffrer.
- Ce n’est pas un vrai "une fois" — n’importe qui ayant une copie du lien peut déchiffrer autant de fois qu’il veut.
- Pour une sémantique de "une fois" réelle, utilisez un service avec stockage côté serveur.
Ouvrir le secret chiffré
Fonctionnalités
Questions fréquentes
Pouvons-nous lire votre secret sur le serveur ?
En mode navigateur — non. La clé de chiffrement vit après le # dans l’URL, et conformément à la spécification HTTP les navigateurs n'incluent jamais les fragments dans les requêtes réseau, donc la clé n’atteint jamais notre serveur. Le blob chiffré arrive dans le chemin de l’URL (les journaux de notre serveur peuvent donc enregistrer brièvement le texte chiffré via les access logs nginx standard), mais sans la clé, le texte chiffré est en AES-GCM-256 et indéchiffrable.
En quoi cela diffère-t-il de Privnote ?
Privnote stocke le blob chiffré dans une base de données et le supprime après la première vue. En mode navigateur, cet outil n’utilise pas de base de données de secrets — le blob est dans l’URL elle-même, nous ne pouvons donc pas appliquer le « une fois ». Le compromis : la clé de chiffrement n’atteint jamais notre serveur, mais le lien est réutilisable tant que quelqu’un le possède. (Le mode stocké côté serveur de cet outil ressemble davantage à Privnote.)
Pourquoi l’URL est-elle si longue ?
Elle contient tout le secret chiffré et la clé.
Le mot de passe est-il vraiment nécessaire ?
Non — le lien seul est entièrement chiffré.
Combien de temps le lien fonctionne ?
En mode navigateur : tant que quelqu’un possède l’URL. Il n’y a pas d’état de base de données pour imposer une expiration, traitez donc les liens partagés comme durables jusqu’à ce que vous soyez sûr qu’ils ont été supprimés de chaque appareil destinataire. (En mode stocké côté serveur, un TTL explicite s’applique — voir « Expire après ».)
Pouvez-vous faire une version « une fois » réelle ?
Oui — c’est le mode stocké côté serveur. Il utilise un stockage côté serveur avec suppression-après-lecture, ce qui a des hypothèses de confiance différentes (vous devez faire confiance au serveur). Le mode navigateur (texte chiffré dans l’URL) est livré en parallèle comme option sans base de données.
Nous le pouvons — et c'est gratuit ! Envoyez-nous simplement un message rapide avec votre idée. Si vous voulez en discuter en détail, laissez votre e-mail et nous reviendrons vers vous. Vous pouvez rester anonyme.
