Política de seguretat

Herkos gestiona claus privades i missatges xifrats, així que ens prenem seriosament els informes de seguretat i preferim saber d'un problema aviat que no pas tard.

Com informar d'una vulnerabilitat

Si us plau, no obris una incidència pública per a problemes de seguretat.

Informa'n en privat per correu a security@herkos.email.

Coses útils per incloure: quin és el problema, com reproduir-lo, quina plataforma i quina versió has provat, i què podria aconseguir un atacant. Una prova de concepte ajuda molt.

No incloguis mai el teu nsec, la teva clau secreta ni el secret del teu bunker en un informe.

Intentem confirmar la recepció dels informes en pocs dies. Com que Herkos és un projecte petit, et demanem que deixis un temps raonable per a una correcció abans de fer-ho públic. T'esmentarem amb molt de gust a l'avís de seguretat, tret que prefereixis el contrari.

Què entra en l'abast

L'app Herkos mateixa: el tractament i l'emmagatzematge de les claus, el xifratge i el desxifratge dels missatges (incloses les comprovacions del remitent de NIP-59 i l'aïllament de la còpia oculta (Bcc) a local_packages/nostr_mail), el bloqueig de l'app, la comunicació amb relays i bridges, el tractament dels adjunts, i el procés de compilació i publicació. Per a Herkos Drive, també el seu paquet de protocol (packages/herkos_drive_protocol) i la pàgina que n'obre els enllaços (herkos.app/f/); vegeu la seva pròpia secció més avall.

Què queda fora de l'abast

• El protocol Nostr i els seus NIP mateixos: informa'n els seus responsables originals.
• Els relays, bridges i servidors Blossom gestionats per tercers. Herkos els porta com a valors predeterminats però no els gestiona; informa'n els seus operadors.
• El projecte original Nostr Mail Client, tret que el problema sigui propi dels canvis fets a Herkos.
• Mesures de protecció que falten i que ja documentem com a limitació coneguda (vegeu més avall).

Limitacions conegudes, dites clarament

Són decisions de disseny amb els seus costos, no vulnerabilitats. Preferim escriure-les que no pas que algú les descobreixi pel camí dolent:

• El correu a adreces tradicionals no va xifrat d'extrem a extrem. Els missatges entre usuaris de Nostr fan servir gift wrap NIP-17 i van xifrats d'extrem a extrem. Quan escrius a una adreça de correu normal, un bridge converteix el missatge i el pot llegir.
• El bloqueig de l'app (PIN i biometria) és una barrera de comoditat, no un xifratge en repòs. Atura qui agafi un dispositiu desbloquejat; no protegeix contra un atacant amb accés complet al dispositiu o al seu emmagatzematge.
• A Windows no es pot imposar l'autenticació només biomètrica. Windows Hello no permet triar el mètode, de manera que el PIN del sistema sempre queda disponible com a alternativa.
• Perdre la clau vol dir perdre el compte. No hi ha recuperació, per disseny.
• Les metadades no queden del tot amagades. Els relays poden observar patrons de connexió, i tots els relays veuen la teva adreça IP, encara que no puguin llegir el contingut dels missatges. El que Herkos no revela (des del 30-09-2026) és qui escriu a qui quan un relay demana autenticació NIP-42:
• Saber on lliurar. Les llistes de relays i de Blossom d'un destinatari es demanen per una connexió separada que no t'identifica mai, primer a relays que no exigeixen autenticació (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
• Perfils i el programador. El nom i la imatge que es mostren de qualsevol altra persona (kind 0), i la llista de relays del DVM de programació quan programes o cancel·les un correu, es demanen de la mateixa manera: primer de forma anònima i, si un relay hi insisteix, amb la clau temporal que es descriu més avall, mai amb la teva (des de l'01-10-2026; abans, un relay que demanava autenticació rebia la teva clau i podia saber de qui era el perfil que miraves). Només el teu propi perfil es continua llegint com a tu.
• Lliurar. Els gift wraps van als relays DM del destinatari, per aquesta mateixa connexió separada. Si un d'ells exigeix autenticació, Herkos respon amb una clau creada per a l'ocasió i guardada només a la memòria, mai amb la teva; cada compte del dispositiu té la seva. El relay encara pot veure que el mateix dispositiu (mateixa IP, mateixa clau temporal) ha enviat diversos sobres durant una sessió.
• Correus grans. La còpia xifrada d'un correu de més de 32 KB es puja als servidors Blossom, inclosos els dels destinataris. Només els teus propis servidors (la teva llista de Blossom) reben la pujada autoritzada amb la teva clau. Qualsevol altre servidor la rep de forma anònima i, si insisteix a demanar una autorització, una signada amb la mateixa clau temporal d'abans (des de l'01-10-2026; abans, tots els servidors rebien la teva clau). Un servidor que només accepta claus conegudes la rebutja, i la còpia queda als altres servidors.
• Les teves pròpies dades. La sincronització de la bústia, les etiquetes, els ajustos i els esborranys s'autentica, quan un relay ho demana, com el compte a qui pertanyen les dades, fins i tot durant un canvi de compte. Als teus propis relays això no els diu res que no sabessin: les peticions ja porten la teva clau. Les teves pròpies llistes de relays i de Blossom són públiques i es demanen sense identificar-te, igual que els relays que apareixen en un enllaç d'un correu.
• L'estat de lectura i les carpetes són metadades públiques (de moment). Marcar un correu com a llegit, destacat, arxivat o mogut publica un esdeveniment d'etiqueta NIP-32 sense xifrar lligat a la teva clau pública, inclosos els noms de les carpetes pròpies. Un remitent que conegui l'identificador d'un correu que t'ha enviat pot saber quan hi has fet alguna cosa. Xifrar aquestes etiquetes està previst; fins llavors, considera públics els noms de les carpetes.
• Les notificacions push i l'enviament programat fan servir serveis de tercers. El servidor de push, si en tries un (cap per defecte; api.nmail.li amb relay.nmail.li si ho demanes), coneix la teva clau pública, un testimoni de push i quan reps correu; el DVM de programació coneix la teva clau pública i els missatges ja xifrats que ha de publicar. Tots dos són opcionals i estan documentats a PRIVACY.md. El text d'una notificació push el tria el servidor de push, i Herkos només se'n refia quan UnifiedPush el lliura xifrat (RFC 8291); un contingut sense xifrar només desperta l'app perquè vagi a buscar el correu ella mateixa.
• La versió web guarda la teva clau al navegador, que és el lloc més feble per a ella. Les aplicacions instal·lades confien la teva clau secreta a l'emmagatzematge segur del sistema operatiu (Android Keystore, DPAPI a Windows, libsecret, el Clauer d'iOS/macOS). Un navegador no té res d'això: la clau és a l'emmagatzematge de l'origen i passa per JavaScript a cada signatura, a l'abast de qualsevol codi que s'executi a la pàgina —una extensió del navegador amb accés a totes les pàgines, un error d'XSS a l'app o en una dependència, un desplegament manipulat— i de qualsevol programa robador d'informació que copiï el perfil del navegador. A més, no hi ha cap moment en què verifiquis el codi una vegada: un binari signat es comprova en instal·lar-lo, mentre que una pàgina web serveix codi nou a cada visita. Entra a la versió web amb un signant remot (bunker NIP-46, Amber), perquè la clau no arribi mai al navegador, o tracta-la com una identitat d'usar i llençar i guarda la teva clau real en una app instal·lada.
• El correu que passa per un bridge només és tan fiable com el bridge. Herkos verifica que un missatge marcat com a arribat a través d'un bridge l'hagi signat realment un bridge que tens configurat (o un dels predeterminats). No pot verificar res de l'adreça From: tradicional que retransmet el bridge.
• Els adjunts els obre el sistema operatiu. Herkos no executa mai tipus de fitxer executables ni scripts, i pregunta abans de passar qualsevol altre adjunt que no es pugui previsualitzar a l'app predeterminada del sistema, però l'app que obre el fitxer és fora del nostre control.

Herkos Local Relay: què protegeix i què no

Herkos Local Relay guarda al teu dispositiu els esdeveniments de les teves aplicacions, també els privats (esborranys, llistes privades, els sobres que reps). Això és el que els protegeix i on és el límit, plataforma per plataforma. Els problemes de seguretat del relay s'informen igual que els altres (més amunt).

La base de dades va xifrada sencera, el diari inclòs (SQLite3 Multiple Ciphers, AEGIS-256). La clau són 32 bytes aleatoris creats al dispositiu i desats a l'emmagatzematge segur del sistema: el Keystore a Android, DPAPI a Windows, el clauer (libsecret) a Linux. No porta cap contrasenya teva, perquè el relay ha d'arrencar sol. Sense la clau, el relay no arrenca i ho diu: no obre ni crea mai una base sense xifrar, i no esborra mai la que no pot obrir.

A l'escriptori, el límit de DPAPI i del clauer és el de qualsevol programa: protegeixen contra altres usuaris i contra qui s'emporta el disc, no contra un programa maliciós que ja s'executa amb el teu usuari. Si et preocupa aquest cas, el que protegeix és el xifratge del disc del sistema (BitLocker, LUKS) juntament amb no executar programes en què no confies. A Linux sense clauer (sense Secret Service), el relay no arrenca i ho explica: no guarda mai la clau en clar.

Qui hi entra, al mateix dispositiu. El relay només escolta a 127.0.0.1, i qualsevol aplicació del dispositiu, o una pàgina web del navegador, pot arribar a aquesta adreça. Per això:

• Una aplicació s'ha d'aparellar: apareix a la pantalla del relay i tu l'aproves (amb el PIN o l'empremta, si els vas posar). Qualsevol aplicació es pot posar qualsevol nom: aprova-la només si l'acabes de demanar des d'aquesta aplicació.
• Una pàgina web s'aparella sempre, i un aparellament només val des d'on es va fer: el d'una aplicació del dispositiu no obre res a una pàgina web, encara que signi amb la mateixa clau.
• Una aplicació aparellada només llegeix i escriu els tipus d'esdeveniment que li vas donar, i només esborra els que pot escriure. Revocar-la la desconnecta a l'instant.
• Una aplicació sense aparellar només llegeix els teus esdeveniments públics (que ja són públics) i no escriu res, tret que activis l'ajust que deixa entrar les aplicacions del dispositiu sense aparellar.
• Els esdeveniments privats només s'entreguen a qui demostra amb NIP-42 que té la clau a la qual pertanyen, i un sobre, només al seu destinatari.

El que no protegeix, aquí:

• Una aplicació maliciosa del dispositiu pot alentir el relay o fer-li gastar memòria. Així no pot llegir res privat.
• Mentre el relay dorm o no funciona, el port queda lliure. A Android s'adorm després de 10 minuts sense connexions; a l'escriptori, el port és lliure mentre no l'arrenques. Una altra aplicació podria escoltar-hi i fer-se passar per ell. Les aplicacions de Herkos comprovaran la clau del relay abans d'enviar-li res privat; encara no ho fan, i fins llavors aquest és un límit real.
• A l'escriptori, altres usuaris de l'ordinador es poden connectar com una aplicació sense aparellar: llegir els teus esdeveniments públics i demanar d'aparellar-se.

La xarxa local, si l'actives (ve desactivada):

• Només wss://, amb un certificat propi del relay; mai ws:// sense xifrar fora del dispositiu.
• Res abans d'autenticar-se (NIP-42) amb una clau de la teva llista. Una connexió que no ho fa en 30 segons es tanca, i la xarxa local té un nombre de connexions propi: no ocupa mai les de les aplicacions del dispositiu.
• Una clau de la llista llegeix els teus esdeveniments públics i els seus privats, i només escriu esdeveniments signats per ella. Treure-la de la llista la desconnecta.
• El certificat només val per a noms de casa (localhost, .local, adreces privades): encara que algú en robés la clau, no li serviria per signar un domini d'Internet als aparells que l'han instal·lat.

El que no protegeix, aquí: qui és a la mateixa xarxa veu que l'aparell té un port obert i quant trànsit hi passa, però no què hi passa; i si l'aparell té una adreça pública (sense router entremig), aquest port es veu des d'Internet, encara que continuï demanant una clau de la teva llista.

Còpies. La còpia xifrada porta contrasenya (scrypt i XChaCha20-Poly1305): sense ella ningú no la pot obrir, tampoc nosaltres. L'exportació JSONL no està xifrada i conté els teus esdeveniments privats en clar; l'aplicació t'avisa.

El bloqueig (PIN, i empremta o Windows Hello) es demana en obrir l'aplicació, després de 30 segons fora, i per aprovar un aparellament. És una barrera de comoditat, com a Mail: no xifra res. A Android, amb PIN no hi ha captures de pantalla ni miniatura a les aplicacions recents, i des d'Android 12 cap finestra d'una altra aplicació no es pot posar damunt de la del relay mentre la fas servir.

Herkos Drive: què protegeix i què no

Herkos Drive guarda els teus fitxers en servidors Blossom i la llista dels teus fitxers i carpetes en relays de Nostr, tot xifrat al teu dispositiu. Això és el que els protegeix i on són els límits. El detall complet és a spec-drive.md i al model d'amenaces amenazas-drive.md, a packages/herkos_drive_protocol/; el que veu cada relay i cada servidor és a la política de privacitat. Els problemes de seguretat de Drive s'informen igual que els altres (més amunt).

El que els relays i els servidors no poden fer:

• Llegir els teus fitxers o els seus noms. Cada bloc d'un fitxer es xifra amb AES-256-GCM amb una clau pròpia de la seva revisió; els noms, les carpetes, les mides, les dates i les claus van segellats amb XChaCha20-Poly1305 amb la clau de la carpeta on són. Res no es deriva del contingut: el mateix fitxer pujat dues vegades dona blocs diferents.
• Canviar, intercanviar o moure res sense que es noti. Cada bloc es comprova amb el manifest segellat a l'entrada del seu fitxer, i cada entrada va signada per la clau del volum i segellada per al seu lloc (volum, identificador i carpeta): un relay no pot fer passar una entrada per una altra, ni un bloc per un altre.
• Tornar a una versió antiga. L'aplicació no accepta mai una entrada més antiga que la que ja té per al mateix identificador.
• Escriure com tu només amb la clau del volum. El que escriuen els teus dispositius porta la marca del propietari, un HMAC amb una clau que cap enllaç no dona; una entrada o un esborrat sense aquesta marca no s'accepta, i l'aplicació t'avisa.

El que no protegeix:

• El patró del teu Drive. Els relays poden comptar els teus fitxers i carpetes, veure la forma de l'arbre i quan canvia cada entrada; els servidors veuen aproximadament quina mida té cada fitxer (els blocs es farceixen fins a 64 KiB, les entrades fins a una potència de dos). Cada relay i cada servidor veu la teva adreça IP. Fes servir Tor o Orbot a nivell de sistema si això t'importa.
• El que algú ja ha baixat. Eliminar un enllaç, o una persona, dona de seguida claus noves al que podia obrir, de manera que no pot obrir el que hi afegeixis després; no pot recuperar el que ja ha desat.
• Un enllaç filtrat. Un enllaç sense contrasenya és la clau. El navegador el pot guardar a l'historial abans que la pàgina el tregui de la barra d'adreces. Per a qualsevol cosa delicada, posa una contrasenya a l'enllaç, enviada per una altra via, o comparteix amb el compte de la persona. Una contrasenya feble es pot trencar amb temps: qui té l'enllaç pot provar-ho fora de línia.
• La pàgina herkos.app/f/ s'executa al navegador de qui obre un enllaç. Se serveix amb una Content-Security-Policy estricta, Subresource Integrity i cap codi de tercers, però qui controli l'allotjament web podria servir una pàgina diferent. Aquest és el límit de qualsevol pàgina web que desxifra al navegador.
• Qui hagi tingut la clau del volum (la teva, o la que es dona amb un enllaç a una carpeta) encara pot esborrar els blocs que es van pujar amb ella, fins que es tornin a pujar. Pots canviar la clau del volum (Ajustos → Clau del volum): els teus altres dispositius la segueixen sols.
• El teu dispositiu. La llista de fitxers es guarda en memòria cau xifrada, amb la clau a l'emmagatzematge segur del sistema; un fitxer que baixes o obres s'escriu en clar on tu tries. El PIN de Drive és una barrera de comoditat, com a Mail.
• Un ordinador quàntic, més endavant. Els blocs i els segells són simètrics (AES-256, XChaCha20), però el teu localitzador va xifrat amb NIP-44 sobre secp256k1: qui el guardi avui i trenqui secp256k1 demà podria obrir tot el Drive.

Com es comprova. Dues revisions internes contra el model d'amenaces (2 de novembre de 2026) i les seves correccions; proves del que mostra cada esdeveniment i cada bloc; fuzzing de cada lector del que ve de fora (esdeveniments, segells, manifestos, enllaços, còpies de seguretat). Encara no hi ha cap auditoria externa: n'hi ha una de prevista abans de la beta pública, i el seu informe es publicarà sencer. Drive encara és en desenvolupament.

Versions amb suport

Les correccions de seguretat s'apliquen a l'última versió publicada. Tenint en compte la mida del projecte, les versions anteriors no es mantenen: actualitza abans d'informar d'un problema.