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 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. Für Herkos Drive außerdem sein Protokollpaket (packages/herkos_drive_protocol) und die Seite, die seine Links öffnet (herkos.app/f/); siehe seinen eigenen Abschnitt weiter unten.

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, falls Sie einen wählen (standardmäßig keiner; api.nmail.li mit relay.nmail.li auf Wunsch), 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, DPAPI unter Windows, 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 Signierer 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.

Herkos Local Relay: was es schützt und was nicht

Herkos Local Relay bewahrt die Ereignisse Ihrer Apps auf Ihrem Gerät auf, auch die privaten (Entwürfe, private Listen, die Umschläge, die Sie erhalten). Hier steht, was sie schützt und wo die Grenze liegt, Plattform für Plattform. Sicherheitsprobleme des Relays melden Sie genauso wie alle anderen (siehe oben).

Die gesamte Datenbank ist verschlüsselt, einschließlich ihres Journals (SQLite3 Multiple Ciphers, AEGIS-256). Der Schlüssel besteht aus 32 zufälligen Bytes, die auf dem Gerät erzeugt und im sicheren Speicher des Betriebssystems abgelegt werden: im Keystore unter Android, mit DPAPI unter Windows, im Schlüsselbund (libsecret) unter Linux. Er hängt an keinem Passwort von Ihnen, weil das Relay von selbst starten muss. Ohne den Schlüssel startet das Relay nicht und sagt das: Es öffnet oder erstellt nie eine unverschlüsselte Datenbank, und es löscht nie eine, die es nicht öffnen kann.

Auf dem Desktop ist die Grenze von DPAPI und des Schlüsselbunds die jedes Programms: Sie schützen vor anderen Benutzern und vor jemandem, der die Festplatte mitnimmt, nicht vor einem bösartigen Programm, das bereits als Sie läuft. Wenn Sie dieser Fall beunruhigt, schützt Sie die Verschlüsselung der Systemfestplatte (BitLocker, LUKS) und dass Sie keine Programme ausführen, denen Sie nicht vertrauen. Unter einem Linux ohne Schlüsselbund (ohne Secret Service) startet das Relay nicht und erklärt, warum: Es speichert den Schlüssel nie im Klartext.

Wer hineinkommt, auf dem Gerät selbst. Das Relay lauscht nur auf 127.0.0.1, und jede App auf dem Gerät oder eine Webseite im Browser kann diese Adresse erreichen. Deshalb:

• Eine App muss sich koppeln: Sie erscheint auf dem Bildschirm des Relays, und Sie bestätigen sie (mit der PIN oder dem Fingerabdruck, falls Sie sie eingerichtet haben). Jede App kann sich einen beliebigen Namen geben: Bestätigen Sie nur, wenn Sie die Kopplung gerade in dieser App angefordert haben.
• Eine Webseite muss sich immer koppeln, und eine Kopplung gilt nur dort, wo sie erstellt wurde: Die Kopplung einer App des Geräts öffnet einer Webseite nichts, auch wenn diese mit demselben Schlüssel signiert.
• Eine gekoppelte App liest und schreibt nur die Ereignisarten, die Sie ihr erlaubt haben, und löscht nur die, die sie schreiben darf. Wenn Sie ihr den Zugriff entziehen, wird sie sofort getrennt.
• Eine nicht gekoppelte App liest nur Ihre öffentlichen Ereignisse (die ohnehin öffentlich sind) und schreibt nichts, es sei denn, Sie schalten die Einstellung ein, die nicht gekoppelte Apps des Geräts hereinlässt.
• Private Ereignisse gehen nur an den, der mit NIP-42 nachweist, dass er den Schlüssel besitzt, zu dem sie gehören, und ein Umschlag nur an seinen Empfänger.

Was es hier nicht schützt:

• Eine bösartige App auf dem Gerät kann das Relay verlangsamen oder es Arbeitsspeicher verbrauchen lassen. Etwas Privates lesen kann sie dadurch nicht.
• Während das Relay schläft oder nicht läuft, ist sein Port frei. Unter Android schläft es nach 10 Minuten ohne Verbindungen ein; auf dem Desktop ist der Port frei, solange Sie es nicht gestartet haben. Eine andere App könnte dort lauschen und sich als das Relay ausgeben. Die Herkos-Apps werden den Schlüssel des Relays prüfen, bevor sie ihm etwas Privates senden; das tun sie noch nicht, und bis dahin ist das eine echte Grenze.
• Auf dem Desktop können andere Benutzer des Computers sich als nicht gekoppelte App verbinden: Ihre öffentlichen Ereignisse lesen und um eine Kopplung bitten.

Das lokale Netzwerk, wenn Sie es einschalten (standardmäßig ist es aus):

• Nur wss://, mit einem eigenen Zertifikat des Relays; nie unverschlüsseltes ws:// außerhalb des Geräts.
• Nichts vor der Authentifizierung (NIP-42) mit einem Schlüssel auf Ihrer Liste. Eine Verbindung, die das nicht innerhalb von 30 Sekunden tut, wird geschlossen, und das lokale Netzwerk hat ein eigenes Kontingent an Verbindungen: Es belegt nie die der Apps auf dem Gerät.
• Ein Schlüssel auf der Liste liest Ihre öffentlichen Ereignisse und seine eigenen privaten und schreibt nur Ereignisse, die er signiert hat. Wenn Sie ihn von der Liste nehmen, wird er getrennt.
• Das Zertifikat gilt nur für Namen im Heimnetz (localhost, .local, private Adressen): Selbst wenn jemand seinen Schlüssel stehlen würde, könnte er damit auf den Geräten, die es installiert haben, keine Internetdomain signieren.

Was es hier nicht schützt: Wer im selben Netzwerk ist, sieht, dass das Gerät einen offenen Port hat und wie viel Verkehr darüber läuft, wenn auch nicht, was; und wenn das Gerät eine öffentliche Adresse hat (kein Router dazwischen), ist dieser Port aus dem Internet sichtbar, auch wenn er weiterhin einen Schlüssel auf Ihrer Liste verlangt.

Kopien. Die verschlüsselte Kopie hat ein Passwort (scrypt und XChaCha20-Poly1305): Ohne es kann niemand sie öffnen, auch wir nicht. Der JSONL-Export ist nicht verschlüsselt und enthält Ihre privaten Ereignisse im Klartext; die App weist Sie darauf hin.

Die Sperre (eine PIN, dazu Fingerabdruck oder Windows Hello) wird beim Öffnen der App, nach 30 Sekunden Abwesenheit und zum Bestätigen einer Kopplung abgefragt. Sie ist eine Komfortbarriere, wie in Mail: Sie verschlüsselt nichts. Unter Android gibt es mit eingerichteter PIN keine Bildschirmfotos und keine Vorschau unter den zuletzt verwendeten Apps, und seit Android 12 kann sich kein Fenster einer anderen App über das des Relays legen, während Sie es benutzen.

Herkos Drive: was es schützt und was nicht

Herkos Drive speichert Ihre Dateien auf Blossom-Servern und die Liste Ihrer Dateien und Ordner auf Nostr-Relays, beides auf Ihrem Gerät verschlüsselt. Das ist es, was sie schützt, und wo die Grenzen liegen. Alle Einzelheiten stehen in spec-drive.md und im Bedrohungsmodell amenazas-drive.md, in packages/herkos_drive_protocol/; was jedes Relay und jeder Server sieht, steht in der Datenschutzerklärung. Melden Sie Sicherheitsprobleme von Drive auf demselben Weg wie alle anderen (siehe oben).

Was Relays und Server nicht können:

• Ihre Dateien oder deren Namen lesen. Jeder Block einer Datei wird mit AES-256-GCM unter einem eigenen Schlüssel seiner Revision verschlüsselt; Namen, Ordner, Größen, Daten und Schlüssel werden mit XChaCha20-Poly1305 unter dem Schlüssel des Ordners versiegelt, in dem sie liegen. Nichts wird aus dem Inhalt abgeleitet: Dieselbe Datei, zweimal hochgeladen, ergibt verschiedene Blöcke.
• Unbemerkt etwas ändern, austauschen oder verschieben. Jeder Block wird gegen das Manifest geprüft, das im Eintrag seiner Datei versiegelt ist, und jeder Eintrag ist mit dem Volume-Schlüssel signiert und für seinen eigenen Platz versiegelt (Volume, Kennung und Ordner): Ein Relay kann weder einen Eintrag als einen anderen ausgeben noch einen Block als einen anderen.
• Eine alte Version zurückbringen. Die App nimmt nie einen Eintrag an, der älter ist als der, den sie für dieselbe Kennung bereits hat.
• Allein mit dem Volume-Schlüssel als Sie schreiben. Was Ihre Geräte schreiben, trägt die Markierung des Eigentümers, einen HMAC mit einem Schlüssel, den kein Link weitergibt; ein Eintrag oder eine Löschung ohne sie wird nicht angenommen, und die App warnt Sie.

Was es nicht schützt:

• Das Muster Ihres Drive. Relays können Ihre Dateien und Ordner zählen und die Form des Baums sehen sowie wann sich jeder Eintrag ändert; Server sehen ungefähr, wie groß jede Datei ist (Blöcke werden auf 64 KiB aufgefüllt, Einträge auf eine Zweierpotenz). Jedes Relay und jeder Server sieht Ihre IP-Adresse. Nutzen Sie Tor oder Orbot auf Systemebene, wenn Ihnen das wichtig ist.
• Was jemand bereits heruntergeladen hat. Wenn Sie einen Link oder eine Person entfernen, erhält alles, was sie öffnen konnte, sofort neue Schlüssel, sodass sie nicht öffnet, was Sie später hinzufügen; was sie bereits gespeichert hat, lässt sich nicht zurückholen.
• Ein durchgesickerter Link. Ein Link ohne Passwort ist der Schlüssel. Der Browser kann ihn in seinem Verlauf speichern, bevor die Seite ihn aus der Adressleiste entfernt. Für alles Sensible geben Sie dem Link ein Passwort, das auf anderem Weg übermittelt wird, oder teilen Sie mit dem Konto der Person. Ein schwaches Passwort lässt sich mit der Zeit knacken: Wer den Link hat, kann es offline versuchen.
• Die Seite herkos.app/f/ läuft im Browser dessen, der einen Link öffnet. Sie wird mit einer strikten Content-Security-Policy, Subresource Integrity und ohne Code Dritter ausgeliefert, aber wer den Webhoster kontrolliert, könnte eine andere Seite ausliefern. Das ist die Grenze jeder Webseite, die im Browser entschlüsselt.
• Wer den Volume-Schlüssel hatte (Ihren, oder den mit einem Link zu einem Ordner weitergegebenen), kann die Blöcke, die damit hochgeladen wurden, weiterhin löschen, bis sie erneut hochgeladen werden. Sie können den Volume-Schlüssel ändern (Einstellungen → Volume-Schlüssel): Ihre anderen Geräte folgen von selbst.
• Ihr Gerät. Die Dateiliste wird verschlüsselt zwischengespeichert, mit ihrem Schlüssel im sicheren Speicher des Systems; eine Datei, die Sie herunterladen oder öffnen, wird unverschlüsselt dort geschrieben, wo Sie es wählen. Die PIN von Drive ist eine Komfortbarriere, wie in Mail.
• Ein Quantencomputer, später. Die Blöcke und Siegel sind symmetrisch (AES-256, XChaCha20), aber Ihr Locator ist mit NIP-44 auf secp256k1 verschlüsselt: Wer ihn heute aufbewahrt und morgen secp256k1 bricht, könnte das ganze Drive öffnen.

Wie es geprüft wird. Zwei interne Prüfungen anhand des Bedrohungsmodells (2. November 2026) und ihre Korrekturen; Tests dessen, was jedes Ereignis und jeder Block zeigt; Fuzzing jedes Lesers für das, was von außen kommt (Ereignisse, Siegel, Manifeste, Links, Sicherungen). Noch kein externes Audit: Eines ist vor der öffentlichen Beta geplant, und sein Bericht wird vollständig veröffentlicht. Drive befindet sich noch in Entwicklung.

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.