Questions fréquentes

Les notes sont d’abord compressées avec zlib, qui fournit un bon taux de compression avec peu de ressources système. Elles sont ensuite chiffrées avec AES-256 en mode CTR. Le chiffrement inclut également HMAC-SHA512 afin d’assurer l’intégrité et l’authenticité du message chiffré. Les clés ne sont pas enregistrées sur le disque et font partie de l’URL. La note chiffrée est ensuite stockée sur le disque. Toutes ces opérations sont effectuées dans la mémoire vive du serveur.

Premièrement, JavaScript ne prend pas en charge de très grands entiers pour le chiffrement. Sa taille maximale est de 53 bits, alors qu’un chiffrement correct demande au moins 128 bits et souvent 256 bits d’entropie. Il faudrait donc utiliser la bibliothèque BigInt.js. C’est possible, mais cela oblige le client à télécharger environ 50 Ko supplémentaires.

Deuxièmement, JavaScript ne dispose pas de bibliothèques cryptographiques intégrées. Il faudrait prendre en charge une bibliothèque tierce. CryptoJS est probablement l’une des plus complètes et matures, mais cela ajoute encore du téléchargement. AES, PBKDF2 et HMAC-SHA512 représentent au minimum 25 Ko supplémentaires.

Enfin, le principal argument contre le chiffrement côté serveur est la nécessité de faire confiance à l’administrateur du service. Le projet est donc libre et open source afin que vous puissiez l’héberger vous-même. Même avec un chiffrement côté client, la plupart des personnes ne vérifient pas que le serveur envoie le bon code JavaScript. Il faut donc toujours faire confiance au fournisseur pour qu’il chiffre la note sans l’altérer ni l’espionner. Tout fournisseur de service demande une forme de confiance, que le chiffrement soit réalisé côté serveur ou côté client.

AES repose sur le chiffrement Rijndael et remplace DES. À ce jour, aucune attaque pratique contre AES n’est connue. AES-256 a été choisi pour ses performances logicielles et sa capacité à résister à la cryptanalyse dans le temps. Il s’agit d’un standard industriel et d’un algorithme de chiffrement ouvert.

Après la création d’une note, une adresse aléatoire et unique vous est fournie. Vous pouvez l’envoyer au destinataire par courriel ou messagerie instantanée. Un QR code est également généré afin de scanner le lien avec un appareil mobile et de le transmettre facilement par message texte ou toute autre application installée sur cet appareil.

Si vous pensez avoir envoyé la note à la mauvaise personne, trop tôt ou avec de mauvaises informations, vous pouvez la détruire simplement en consultant son lien. Une fois la note affichée, elle est détruite et n’est plus disponible.

Oui. Cela n’était pas possible dans la conception d’origine de d-note, mais l’application a depuis été modifiée.

Le chiffrement de la note étant symétrique, toute personne disposant de la clé peut la déchiffrer et consulter son contenu. Il est donc essentiel que le mot de passe privé reste connu uniquement de l’expéditeur et du destinataire.

Une clé sous contrainte peut être communiquée lorsqu’une personne connaissant le mot de passe de la note est forcée de le fournir par un tiers, par exemple les forces de l’ordre. Cette clé est distincte du mot de passe privé et ne déchiffre pas la note. Elle la détruit immédiatement et silencieusement, puis renvoie cinq phrases aléatoires tirées du Zen de Python. Aucune information sur la note n’est alors révélée et, celle-ci ayant été détruite, son contenu ne peut plus être récupéré.

JavaScript calcule la preuve de travail temporaire demandée lors de la création d’une note. Ce calcul limite les soumissions automatisées sans CAPTCHA tiers ni empreinte de navigateur. JavaScript génère également les mots de passe mémorisables, le QR code et certaines interactions de l’interface.

Le serveur fournit un challenge signé, aléatoire, expirant et utilisable une seule fois. Le navigateur cherche localement une solution SHA-256 correspondant à la difficulté demandée, puis le serveur la vérifie rapidement. Des limites de fréquence empêchent également les créations massives et les essais répétés de mots de passe ou de codes de destruction. Cette protection ne collecte pas les caractéristiques de votre navigateur.

Rien n’est sécurisé à 100 % et tout implique des compromis. Malgré les précautions prises pour protéger vos données par défaut, l’administrateur du service peut être négligent ou malveillant. Dans la mesure du possible, vous devriez héberger vous-même cette application. Il est également préférable de ne pas tout transmettre par le même moyen : envoyez, par exemple, l’identifiant par un canal et le mot de passe par un autre. Il devient ainsi plus difficile pour une seule personne de réunir toutes les informations. Enfin, si l’application n’est pas servie en HTTPS, les communications peuvent être interceptées et le contenu de la note lu en clair.

Non. Le code source d’origine aucune porte dérobée et ne sauvegarde pas les clés générées à la création des notes.

En tant qu’hébergeurs, nous ne partageons les notes avec des tiers et aucune porte dérobée n’est ajoutée à cette instance. Une note n’est pas déchiffrable à partir des seuls fichiers présents sur le serveur : la clé secrète aléatoire est générée lors de sa création et transmise uniquement dans son adresse privée. Pour une note protégée, le mot de passe complémentaire est également nécessaire. Le serveur ne peut donc déchiffrer une note stockée sans disposer de ces éléments secrets ; ils ne sont pas enregistrés sur le serveur et uniquement affiché sur votre navigateur à la création de la note.

Comme tout service qui déchiffre une note lors de sa consultation, la protection dépend toutefois aussi de la sécurité du serveur et de la connexion HTTPS. Nous vous recommandons de ne jamais partager l’adresse privée ou le mot de passe avec une personne non autorisée.