Sicherheitsrichtlinie

Herkos verarbeitet private Schlüssel und verschlüsselte Nachrichten. Deshalb nehmen wir Sicherheitsmeldungen ernst und erfahren von einem Problem lieber früh als spät.

Eine Schwachstelle melden

Bitte eröffnen Sie für Sicherheitsprobleme kein öffentliches Issue.

Melden Sie sie vertraulich über GitHubs private Schwachstellenmeldung oder per E-Mail an security@herkos.email.

Hilfreich sind: worin das Problem besteht, wie es sich reproduzieren lässt, welche Plattform und Version Sie getestet haben und was ein Angreifer damit erreichen könnte. Ein Proof of Concept hilft sehr.

Fügen Sie einer Meldung niemals Ihren eigenen nsec, geheimen Schlüssel oder Bunker-Geheimnis bei.

Wir bemühen uns, Meldungen innerhalb weniger Tage zu bestätigen. Da Herkos ein kleines Projekt ist, geben Sie uns bitte angemessen Zeit für eine Korrektur, bevor Sie etwas öffentlich machen. Gern nennen wir Sie im Sicherheitshinweis, sofern Sie es nicht anders wünschen.

Was abgedeckt ist

Die Herkos-Anwendung selbst: Umgang mit und Speicherung von Schlüsseln, Ver- und Entschlüsselung von Nachrichten (einschließlich der NIP-59-Absenderprüfungen und der Bcc-Isolierung in local_packages/nostr_mail), die App-Sperre, die Kommunikation mit Relays und Bridges, der Umgang mit Anhängen sowie die Build- und Release-Pipeline.

Was nicht abgedeckt ist

Das Nostr-Protokoll und seine NIPs selbst — melden Sie solche Probleme upstream.
Relays, Bridges und Blossom-Server, die von Dritten betrieben werden. Herkos bringt Standardwerte mit, betreibt sie aber nicht; melden Sie Probleme deren Betreibern.
Das Ursprungsprojekt Nostr Mail Client, es sei denn, das Problem betrifft speziell Änderungen in Herkos.
Fehlende Härtung, die wir bereits als bekannte Einschränkung dokumentieren (siehe unten).

Bekannte Einschränkungen, offen gesagt

Das sind bewusste Kompromisse im Design, keine Schwachstellen. Wir schreiben sie lieber auf, als dass jemand sie auf die harte Tour entdeckt:

E-Mail an herkömmliche Adressen ist nicht Ende-zu-Ende-verschlüsselt. Nachrichten zwischen Nostr-Nutzern verwenden NIP-17 Gift Wrap und sind E2E-verschlüsselt. Wenn Sie an eine gewöhnliche E-Mail-Adresse schreiben, wandelt eine Bridge die Nachricht um und kann sie lesen.
Die App-Sperre (PIN und Biometrie) ist eine Komfortbarriere, keine Verschlüsselung im Ruhezustand. Sie hält jemanden auf, der ein entsperrtes Gerät in die Hand nimmt; vor einem Angreifer mit vollem Zugriff auf das Gerät oder dessen Speicher schützt sie nicht.
Unter Windows lässt sich eine rein biometrische Authentifizierung nicht erzwingen. Windows Hello erlaubt keine Auswahl der Methode, daher bleibt die System-PIN immer als Ausweichmöglichkeit verfügbar.
Wer seinen Schlüssel verliert, verliert das Konto. Eine Wiederherstellung gibt es nicht, und das ist so gewollt.
Metadaten sind nicht vollständig verborgen. Relays können Verbindungsmuster beobachten, und jedes Relay sieht Ihre IP-Adresse, auch wenn es den Inhalt der Nachrichten nicht lesen kann. Was Herkos (seit dem 30.09.2026) nicht preisgibt, ist, wer wem schreibt, wenn ein Relay eine NIP-42-Authentifizierung verlangt:
Nachschlagen, wohin zugestellt wird. Die Relay- und Blossom-Listen eines Empfängers werden über eine separate Verbindung abgefragt, die Sie nie identifiziert, zuerst bei Relays, die keine Authentifizierung verlangen (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
Profile und der Scheduler. Name und Bild, die für andere Personen angezeigt werden (kind 0), und die Relay-Liste des Scheduler-DVM, wenn Sie eine E-Mail planen oder die Planung abbrechen, werden auf dieselbe Weise abgefragt: zuerst anonym und, falls ein Relay darauf besteht, mit dem unten beschriebenen temporären Schlüssel, nie mit Ihrem (seit dem 01.10.2026; vorher erhielt ein Relay, das Authentifizierung verlangte, Ihren Schlüssel und konnte erkennen, wessen Profil Sie ansahen). Nur Ihr eigenes Profil wird weiterhin als Sie gelesen.
Zustellen. Gift Wraps gehen an die DM-Relays des Empfängers, über dieselbe separate Verbindung. Verlangt eines davon Authentifizierung, antwortet Herkos mit einem eigens dafür erzeugten Schlüssel, der nur im Arbeitsspeicher liegt, nie mit Ihrem; jedes Konto auf dem Gerät hat einen eigenen. Das Relay kann trotzdem sehen, dass dasselbe Gerät (dieselbe IP, derselbe temporäre Schlüssel) während einer Sitzung mehrere Umschläge gesendet hat.
Große E-Mails. Die verschlüsselte Kopie einer E-Mail über 32 KB wird auf Blossom-Server hochgeladen, auch auf die der Empfänger. Nur Ihre eigenen Server (Ihre Blossom-Liste) erhalten den Upload mit Ihrem Schlüssel autorisiert. Jeder andere Server erhält ihn anonym und, falls er auf einer Autorisierung besteht, mit einer, die mit demselben temporären Schlüssel wie oben signiert ist (seit dem 01.10.2026; vorher erhielt jeder Server Ihren Schlüssel). Ein Server, der nur bekannte Schlüssel annimmt, lehnt ihn ab, und die Kopie bleibt auf den anderen Servern.
Ihre eigenen Daten. Beim Synchronisieren Ihres Postfachs, Ihrer Labels, Einstellungen und Entwürfe authentifiziert sich die App, wo ein Relay es verlangt, als das Konto, dem die Daten gehören, auch während eines Kontowechsels. Ihren eigenen Relays verrät das nichts, was sie nicht schon wussten: Die Anfragen nennen Ihren Schlüssel ohnehin. Ihre eigenen Relay- und Blossom-Listen sind öffentlich und werden abgefragt, ohne Sie zu identifizieren, ebenso Relays, die in einem E-Mail-Link genannt werden.
Lesestatus und Ordner sind öffentliche Metadaten (vorerst). Wenn Sie eine E-Mail als gelesen markieren, mit einem Stern versehen, archivieren oder verschieben, wird ein unverschlüsseltes NIP-32-Label-Ereignis veröffentlicht, das mit Ihrem öffentlichen Schlüssel verknüpft ist, einschließlich der Namen eigener Ordner. Ein Absender, der die Kennung einer E-Mail kennt, die er Ihnen geschickt hat, kann erkennen, wann Sie damit etwas getan haben. Die Verschlüsselung dieser Labels ist geplant; bis dahin betrachten Sie Ordnernamen als öffentlich.
Push-Benachrichtigungen und zeitversetztes Senden nutzen Dienste Dritter. Der Push-Server (standardmäßig api.nmail.li) erfährt Ihren öffentlichen Schlüssel, ein Push-Token und wann Sie Post erhalten; der Scheduler-DVM erfährt Ihren öffentlichen Schlüssel und die bereits verschlüsselten Nachrichten, die er veröffentlichen soll. Beides ist optional und in PRIVACY.md dokumentiert. Den Text einer Push-Benachrichtigung wählt der Push-Server, und Herkos vertraut ihm nur, wenn UnifiedPush ihn verschlüsselt zustellt (RFC 8291); eine unverschlüsselte Nutzlast weckt die App nur auf, damit sie die Post selbst abruft.
Die Web-Version bewahrt Ihren Schlüssel im Browser auf, und das ist der schwächste Ort dafür. Die installierten Apps übergeben Ihren geheimen Schlüssel dem sicheren Speicher des Betriebssystems (Android Keystore, Windows-Anmeldeinformationsverwaltung, libsecret, iOS-/macOS-Schlüsselbund). Ein Browser hat nichts davon: Der Schlüssel liegt im Speicher der Website und läuft bei jeder Signatur durch JavaScript, in Reichweite jedes Codes, der in der Seite läuft — einer Browser-Erweiterung mit Zugriff auf alle Seiten, einer XSS-Lücke in der App oder in einer Abhängigkeit, einer manipulierten Auslieferung — und jedes Infostealers, der das Browserprofil kopiert. Außerdem gibt es keinen Moment, in dem Sie den Code einmal prüfen: Eine signierte Binärdatei wird bei der Installation geprüft, eine Webseite dagegen liefert bei jedem Besuch neuen Code. Melden Sie sich in der Web-Version mit einem entfernten Signierdienst an (Bunker nach NIP-46, Amber), damit der Schlüssel den Browser nie erreicht, oder betrachten Sie sie als Wegwerf-Identität und bewahren Sie Ihren echten Schlüssel in einer installierten App auf.
Über eine Bridge geleitete Post ist nur so vertrauenswürdig wie die Bridge. Herkos prüft, dass eine Nachricht, die als über eine Bridge gekommen markiert ist, wirklich von einer Bridge signiert wurde, die Sie konfiguriert haben (oder von einer der Standard-Bridges). Über die herkömmliche From:-Adresse, die die Bridge weiterreicht, kann es nichts prüfen.
Anhänge werden vom Betriebssystem geöffnet. Herkos startet niemals ausführbare Dateien oder Skripte und fragt nach, bevor es einen anderen nicht in der Vorschau darstellbaren Anhang an die Standard-App des Systems übergibt; die App, die die Datei öffnet, liegt aber außerhalb unserer Kontrolle.

Unterstützte Versionen

Sicherheitskorrekturen fließen in die jeweils neueste veröffentlichte Version ein. Angesichts der Größe des Projekts werden ältere Versionen nicht gepflegt — bitte aktualisieren Sie, bevor Sie etwas melden.