Politica di sicurezza

Herkos gestisce chiavi private e messaggi cifrati, quindi prendiamo sul serio le segnalazioni di sicurezza e preferiamo sapere di un problema presto piuttosto che tardi.

Segnalare una vulnerabilità

Per favore non aprire una issue pubblica per i problemi di sicurezza.

Segnalalo in privato via email a security@herkos.email.

Cose utili da includere: qual è il problema, come riprodurlo, su quale piattaforma e versione l'hai testato e cosa potrebbe ottenere un attaccante. Una prova di concetto aiuta molto.

Non includere mai il tuo nsec, la tua chiave segreta o il segreto del tuo bunker in una segnalazione.

Cerchiamo di confermare la ricezione delle segnalazioni entro pochi giorni. Poiché Herkos è un piccolo progetto, concedi un tempo ragionevole per una correzione prima di renderla pubblica. Saremo lieti di citarti nell'avviso, a meno che tu non preferisca altrimenti.

Cosa rientra nell'ambito

L'applicazione Herkos in sé: gestione e conservazione delle chiavi, cifratura e decifratura dei messaggi (compresi i controlli sul mittente NIP-59 e l'isolamento del Bcc in local_packages/nostr_mail), il blocco dell'app, la comunicazione con relay e bridge, la gestione degli allegati e la pipeline di build e rilascio. Per Herkos Drive, anche il suo pacchetto di protocollo (packages/herkos_drive_protocol) e la pagina che ne apre i link (herkos.app/f/); vedi la sua sezione più sotto.

Cosa non rientra nell'ambito

• Il protocollo Nostr e i suoi NIP in quanto tali — segnalali a monte.
• Relay, bridge e server Blossom gestiti da terzi. Herkos li include come predefiniti ma non li gestisce; segnala i problemi ai loro operatori.
• Il progetto originale Nostr Mail Client, a meno che il problema non riguardi specificamente modifiche fatte in Herkos.
• Irrobustimenti mancanti che documentiamo già come limiti noti (vedi sotto).

Limiti noti, detti chiaramente

Questi sono compromessi di progettazione, non vulnerabilità. Preferiamo metterli per iscritto piuttosto che qualcuno li scopra a proprie spese:

• La posta verso indirizzi tradizionali non è cifrata end-to-end. I messaggi tra utenti Nostr usano il gift wrap NIP-17 e sono cifrati end-to-end. Quando scrivi a un indirizzo email tradizionale, un bridge converte il messaggio e può leggerlo.
• Il blocco dell'app (PIN e biometria) è una barriera di comodità, non una cifratura a riposo. Ferma chi prende in mano un dispositivo sbloccato; non protegge da un attaccante con pieno accesso al dispositivo o alla sua memoria.
• Su Windows non si può imporre l'autenticazione solo biometrica. Windows Hello non consente di scegliere il metodo, quindi il PIN di sistema resta sempre disponibile come alternativa.
• Perdere la chiave significa perdere l'account. Non c'è recupero, per scelta.
• I metadati non sono del tutto nascosti. I relay possono osservare gli schemi di connessione, e ogni relay vede il tuo indirizzo IP, anche quando non può leggere il contenuto dei messaggi. Ciò che Herkos non rivela (dal 30-09-2026) è chi scrive a chi quando un relay chiede l'autenticazione NIP-42:
• Cercare dove consegnare. Gli elenchi di relay e di server Blossom di un destinatario vengono richiesti su una connessione separata che non ti identifica mai, prima su relay che non richiedono autenticazione (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
• Profili e pianificatore. Il nome e l'immagine mostrati per chiunque altro (kind 0), e l'elenco di relay della DVM di pianificazione quando programmi o annulli un'email, vengono richiesti allo stesso modo: prima in forma anonima e, se un relay insiste, con la chiave temporanea descritta più sotto, mai con la tua (dal 01-10-2026; prima, un relay che chiedeva l'autenticazione otteneva la tua chiave, e poteva sapere di chi stavi guardando il profilo). Solo il tuo profilo viene ancora letto a tuo nome.
• Consegnare. I gift wrap vanno ai relay DM del destinatario, su quella stessa connessione separata. Se uno di essi richiede l'autenticazione, Herkos risponde con una chiave creata apposta e conservata solo in memoria, mai con la tua; ogni account sul dispositivo ha la propria. Il relay può comunque vedere che lo stesso dispositivo (stesso IP, stessa chiave temporanea) ha inviato più buste durante una sessione.
• Email di grandi dimensioni. La copia cifrata di un'email oltre i 32 KB viene caricata su server Blossom, compresi quelli dei destinatari. Solo i tuoi server (il tuo elenco Blossom) ricevono il caricamento autorizzato con la tua chiave. Qualsiasi altro server lo riceve in forma anonima e, se insiste per un'autorizzazione, una firmata con la stessa chiave temporanea di cui sopra (dal 01-10-2026; prima, ogni server otteneva la tua chiave). Un server che accetta solo chiavi conosciute lo rifiuta, e la copia resta sugli altri server.
• I tuoi dati. La sincronizzazione della tua casella, delle etichette, delle impostazioni e delle bozze si autentica, quando un relay lo chiede, come l'account a cui appartengono i dati, anche durante un cambio di account. Sui tuoi relay questo non dice loro nulla che non sapessero già: le richieste nominano comunque la tua chiave. I tuoi elenchi di relay e di server Blossom sono pubblici e vengono richiesti senza identificarti, e così i relay indicati in un link di un'email.
• Lo stato di lettura e le cartelle sono metadati pubblici (per ora). Segnare un'email come letta, preferita, archiviata o spostata pubblica un evento etichetta NIP-32 non cifrato legato alla tua chiave pubblica, compresi i nomi delle cartelle personalizzate. Un mittente che conosce l'identificativo di un'email che ti ha inviato può sapere quando ci hai agito sopra. La cifratura di queste etichette è prevista; fino ad allora, considera pubblici i nomi delle cartelle.
• Le notifiche push e l'invio programmato usano servizi di terze parti. Il server push, se ne scegli uno (nessuno per impostazione predefinita; api.nmail.li con relay.nmail.li su richiesta), apprende la tua chiave pubblica, un token push e quando ricevi posta; la DVM di pianificazione apprende la tua chiave pubblica e i messaggi già cifrati che deve pubblicare. Entrambi sono facoltativi e documentati in PRIVACY.md. Il testo di una notifica push è scelto dal server push, e Herkos se ne fida solo quando UnifiedPush lo consegna cifrato (RFC 8291); un payload non cifrato si limita a risvegliare l'app perché scarichi la posta da sé.
• La versione web tiene la tua chiave nel browser, che è il posto più debole in cui tenerla. Le app installate affidano la tua chiave segreta all'archivio sicuro del sistema operativo (Android Keystore, DPAPI su Windows, libsecret, il portachiavi di iOS/macOS). Un browser non ha nulla di tutto ciò: la chiave sta nell'archiviazione dell'origine e passa da JavaScript a ogni firma, alla portata di qualsiasi codice eseguito nella pagina — un'estensione del browser con accesso a tutti i siti, un bug XSS nell'app o in una dipendenza, un rilascio manomesso — e di qualsiasi infostealer che copi il profilo del browser. Non c'è nemmeno un momento in cui verifichi il codice una volta per tutte: un binario firmato viene controllato all'installazione, mentre una pagina web serve codice nuovo a ogni visita. Accedi alla versione web con un firmatario remoto (bunker NIP-46, Amber), così la chiave non raggiunge mai il browser, oppure trattala come un'identità usa e getta e tieni la tua vera chiave in un'app installata.
• La posta tramite bridge è affidabile solo quanto il bridge. Herkos verifica che un messaggio indicato come proveniente da un bridge sia stato davvero firmato da un bridge che hai configurato (o da uno di quelli predefiniti). Non può verificare nulla sull'indirizzo From: tradizionale che il bridge inoltra.
• Gli allegati vengono aperti dal sistema operativo. Herkos non avvia mai tipi di file eseguibili o script e chiede conferma prima di passare qualsiasi altro allegato non visualizzabile all'app predefinita del sistema, ma l'app che apre il file è fuori dal nostro controllo.

Herkos Local Relay: cosa protegge e cosa no

Herkos Local Relay conserva sul tuo dispositivo gli eventi delle tue app, anche quelli privati (bozze, elenchi privati, le buste che ricevi). Ecco cosa li protegge e dov'è il limite, piattaforma per piattaforma. I problemi di sicurezza del relay si segnalano come tutti gli altri (sopra).

Il database è cifrato per intero, journal compreso (SQLite3 Multiple Ciphers, AEGIS-256). La chiave è fatta di 32 byte casuali creati sul dispositivo e conservati nell'archivio sicuro del sistema: il Keystore su Android, DPAPI su Windows, il portachiavi (libsecret) su Linux. Non dipende da una tua password, perché il relay deve avviarsi da solo. Senza la chiave il relay non si avvia e lo dice: non apre né crea mai un database non cifrato, e non elimina mai quello che non riesce ad aprire.

Sul desktop, il limite di DPAPI e del portachiavi è quello di qualsiasi programma: proteggono dagli altri utenti e da chi si porta via il disco, non da un programma malevolo già in esecuzione con il tuo utente. Se questo caso ti preoccupa, ciò che ti protegge è la cifratura del disco di sistema (BitLocker, LUKS) insieme al non eseguire programmi di cui non ti fidi. Su un Linux senza portachiavi (senza Secret Service) il relay non si avvia e spiega perché: non tiene mai la chiave in chiaro.

Chi entra, sul dispositivo stesso. Il relay ascolta solo su 127.0.0.1, e qualsiasi app del dispositivo, o una pagina web nel browser, può raggiungere quell'indirizzo. Per questo:

• Un'app deve essere abbinata: compare sulla schermata del relay e tu la approvi (con il PIN o l'impronta, se li hai impostati). Qualsiasi app può darsi qualsiasi nome: approva solo se l'hai appena chiesto da quell'app.
• Una pagina web viene sempre abbinata, e un abbinamento vale solo da dove è stato fatto: quello di un'app del dispositivo non apre nulla a una pagina web, anche se firma con la stessa chiave.
• Un'app abbinata legge e scrive solo i tipi di evento che le hai concesso, ed elimina solo quelli che può scrivere. Revocarla la disconnette subito.
• Un'app non abbinata legge solo i tuoi eventi pubblici (che sono comunque pubblici) e non scrive nulla, a meno che tu non attivi l'impostazione che lascia entrare le app del dispositivo non abbinate.
• Gli eventi privati vengono dati solo a chi dimostra con NIP-42 di possedere la chiave a cui appartengono, e una busta, solo al suo destinatario.

Cosa non protegge, qui:

• Un'app malevola sul dispositivo può rallentare il relay o fargli consumare memoria. Non può leggere nulla di privato in questo modo.
• Mentre il relay è sospeso o non è in funzione, la sua porta è libera. Su Android si sospende dopo 10 minuti senza connessioni; sul desktop la porta è libera finché non lo avvii. Un'altra app potrebbe mettersi in ascolto lì e spacciarsi per il relay. Le app Herkos verificheranno la chiave del relay prima di inviargli qualcosa di privato; ancora non lo fanno, e fino ad allora questo è un limite reale.
• Sul desktop, gli altri utenti del computer possono connettersi come un'app non abbinata: leggere i tuoi eventi pubblici e chiedere l'abbinamento.

La rete locale, se la attivi (è disattivata per impostazione predefinita):

• Solo wss://, con un certificato proprio del relay; mai ws:// non cifrato fuori dal dispositivo.
• Nulla prima di autenticarsi (NIP-42) con una chiave del tuo elenco. Una connessione che non lo fa entro 30 secondi viene chiusa, e la rete locale ha un proprio numero di connessioni: non occupa mai quelle delle app del dispositivo.
• Una chiave dell'elenco legge i tuoi eventi pubblici e i propri eventi privati, e scrive solo eventi firmati da lei. Toglierla dall'elenco la disconnette.
• Il certificato vale solo per nomi di casa (localhost, .local, indirizzi privati): anche se qualcuno ne rubasse la chiave, non gli servirebbe a firmare un dominio Internet sui dispositivi che lo hanno installato.

Cosa non protegge, qui: chi è sulla stessa rete vede che il dispositivo ha una porta aperta e quanto traffico vi passa, ma non cosa; e se il dispositivo ha un indirizzo pubblico (senza router in mezzo), quella porta è visibile da Internet, anche se continua a chiedere una chiave del tuo elenco.

Copie. La copia cifrata ha una password (scrypt e XChaCha20-Poly1305): senza di essa nessuno può aprirla, nemmeno noi. L'esportazione JSONL non è cifrata e contiene i tuoi eventi privati in chiaro; l'app ti avvisa.

Il blocco (PIN, e impronta o Windows Hello) viene chiesto all'apertura dell'app, dopo 30 secondi di assenza, e per approvare un abbinamento. È una barriera di comodità, come in Mail: non cifra nulla. Su Android, con il PIN impostato non ci sono screenshot né anteprima tra le app recenti, e da Android 12 nessuna finestra di un'altra app può sovrapporsi a quella del relay mentre la usi.

Herkos Drive: cosa protegge e cosa no

Herkos Drive conserva i tuoi file su server Blossom e l'elenco dei tuoi file e cartelle su relay Nostr, entrambi cifrati sul tuo dispositivo. Ecco cosa li protegge e dove sono i limiti. Il dettaglio completo è in spec-drive.md e nel modello delle minacce amenazas-drive.md, in packages/herkos_drive_protocol/; cosa vede ogni relay e ogni server è nell'informativa sulla privacy. Segnala i problemi di sicurezza di Drive come qualsiasi altro (vedi sopra).

Cosa relay e server non possono fare:

• Leggere i tuoi file o i loro nomi. Ogni blocco di un file è cifrato con AES-256-GCM con una chiave propria della sua revisione; nomi, cartelle, dimensioni, date e chiavi vanno sigillati con XChaCha20-Poly1305 con la chiave della cartella in cui si trovano. Niente è derivato dal contenuto: lo stesso file caricato due volte dà blocchi diversi.
• Cambiare, scambiare o spostare qualcosa senza che si noti. Ogni blocco viene verificato rispetto al manifesto sigillato nella voce del suo file, e ogni voce è firmata dalla chiave del volume e sigillata per il proprio posto (volume, identificativo e cartella): un relay non può far passare una voce per un'altra, né un blocco per un altro.
• Riportare una versione vecchia. L'app non accetta mai una voce più vecchia di quella che ha già per lo stesso identificativo.
• Scrivere al posto tuo con la sola chiave del volume. Ciò che scrivono i tuoi dispositivi porta il marchio del proprietario, un HMAC con una chiave che nessun link fornisce; una voce o un'eliminazione senza di esso non viene accettata, e l'app ti avvisa.

Cosa non protegge:

• Lo schema del tuo Drive. I relay possono contare i tuoi file e cartelle, vedere la forma dell'albero e quando cambia ogni voce; i server vedono più o meno quanto è grande ogni file (i blocchi sono riempiti fino a 64 KiB, le voci fino a una potenza di due). Ogni relay e ogni server vede il tuo indirizzo IP. Usa Tor o Orbot a livello di sistema se per te è importante.
• Ciò che qualcuno ha già scaricato. Rimuovere un link, o una persona, dà subito chiavi nuove a ciò che poteva aprire, così non apre ciò che aggiungi dopo; non può riprendersi ciò che ha già salvato.
• Un link trapelato. Un link senza password è la chiave. Il browser può conservarlo nella cronologia prima che la pagina lo tolga dalla barra degli indirizzi. Per qualsiasi cosa delicata, dai al link una password, inviata per un'altra via, oppure condividi con l'account della persona. Una password debole può essere forzata con il tempo: chi ha il link può provare offline.
• La pagina herkos.app/f/ viene eseguita nel browser di chi apre un link. È servita con una Content-Security-Policy rigorosa, Subresource Integrity e nessun codice di terze parti, ma chi controlla l'hosting web potrebbe servire una pagina diversa. È il limite di ogni pagina web che decifra nel browser.
• Chi ha avuto la chiave del volume (la tua, o quella data con un link a una cartella) può ancora eliminare i blocchi caricati con essa, finché non vengono caricati di nuovo. Puoi cambiare la chiave del volume (Impostazioni → Chiave del volume): gli altri tuoi dispositivi si adeguano da soli.
• Il tuo dispositivo. L'elenco dei file è memorizzato in cache cifrato, con la sua chiave nell'archivio sicuro del sistema; un file che scarichi o apri viene scritto in chiaro dove scegli tu. Il PIN di Drive è una barriera di comodità, come in Mail.
• Un computer quantistico, in futuro. I blocchi e i sigilli sono simmetrici (AES-256, XChaCha20), ma il tuo localizzatore è cifrato con NIP-44 su secp256k1: chi lo conserva oggi e rompe secp256k1 domani potrebbe aprire tutto il Drive.

Come viene verificato. Due revisioni interne rispetto al modello delle minacce (2 novembre 2026) e le relative correzioni; test di ciò che mostra ogni evento e ogni blocco; fuzzing di ogni lettore di ciò che arriva dall'esterno (eventi, sigilli, manifesti, link, backup). Nessun audit esterno ancora: ne è previsto uno prima della beta pubblica, e il suo rapporto sarà pubblicato integralmente. Drive è ancora in sviluppo.

Versioni supportate

Le correzioni di sicurezza vengono applicate all'ultima versione rilasciata. Viste le dimensioni del progetto, le versioni precedenti non sono mantenute — aggiorna prima di segnalare.