Politique de sécurité

Herkos manipule des clés privées et des messages chiffrés : nous prenons donc les signalements de sécurité au sérieux et préférons entendre parler d'un problème tôt plutôt que tard.

Signaler une vulnérabilité

Merci de ne pas ouvrir de ticket public pour un problème de sécurité.

Signalez-le en privé par courriel à security@herkos.email.

Éléments utiles à inclure : la nature du problème, comment le reproduire, la plateforme et la version testées, et ce qu'un attaquant pourrait obtenir. Une preuve de concept aide beaucoup.

N'incluez jamais votre propre nsec, votre clé secrète ou le secret de votre bunker dans un signalement.

Nous nous efforçons d'accuser réception des signalements sous quelques jours. Herkos étant un petit projet, merci de laisser un délai raisonnable pour un correctif avant toute divulgation publique. Nous serons heureux de vous citer dans l'avis de sécurité, sauf si vous préférez le contraire.

Ce qui entre dans le périmètre

L'application Herkos elle-même : la gestion et le stockage des clés, le chiffrement et le déchiffrement des messages (y compris les vérifications d'expéditeur NIP-59 et l'isolation du Cci dans local_packages/nostr_mail), le verrouillage de l'application, la communication avec les relais et les bridges, la gestion des pièces jointes, ainsi que la chaîne de compilation et de publication. Pour Herkos Drive, aussi son paquet de protocole (packages/herkos_drive_protocol) et la page qui ouvre ses liens (herkos.app/f/) ; voir sa propre section plus bas.

Ce qui n'entre pas dans le périmètre

• Le protocole Nostr et ses NIP eux-mêmes — signalez-les en amont.
• Les relais, bridges et serveurs Blossom exploités par des tiers. Herkos est livré avec des réglages par défaut mais ne les exploite pas ; signalez les problèmes à leurs opérateurs.
• Le projet d'origine Nostr Mail Client, sauf si le problème est propre aux modifications apportées dans Herkos.
• L'absence d'un durcissement que nous documentons déjà comme limite connue (voir ci-dessous).

Limites connues, dites franchement

Ce sont des compromis de conception, pas des vulnérabilités. Nous préférons les écrire plutôt que de laisser quelqu'un les découvrir à ses dépens :

• Le courrier vers des adresses classiques n'est pas chiffré de bout en bout. Les messages entre utilisateurs de Nostr utilisent le gift wrap NIP-17 et sont chiffrés de bout en bout. Quand vous écrivez à une adresse électronique ordinaire, un bridge convertit le message et peut le lire.
• Le verrouillage de l'application (code PIN et biométrie) est une barrière de confort, pas un chiffrement au repos. Il arrête quelqu'un qui ramasse un appareil déverrouillé ; il ne protège pas contre un attaquant ayant un accès complet à l'appareil ou à son stockage.
• Sous Windows, l'authentification uniquement biométrique ne peut pas être imposée. Windows Hello ne permet pas de choisir la méthode : le code PIN du système reste donc toujours disponible en solution de repli.
• Perdre sa clé, c'est perdre le compte. Il n'y a pas de récupération, par conception.
• Les métadonnées ne sont pas entièrement cachées. Les relais peuvent observer les schémas de connexion, et chaque relais voit votre adresse IP, même lorsqu'il ne peut pas lire le contenu des messages. Ce que Herkos ne dévoile pas (depuis le 30/09/2026), c'est qui écrit à qui lorsqu'un relais demande une authentification NIP-42 :
• Chercher où livrer. Les listes de relais et de serveurs Blossom d'un destinataire sont demandées sur une connexion séparée qui ne vous identifie jamais, d'abord auprès de relais qui n'exigent pas d'authentification (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
• Les profils et le planificateur. Le nom et l'image affichés pour toute autre personne (kind 0), ainsi que la liste de relais du DVM de planification lorsque vous programmez ou annulez un courriel, sont demandés de la même façon : d'abord anonymement et, si un relais insiste, avec la clé temporaire décrite ci-dessous, jamais avec la vôtre (depuis le 01/10/2026 ; auparavant, un relais qui demandait une authentification obtenait votre clé et pouvait savoir quel profil vous consultiez). Seul votre propre profil est encore lu en votre nom.
• Livrer. Les gift wraps partent vers les relais DM du destinataire, sur cette même connexion séparée. Si l'un d'eux exige une authentification, Herkos répond avec une clé créée à cet effet et conservée uniquement en mémoire, jamais avec la vôtre ; chaque compte de l'appareil a la sienne. Le relais peut tout de même voir que le même appareil (même IP, même clé temporaire) a envoyé plusieurs enveloppes au cours d'une session.
• Les courriels volumineux. La copie chiffrée d'un courriel de plus de 32 Ko est téléversée sur des serveurs Blossom, y compris ceux des destinataires. Seuls vos propres serveurs (votre liste Blossom) reçoivent un téléversement autorisé avec votre clé. Tout autre serveur le reçoit anonymement et, s'il exige une autorisation, une autorisation signée avec la même clé temporaire que ci-dessus (depuis le 01/10/2026 ; auparavant, chaque serveur obtenait votre clé). Un serveur qui n'accepte que des clés connues le refuse, et la copie reste sur les autres serveurs.
• Vos propres données. La synchronisation de votre boîte aux lettres, de vos étiquettes, de vos réglages et de vos brouillons s'authentifie, lorsqu'un relais le demande, en tant que le compte auquel appartiennent les données, même pendant un changement de compte. Sur vos propres relais, cela ne leur apprend rien qu'ils ne sachent déjà : les requêtes nomment de toute façon votre clé. Vos propres listes de relais et de serveurs Blossom sont publiques et sont demandées sans vous identifier, tout comme les relais cités dans un lien de courriel.
• L'état de lecture et les dossiers sont des métadonnées publiques (pour l'instant). Marquer un courriel comme lu, favori, archivé ou déplacé publie un événement d'étiquette NIP-32 non chiffré, lié à votre clé publique, y compris le nom des dossiers personnalisés. Un expéditeur qui connaît l'identifiant d'un courriel qu'il vous a envoyé peut savoir quand vous avez agi dessus. Le chiffrement de ces étiquettes est prévu ; en attendant, considérez les noms de dossiers comme publics.
• Les notifications push et l'envoi programmé utilisent des services tiers. Le serveur push, si vous en choisissez un (aucun par défaut ; api.nmail.li avec relay.nmail.li sur demande), apprend votre clé publique, un jeton push et quand vous recevez du courrier ; le DVM de planification apprend votre clé publique et les messages déjà chiffrés qu'il doit publier. Les deux sont optionnels et documentés dans PRIVACY.md. Le texte d'une notification push est choisi par le serveur push, et Herkos ne s'y fie que lorsque UnifiedPush le livre chiffré (RFC 8291) ; une charge utile non chiffrée ne fait que réveiller l'application pour qu'elle aille chercher le courrier elle-même.
• La version web garde votre clé dans le navigateur, l'endroit le plus faible pour elle. Les applications installées confient votre clé secrète au stockage sécurisé du système d'exploitation (Android Keystore, DPAPI sous Windows, libsecret, trousseau iOS/macOS). Un navigateur n'a rien de tout cela : la clé réside dans le stockage de l'origine et transite par JavaScript à chaque signature, à la portée de tout code qui s'exécute dans la page — une extension de navigateur ayant accès à tous les sites, une faille XSS dans l'application ou dans une dépendance, un déploiement altéré — et de tout logiciel voleur d'informations qui copie le profil du navigateur. Il n'y a pas non plus de moment où vous vérifiez le code une fois pour toutes : un binaire signé est vérifié à l'installation, alors qu'une page web livre du code neuf à chaque visite. Connectez-vous à la version web avec un signataire distant (bunker NIP-46, Amber), pour que la clé n'atteigne jamais le navigateur, ou traitez-la comme une identité jetable et gardez votre vraie clé dans une application installée.
• Le courrier passé par un bridge n'est pas plus fiable que le bridge. Herkos vérifie qu'un message présenté comme venant d'un bridge a bien été signé par un bridge que vous avez configuré (ou l'un de ceux par défaut). Il ne peut rien vérifier de l'adresse From: classique que le bridge relaie.
• Les pièces jointes sont ouvertes par le système d'exploitation. Herkos ne lance jamais de fichiers exécutables ou de scripts, et demande confirmation avant de confier toute autre pièce jointe sans aperçu à l'application par défaut du système, mais l'application qui ouvre le fichier échappe à notre contrôle.

Herkos Local Relay : ce qu'il protège et ce qu'il ne protège pas

Herkos Local Relay garde sur votre appareil les événements de vos applications, y compris les privés (brouillons, listes privées, les enveloppes que vous recevez). Voici ce qui les protège et où se trouve la limite, plateforme par plateforme. Les problèmes de sécurité du relais se signalent comme les autres (ci-dessus).

La base de données est entièrement chiffrée, journal compris (SQLite3 Multiple Ciphers, AEGIS-256). La clé est faite de 32 octets aléatoires créés sur l'appareil et conservés dans le stockage sécurisé du système : le Keystore sous Android, DPAPI sous Windows, le trousseau (libsecret) sous Linux. Elle ne dépend d'aucun mot de passe de votre part, car le relais doit démarrer tout seul. Sans la clé, le relais ne démarre pas et le dit : il n'ouvre ni ne crée jamais une base non chiffrée, et ne supprime jamais celle qu'il ne peut pas ouvrir.

Sur ordinateur, la limite de DPAPI et du trousseau est celle de tout programme : ils protègent contre les autres utilisateurs et contre qui emporte le disque, pas contre un programme malveillant qui tourne déjà sous votre utilisateur. Si ce cas vous inquiète, ce qui vous protège, c'est le chiffrement du disque système (BitLocker, LUKS) et le fait de ne pas lancer de programmes auxquels vous ne faites pas confiance. Sous Linux sans trousseau (sans Secret Service), le relais ne démarre pas et explique pourquoi : il ne garde jamais la clé en clair.

Qui entre, sur l'appareil lui-même. Le relais n'écoute que sur 127.0.0.1, et n'importe quelle application de l'appareil, ou une page web du navigateur, peut atteindre cette adresse. Donc :

• Une application doit être appairée : elle apparaît sur l'écran du relais et vous l'approuvez (avec le code PIN ou l'empreinte, si vous les avez définis). N'importe quelle application peut se donner n'importe quel nom : n'approuvez que si vous venez de le demander depuis cette application.
• Une page web est toujours appairée, et un appairage ne vaut que depuis l'endroit où il a été fait : celui d'une application de l'appareil n'ouvre rien à une page web, même si elle signe avec la même clé.
• Une application appairée ne lit et n'écrit que les types d'événements que vous lui avez accordés, et ne supprime que ceux qu'elle peut écrire. La révoquer la déconnecte aussitôt.
• Une application non appairée ne lit que vos événements publics (qui sont publics de toute façon) et n'écrit rien, sauf si vous activez le réglage qui laisse entrer les applications non appairées de l'appareil.
• Les événements privés ne sont remis qu'à qui prouve avec NIP-42 qu'il détient la clé à laquelle ils appartiennent, et une enveloppe, qu'à son destinataire.

Ce qu'il ne protège pas, ici :

• Une application malveillante de l'appareil peut ralentir le relais ou lui faire consommer de la mémoire. Elle ne peut rien lire de privé pour autant.
• Pendant que le relais est en veille ou ne fonctionne pas, son port est libre. Sous Android, il se met en veille après 10 minutes sans connexion ; sur ordinateur, le port est libre tant que vous ne l'avez pas lancé. Une autre application pourrait y écouter et se faire passer pour lui. Les applications Herkos vérifieront la clé du relais avant de lui envoyer quoi que ce soit de privé ; elles ne le font pas encore, et d'ici là, c'est une vraie limite.
• Sur ordinateur, les autres utilisateurs de la machine peuvent se connecter comme une application non appairée : lire vos événements publics et demander un appairage.

Le réseau local, si vous l'activez (il est désactivé par défaut) :

• wss:// uniquement, avec un certificat propre au relais ; jamais ws:// non chiffré en dehors de l'appareil.
• Rien avant de s'authentifier (NIP-42) avec une clé de votre liste. Une connexion qui ne le fait pas dans les 30 secondes est fermée, et le réseau local a son propre nombre de connexions : il ne prend jamais celles des applications de l'appareil.
• Une clé de la liste lit vos événements publics et ses propres événements privés, et n'écrit que des événements qu'elle a signés. La retirer de la liste la déconnecte.
• Le certificat n'est valable que pour des noms de la maison (localhost, .local, adresses privées) : même si quelqu'un volait sa clé, elle ne lui servirait pas à signer un domaine Internet sur les appareils qui l'ont installé.

Ce qu'il ne protège pas, ici : quiconque se trouve sur le même réseau voit que l'appareil a un port ouvert et combien de trafic y passe, mais pas son contenu ; et si l'appareil a une adresse publique (sans routeur entre les deux), ce port est visible depuis Internet, même s'il demande toujours une clé de votre liste.

Copies. La copie chiffrée a un mot de passe (scrypt et XChaCha20-Poly1305) : sans lui, personne ne peut l'ouvrir, pas même nous. L'export JSONL n'est pas chiffré et contient vos événements privés en clair ; l'application vous prévient.

Le verrouillage (code PIN, et empreinte ou Windows Hello) est demandé à l'ouverture de l'application, après 30 secondes d'absence, et pour approuver un appairage. C'est une barrière de confort, comme dans Mail : il ne chiffre rien. Sous Android, avec un code PIN, il n'y a ni captures d'écran ni miniature dans les applications récentes, et depuis Android 12, aucune fenêtre d'une autre application ne peut se placer par-dessus celle du relais pendant que vous l'utilisez.

Herkos Drive : ce qu'il protège et ce qu'il ne protège pas

Herkos Drive garde vos fichiers sur des serveurs Blossom et la liste de vos fichiers et dossiers sur des relais Nostr, les deux chiffrés sur votre appareil. Voici ce qui les protège et où sont les limites. Le détail complet se trouve dans spec-drive.md et le modèle de menaces amenazas-drive.md, dans packages/herkos_drive_protocol/ ; ce que voit chaque relais et chaque serveur se trouve dans la politique de confidentialité. Signalez les problèmes de sécurité de Drive de la même façon que tous les autres (voir plus haut).

Ce que les relais et les serveurs ne peuvent pas faire :

• Lire vos fichiers ou leurs noms. Chaque bloc d'un fichier est chiffré avec AES-256-GCM sous une clé propre à sa révision ; les noms, les dossiers, les tailles, les dates et les clés sont scellés avec XChaCha20-Poly1305 sous la clé du dossier où ils se trouvent. Rien n'est dérivé du contenu : le même fichier téléversé deux fois donne des blocs différents.
• Changer, échanger ou déplacer quoi que ce soit sans que cela se voie. Chaque bloc est vérifié par rapport au manifeste scellé dans l'entrée de son fichier, et chaque entrée est signée par la clé du volume et scellée pour sa propre place (volume, identifiant et dossier) : un relais ne peut pas faire passer une entrée pour une autre, ni un bloc pour un autre.
• Ramener une ancienne version. L'application n'accepte jamais une entrée plus ancienne que celle qu'elle a déjà pour le même identifiant.
• Écrire en votre nom avec la seule clé du volume. Ce qu'écrivent vos appareils porte la marque du propriétaire, un HMAC avec une clé qu'aucun lien ne donne ; une entrée ou une suppression sans elle n'est pas acceptée, et l'application vous prévient.

Ce qu'il ne protège pas :

• Le schéma de votre Drive. Les relais peuvent compter vos fichiers et dossiers, voir la forme de l'arborescence et quand chaque entrée change ; les serveurs voient à peu près la taille de chaque fichier (les blocs sont complétés jusqu'à 64 KiB, les entrées jusqu'à une puissance de deux). Chaque relais et chaque serveur voit votre adresse IP. Utilisez Tor ou Orbot au niveau du système si cela compte pour vous.
• Ce que quelqu'un a déjà téléchargé. Supprimer un lien, ou une personne, donne aussitôt de nouvelles clés à ce qu'elle pouvait ouvrir, si bien qu'elle n'ouvre pas ce que vous ajoutez ensuite ; cela ne peut pas reprendre ce qu'elle a déjà enregistré.
• Un lien qui a fuité. Un lien sans mot de passe est la clé. Le navigateur peut le garder dans son historique avant que la page ne le retire de la barre d'adresse. Pour tout ce qui est sensible, donnez au lien un mot de passe, envoyé par un autre moyen, ou partagez avec le compte de la personne. Un mot de passe faible peut être cassé avec le temps : qui a le lien peut essayer hors ligne.
• La page herkos.app/f/ s'exécute dans le navigateur de qui ouvre un lien. Elle est servie avec une Content-Security-Policy stricte, Subresource Integrity et aucun code tiers, mais qui contrôle l'hébergeur web pourrait servir une page différente. C'est la limite de toute page web qui déchiffre dans le navigateur.
• Qui a eu la clé du volume (la vôtre, ou celle donnée avec un lien vers un dossier) peut encore supprimer les blocs qui ont été téléversés avec elle, jusqu'à ce qu'ils soient téléversés de nouveau. Vous pouvez changer la clé du volume (Paramètres → Clé du volume) : vos autres appareils suivent d'eux-mêmes.
• Votre appareil. La liste des fichiers est mise en cache chiffrée, avec sa clé dans le stockage sécurisé du système ; un fichier que vous téléchargez ou ouvrez est écrit en clair là où vous le choisissez. Le code PIN de Drive est une barrière de confort, comme dans Mail.
• Un ordinateur quantique, plus tard. Les blocs et les sceaux sont symétriques (AES-256, XChaCha20), mais votre localisateur est chiffré avec NIP-44 sur secp256k1 : quelqu'un qui le garde aujourd'hui et casse secp256k1 demain pourrait ouvrir tout le Drive.

Comment c'est vérifié. Deux revues internes au regard du modèle de menaces (2 novembre 2026) et leurs corrections ; des tests de ce que montre chaque événement et chaque bloc ; du fuzzing de chaque lecteur de ce qui vient de l'extérieur (événements, sceaux, manifestes, liens, sauvegardes). Pas encore d'audit externe : un audit est prévu avant la bêta publique, et son rapport sera publié en entier. Drive est encore en développement.

Versions prises en charge

Les correctifs de sécurité sont appliqués à la dernière version publiée. Vu la taille du projet, les versions plus anciennes ne sont pas maintenues — merci de mettre à jour avant de signaler un problème.