Säkerhetspolicy

Herkos hanterar privata nycklar och krypterade meddelanden, så vi tar säkerhetsrapporter på allvar och hör hellre om ett problem tidigt än sent.

Rapportera en sårbarhet

Öppna inte ett offentligt ärende (issue) för säkerhetsproblem.

Rapportera det privat via e-post till security@herkos.email.

Bra att ta med: vad problemet är, hur det kan återskapas, vilken plattform och version du testade och vad en angripare skulle kunna uppnå. Ett konceptbevis (proof of concept) hjälper mycket.

Ta aldrig med din egen nsec, hemliga nyckel eller bunker-hemlighet i en rapport.

Vi försöker bekräfta rapporter inom några dagar. Eftersom Herkos är ett litet projekt ber vi dig ge oss rimlig tid för en åtgärd innan du offentliggör något. Vi nämner dig gärna i säkerhetsmeddelandet, om du inte föredrar något annat.

Vad som omfattas

Själva Herkos-appen: hantering och lagring av nycklar, kryptering och dekryptering av meddelanden (inklusive NIP-59-kontrollerna av avsändaren och isoleringen av Bcc i local_packages/nostr_mail), applåset, kommunikationen med reläer och bryggor, hanteringen av bilagor samt bygg- och releaseprocessen. För Herkos Drive även dess protokollpaket (packages/herkos_drive_protocol) och sidan som öppnar dess länkar (herkos.app/f/); se dess eget avsnitt nedan.

Vad som inte omfattas

• Nostr-protokollet och dess NIP:ar i sig — rapportera sådant uppströms.
• Reläer, bryggor och Blossom-servrar som drivs av tredje part. Herkos levereras med standardinställningar men driver dem inte; rapportera problem till deras operatörer.
• Uppströmsprojektet Nostr Mail Client, om inte problemet gäller ändringar som gjorts i Herkos.
• Saknad härdning som vi redan dokumenterar som en känd begränsning (se nedan).

Kända begränsningar, rakt på sak

Det här är avvägningar i designen, inte sårbarheter. Vi skriver hellre ut dem än låter någon upptäcka dem den hårda vägen:

• Post till traditionella adresser är inte end-to-end-krypterad. Meddelanden mellan Nostr-användare använder NIP-17 gift wrap och är E2E-krypterade. När du skriver till en vanlig e-postadress konverterar en brygga meddelandet och kan läsa det.
• Applåset (PIN-kod och biometri) är en bekvämlighetsspärr, inte kryptering av lagrade data. Det stoppar någon som plockar upp en olåst enhet; det skyddar inte mot en angripare med full åtkomst till enheten eller dess lagring.
• På Windows går det inte att kräva enbart biometrisk autentisering. Windows Hello låter inte appen välja metod, så systemets PIN-kod finns alltid kvar som reserv.
• Förlorar du din nyckel förlorar du kontot. Det finns ingen återställning, och det är avsiktligt.
• Metadata döljs inte helt. Reläer kan observera anslutningsmönster, och varje relä ser din IP-adress, även när det inte kan läsa innehållet i meddelandena. Det Herkos inte avslöjar (sedan 2026-09-30) är vem som skriver till vem när ett relä begär NIP-42-autentisering:
• Ta reda på vart posten ska levereras. En mottagares relä- och Blossom-listor hämtas över en separat anslutning som aldrig identifierar dig, i första hand från reläer som inte kräver autentisering (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
• Profiler och schemaläggaren. Namnet och bilden som visas för alla andra (kind 0), och schemaläggnings-DVM:ens relälista när du schemalägger eller avbryter ett mejl, hämtas på samma sätt: anonymt i första hand och, om ett relä insisterar, med den tillfälliga nyckel som beskrivs nedan, aldrig med din (sedan 2026-10-01; tidigare fick ett relä som begärde autentisering din nyckel och kunde se vems profil du tittade på). Bara din egen profil läses fortfarande som du.
• Leverans. Gift wraps skickas till mottagarens DM-reläer, över samma separata anslutning. Om något av dem kräver autentisering svarar Herkos med en nyckel som skapats för ändamålet och bara finns i minnet, aldrig med din; varje konto på enheten har sin egen. Reläet kan fortfarande se att samma enhet (samma IP-adress, samma tillfälliga nyckel) skickade flera kuvert under en session.
• Stora mejl. Den krypterade kopian av ett mejl på över 32 KB laddas upp till Blossom-servrar, även mottagarnas. Bara dina egna servrar (din Blossom-lista) får uppladdningen auktoriserad med din nyckel. Alla andra servrar får den anonymt och, om de insisterar på en auktorisering, en som signerats med samma tillfälliga nyckel som ovan (sedan 2026-10-01; tidigare fick varje server din nyckel). En server som bara godtar kända nycklar avvisar den, och kopian finns kvar på de andra servrarna.
• Dina egna data. Synkronisering av din brevlåda, dina etiketter, inställningar och utkast autentiseras, där ett relä begär det, som det konto som uppgifterna tillhör, även när du byter konto. På dina egna reläer avslöjar det inget de inte redan visste: förfrågningarna namnger ändå din nyckel. Dina egna relä- och Blossom-listor är offentliga och hämtas utan att identifiera dig, och detsamma gäller reläer som anges i en e-postlänk.
• Lässtatus och mappar är offentliga metadata (tills vidare). När du markerar ett mejl som läst, stjärnmärker, arkiverar eller flyttar det publiceras en okrypterad NIP-32-etiketthändelse kopplad till din offentliga nyckel, inklusive namnen på egna mappar. En avsändare som känner till id:t för ett mejl hen skickade till dig kan se när du gjorde något med det. Kryptering av dessa etiketter är planerad; tills dess bör du se mappnamn som offentliga.
• Push-aviseringar och schemalagda utskick använder tjänster från tredje part. Push-servern, om du väljer en (ingen som standard; api.nmail.li med relay.nmail.li på begäran), får veta din offentliga nyckel, en push-token och när du tar emot post; schemaläggnings-DVM:en får veta din offentliga nyckel och de redan krypterade meddelanden den ska publicera. Båda är frivilliga och dokumenterade i PRIVACY.md. Texten i en push-avisering väljs av push-servern, och Herkos litar bara på den när UnifiedPush levererar den krypterad (RFC 8291); en okrypterad nyttolast väcker bara appen så att den själv hämtar posten.
• Webbversionen förvarar din nyckel i webbläsaren, som är det svagaste stället för den. De installerade apparna lämnar din hemliga nyckel till operativsystemets säkra lagring (Android Keystore, DPAPI på Windows, libsecret, iOS/macOS-nyckelringen). En webbläsare har inget av det: nyckeln ligger i ursprungets lagring och passerar genom JavaScript vid varje signatur, inom räckhåll för all kod som körs på sidan — ett webbläsartillägg med åtkomst till alla webbplatser, en XSS-bugg i appen eller i ett beroende, en manipulerad driftsättning — och för varje informationsstöldprogram (infostealer) som kopierar webbläsarprofilen. Det finns inte heller något tillfälle då du verifierar koden en gång för alla: en signerad binärfil kontrolleras vid installationen, medan en webbsida levererar ny kod vid varje besök. Logga in i webbversionen med en fjärrsignerare (NIP-46-bunker, Amber), så att nyckeln aldrig når webbläsaren, eller behandla den som en engångsidentitet och behåll din riktiga nyckel i en installerad app.
• Post via brygga är bara så pålitlig som bryggan. Herkos verifierar att ett meddelande som är märkt som att det kommer via en brygga verkligen har signerats av en brygga du har konfigurerat (eller en av standardbryggorna). Appen kan inte verifiera något om den traditionella From:-adress som bryggan vidarebefordrar.
• Bilagor öppnas av operativsystemet. Herkos startar aldrig körbara filer eller skriptfiler och frågar innan någon annan bilaga som inte kan förhandsgranskas lämnas till systemets standardapp, men appen som öppnar filen ligger utanför vår kontroll.

Herkos Local Relay: vad det skyddar och vad det inte skyddar

Herkos Local Relay förvarar dina appars händelser på din enhet, även de privata (utkast, privata listor, de kuvert du tar emot). Här är vad som skyddar dem och var gränsen går, plattform för plattform. Säkerhetsproblem i reläet rapporterar du på samma sätt som alla andra (ovan).

Hela databasen är krypterad, journalen inräknad (SQLite3 Multiple Ciphers, AEGIS-256). Nyckeln är 32 slumpmässiga byte som skapas på enheten och förvaras i systemets säkra lagring: Keystore på Android, DPAPI på Windows, nyckelringen (libsecret) på Linux. Den är inte skyddad av något lösenord från dig, eftersom reläet måste kunna starta av sig självt. Utan nyckeln startar reläet inte och säger det: det öppnar eller skapar aldrig en okrypterad databas, och det raderar aldrig en som det inte kan öppna.

På en dator är gränsen för DPAPI och nyckelringen densamma som för vilket program som helst: de skyddar mot andra användare och mot den som tar med sig disken, inte mot ett skadligt program som redan körs som du. Om det fallet oroar dig är det som skyddar dig att kryptera systemdisken (BitLocker, LUKS) och att inte köra program du inte litar på. På en Linux utan nyckelring (utan Secret Service) startar reläet inte och förklarar varför: det förvarar aldrig nyckeln i klartext.

Vem som kommer in, på själva enheten. Reläet lyssnar bara på 127.0.0.1, och vilken app som helst på enheten, eller en webbsida i webbläsaren, kan nå den adressen. Därför:

• En app måste parkopplas: den visas på reläets skärm och du godkänner den (med PIN-koden eller fingeravtrycket, om du har ställt in dem). Vilken app som helst kan ge sig själv vilket namn som helst: godkänn bara om du nyss bad om det från just den appen.
• En webbsida måste alltid parkopplas, och en parkoppling gäller bara där den gjordes: en parkoppling för en app på enheten öppnar ingenting för en webbsida, inte ens för en som signerar med samma nyckel.
• En parkopplad app läser och skriver bara de typer av händelser du har gett den, och raderar bara dem den får skriva. Att återkalla den kopplar bort den direkt.
• En app som inte är parkopplad läser bara dina offentliga händelser (som ändå är offentliga) och skriver ingenting, om du inte slår på inställningen som släpper in enhetens appar som inte är parkopplade.
• Privata händelser lämnas bara ut till den som med NIP-42 bevisar att den har nyckeln de hör till, och ett kuvert bara till sin mottagare.

Vad det inte skyddar, här:

• En skadlig app på enheten kan göra reläet långsammare eller få det att använda minne. Den kan inte läsa något privat på det sättet.
• Medan reläet sover eller inte körs är dess port ledig. På Android somnar det efter 10 minuter utan anslutningar; på en dator är porten ledig så länge du inte har startat det. En annan app skulle kunna lyssna där och utge sig för att vara reläet. Herkos-apparna kommer att kontrollera reläets nyckel innan de skickar något privat till det; det gör de inte än, och tills dess är detta en verklig gräns.
• På en dator kan datorns andra användare ansluta som en app som inte är parkopplad: läsa dina offentliga händelser och be om att få parkopplas.

Det lokala nätverket, om du slår på det (det är avstängt som standard):

• Bara wss://, med reläets eget certifikat; aldrig okrypterad ws:// utanför enheten.
• Ingenting före autentisering (NIP-42) med en nyckel på din lista. En anslutning som inte gör det inom 30 sekunder stängs, och det lokala nätverket har ett eget antal anslutningar: det tar aldrig dem som enhetens appar har.
• En nyckel på listan läser dina offentliga händelser och sina egna privata, och skriver bara händelser som den har signerat. Att ta bort den från listan kopplar bort den.
• Certifikatet gäller bara för namn i hemmet (localhost, .local, privata adresser): även om någon stal dess nyckel skulle den inte gå att använda för att signera en internetdomän på de enheter som har installerat certifikatet.

Vad det inte skyddar, här: den som är på samma nätverk ser att enheten har en öppen port och hur mycket trafik som går genom den, men inte vad; och om enheten har en offentlig adress (ingen router emellan) syns porten från internet, även om den fortfarande kräver en nyckel på din lista.

Kopior. Den krypterade kopian har ett lösenord (scrypt och XChaCha20-Poly1305): utan det kan ingen öppna den, inte heller vi. JSONL-exporten är inte krypterad och innehåller dina privata händelser i klartext; appen varnar dig för det.

Låset (en PIN-kod, plus fingeravtryck eller Windows Hello) begärs när appen öppnas, efter 30 sekunder borta och för att godkänna en parkoppling. Det är en bekvämlighetsspärr, som i Mail: det krypterar ingenting. På Android finns det med PIN-kod inga skärmdumpar och ingen miniatyr bland de senaste apparna, och sedan Android 12 kan inget fönster från en annan app läggas ovanpå reläets medan du använder det.

Herkos Drive: vad det skyddar och vad det inte skyddar

Herkos Drive förvarar dina filer på Blossom-servrar och listan över dina filer och mappar på Nostr-reläer, båda krypterade på din enhet. Det här är vad som skyddar dem och var gränserna går. Alla detaljer finns i spec-drive.md och i hotmodellen amenazas-drive.md, i packages/herkos_drive_protocol/; vad varje relä och server ser står i integritetspolicyn. Rapportera säkerhetsproblem i Drive på samma sätt som alla andra (ovan).

Vad reläer och servrar inte kan göra:

• Läsa dina filer eller deras namn. Varje block i en fil krypteras med AES-256-GCM under en nyckel som hör till just dess revision; namn, mappar, storlekar, datum och nycklar förseglas med XChaCha20-Poly1305 under nyckeln för mappen de ligger i. Ingenting härleds från innehållet: samma fil uppladdad två gånger ger olika block.
• Ändra, byta ut eller flytta något obemärkt. Varje block kontrolleras mot manifestet som är förseglat i filens post, och varje post signeras av volymnyckeln och förseglas för sin egen plats (volym, identifierare och mapp): ett relä kan inte utge en post för en annan, eller ett block för ett annat.
• Ta tillbaka en gammal version. Appen godtar aldrig en post som är äldre än den den redan har för samma identifierare.
• Skriva som du med bara volymnyckeln. Det dina enheter skriver bär ägarens märke, en HMAC med en nyckel som ingen länk ger; en post eller en radering utan det godtas inte, och appen varnar dig.

Vad det inte skyddar:

• Mönstret i din Drive. Reläer kan räkna dina filer och mappar, se trädets form och när varje post ändras; servrar ser ungefär hur stor varje fil är (block fylls ut till 64 KiB, poster till en tvåpotens). Varje relä och server ser din IP-adress. Använd Tor eller Orbot på systemnivå om det spelar roll för dig.
• Det någon redan har laddat ner. Att ta bort en länk, eller en person, ger det de kunde öppna nya nycklar direkt, så att de inte öppnar det du lägger till senare; det kan inte ta tillbaka det de redan har sparat.
• En läckt länk. En länk utan lösenord är nyckeln. Webbläsaren kan spara den i sin historik innan sidan tar bort den ur adressfältet. För allt känsligt, ge länken ett lösenord som skickas på annat sätt, eller dela med personens konto. Ett svagt lösenord kan knäckas med tiden: den som har länken kan försöka offline.
• Sidan herkos.app/f/ körs i webbläsaren hos den som öppnar en länk. Den levereras med en strikt Content-Security-Policy, Subresource Integrity och ingen kod från tredje part, men den som kontrollerar webbhotellet skulle kunna leverera en annan sida. Det är gränsen för varje webbsida som dekrypterar i webbläsaren.
• Den som har haft volymnyckeln (din, eller given med en länk till en mapp) kan fortfarande radera de block som laddades upp med den, tills de laddas upp igen. Du kan byta volymnyckeln (Inställningar → Volymnyckel): dina andra enheter följer efter av sig själva.
• Din enhet. Fillistan cachas krypterad, med sin nyckel i systemets säkra lagring; en fil som du laddar ner eller öppnar skrivs i klartext där du väljer. Drives PIN är ett bekvämlighetshinder, som i Mail.
• En kvantdator, längre fram. Blocken och förseglingarna är symmetriska (AES-256, XChaCha20), men din lokaliserare är krypterad med NIP-44 på secp256k1: någon som sparar den i dag och knäcker secp256k1 i morgon skulle kunna öppna hela Drive.

Hur det kontrolleras. Två interna granskningar mot hotmodellen (2 november 2026) och deras rättelser; tester av vad varje händelse och block visar; fuzzing av varje läsare av det som kommer utifrån (händelser, förseglingar, manifest, länkar, säkerhetskopior). Ingen extern granskning ännu: en är planerad före den offentliga betan, och dess rapport kommer att publiceras i sin helhet. Drive är fortfarande under utveckling.

Versioner som stöds

Säkerhetsrättelser görs i den senast släppta versionen. Med tanke på projektets storlek underhålls inte äldre versioner — uppdatera innan du rapporterar.