Come funziona, e cosa non promettiamo.
Questa pagina è per chi vuole verificare. Per ogni componente diciamo cosa protegge e cosa no.
Architettura in una riga
Un client su ogni dispositivo, un hub per comunità (l'Outpost) raggiungibile solo come onion service Tor v3, cifratura end-to-end MLS fra i client. L'hub ordina, conserva temporaneamente e inoltra messaggi che non può leggere. Nessun server centrale, nessun componente di GiBSeS nel percorso dei dati.
Tor onion v3 con Arti
Outpost e client parlano solo attraverso Tor. L'Outpost pubblica un onion service v3: l'indirizzo deriva dalla chiave del servizio, quindi resta lo stesso se il PC cambia rete o IP, e non serve aprire porte sul router. Usiamo Arti, l'implementazione di Tor in Rust del Tor Project, integrata nel binario: nessun processo Tor esterno da installare.
- La latenza è quella di Tor. Nelle nostre prove il tempo di andata e ritorno di un messaggio tramite hub è stato fra 168 e 627 ms (mediana per scenario). Gli allegati grandi richiedono più tempo che su una connessione diretta.
- Dove la rete Tor è bloccata, Naisho non si collega. Non includiamo bridge né strumenti anti-blocco.
Versione web
La versione web è l'interfaccia, aperta nel browser, di un piccolo programma locale che parla Tor. Non c'è un server web remoto: il browser dialoga solo con il programma sul tuo computer, che porta i messaggi all'Outpost attraverso Tor.
MLS (RFC 9420) con OpenMLS
Ogni conversazione, anche quella a due, è un gruppo MLS secondo RFC 9420, implementato con OpenMLS. Suite: X25519 per lo scambio di chiavi, ChaCha20-Poly1305 per la cifratura, Ed25519 per le firme. Sono cifrati sul dispositivo testo, foto, vocali, file e anche nomi e tipi degli allegati.
- Niente post-quantum, per ora Le suite ibride per MLS sono ancora in bozza. Non le promettiamo finché non sono stabili.
- I messaggi non sono negabili Ogni messaggio è firmato dal mittente: chi lo riceve può dimostrare a terzi che l'hai scritto tu. È la stessa firma che permette di segnalare un messaggio all'operatore con la prova che è autentico.
MLS dà forward secrecy e post-compromise security: una chiave rubata oggi non decifra il traffico di ieri e, dopo un aggiornamento di chiave, non decifra quello di domani. Protegge i messaggi in viaggio, non lo storico già salvato sul telefono: quello è protetto dalla cifratura del database locale e dal blocco dell'app (PIN o biometria).
Lo abbiamo verificato con stringhe sentinella inserite nei messaggi di prova: zero occorrenze nei dati dell'hub.
Chi entra in un gruppo non legge lo storico. Chi esce o viene rimosso non legge quello che si scrive dopo. In una prova a 100 membri, la rimozione di un membro produce un commit di 8,7 KB in 6,5 ms.
Identità e chiavi
Le chiavi dell'Outpost vengono fissate all'ingresso, dall'invito. Ogni ID personale (QR o codice di 32 caratteri) contiene l'impronta della chiave: se qualcuno, hub compreso, prova a sostituirla, l'app blocca l'invio e mostra un avviso a tutta pagina. Due persone possono confrontare un codice di sicurezza di 60 cifre o un QR. Ogni comunità ha un'identità separata, con chiavi diverse.
- Al primo ingresso il client si fida del certificato dell'operatore. Un operatore malevolo può presentarti un falso membro nuovo: la contromisura è il confronto dei codici, che consigliamo per i contatti importanti.
- Identità separate fra comunità riducono il collegamento, non lo rendono impossibile. Due operatori che confrontano a lungo gli orari di connessione possono collegare la stessa persona.
- Un link d'invito intercettato può essere usato da chi lo intercetta prima del destinatario. Il QR mostrato di persona non ha questo problema.
L'hub è cieco sui contenuti. Sui metadati, no.
Questa tabella va letta per intero. Vale per l'Outpost e quindi per chi lo gestisce.
| Dato | L'hub lo vede? |
|---|---|
| Testo, foto, vocali, file, nomi e tipi degli allegati | No |
| Audio e video delle riunioni (entrambe le modalità) | Sì |
| IP dei client | No (Tor), salvo i partecipanti alle riunioni in modalità Alta qualità |
| IP dell'hub, per i client | No (onion), salvo i partecipanti alle riunioni in modalità Alta qualità |
| Elenco dei membri, con chiavi ed etichette, anche quelli riservati | Sì |
| Visibilità scelta da ciascuno | Sì |
| Chi è in quale stanza, nomi delle stanze | Sì |
| Chi scrive a chi nelle chat a due | Sì |
| Chi carica contenuti in una stanza | Sì |
| Quando e quanto spesso ognuno si collega | Sì |
| Dimensione dei messaggi | Sì |
| Chi apre una chat privata con chi a partire da una stanza | Sì |
GiBSeS non vede nessuna di queste cose: non ha server, account, telemetria, crash report né attivazione online. Chi è «visibile solo a chi ha il mio ID» resta visibile ai membri delle stanze in cui entra.
Store-and-forward
Se il destinatario è offline, la busta cifrata resta sull'Outpost fino a 30 giorni (regolabile), poi scade. Appena consegnata viene cancellata: l'Outpost lavora in solo transito e non tiene archivio dei messaggi. Restano su disco l'elenco dei membri e delle stanze e la coda dei non ritirati, in una cartella cifrata a riposo con la password dell'operatore (Argon2id). Nelle chat a due vedi «in coda», «consegnato» o «scaduto». Gli allegati viaggiano a pezzi, con ripresa dopo un'interruzione, fino a 100 MB per elemento.
Niente push
Nessuna notifica passa dai servizi push di Android e iOS. Due modalità: nessun controllo in background (predefinita) oppure un controllo periodico via Tor ogni 15, 30, 60 o 240 minuti, con una notifica locale senza contenuto. Su Android il risparmio energetico può ritardare i controlli; su iOS il sistema limita l'attività in background, quindi la ricezione è piena ad app aperta.
Chiamate audio
Le chiamate, 1:1 e di gruppo fino a circa 10 persone, viaggiano su Tor e passano dall'hub, che le inoltra solo in memoria, senza scriverle su disco. La latenza è quella di due tratte onion: aspettati un ritardo percepibile, più simile a un walkie-talkie che a una telefonata tradizionale. Se il contatto non è raggiungibile, la chiamata risulta persa e puoi lasciare un vocale. È disponibile anche una condivisione schermo leggera.
Due modalità
Componente opzionale, spento di default, che gira sull'hub come SFU (Selective Forwarding Unit). Il media è cifrato in transito, ma la SFU lo decifra per inoltrarlo: l'hub vede audio e video delle riunioni in entrambe le modalità. Non usiamo SFrame. Per il video ti fidi dell'hub, cioè di chi lo gestisce.
Protetta
il media viaggia su Tor, inoltrato dall'Outpost come relay, a bassa risoluzione per stare nella banda e nella latenza di un circuito onion. Nessun IP esposto: né quello dei partecipanti né quello dell'hub. Nessuna configurazione di rete in più.
Alta qualità
connessione diretta WebRTC fra client e Outpost, fuori da Tor, con cifratura DTLS-SRTP e TURN incluso. Servono un IP pubblico sull'hub e una o due porte aperte. Certificato self-signed: la sua impronta e l'indirizzo arrivano ai client attraverso Tor, nessun servizio esterno. Gli IP dei partecipanti li vede solo l'Outpost della comunità, non gli altri partecipanti. I partecipanti conoscono l'IP dell'hub. Come per qualsiasi connessione diretta, il provider di rete di ciascuno vede che c'è un collegamento verso quell'indirizzo.
Le chat restano sempre su Tor, qualunque modalità scegli per il video.
Requisiti
L'hub fa poca crittografia pesante: inoltra buste e ordina i commit MLS. Il carico vero è il disco (coda degli allegati, fino a 30 giorni) e la banda Tor. Il disco di lavoro deve essere un SSD: la coda scrive di continuo. Il nodo misurato a regime occupa 34-46 MB di RAM.
| Comunità | Configurazione consigliata |
|---|---|
| Fino a ~25 persone | PC o portatile acceso, 4 GB di RAM, 32 GB liberi su SSD |
| Da ~25 a 100 persone | Un computer o un mini-PC, 8 GB di RAM, SSD da 64-128 GB |
| Oltre 100 persone | Più Outpost |
| Video Alta qualità, 5 partecipanti | ~10 Mbit/s in upload sull'hub, IP pubblico, 1-2 porte |
| Video Alta qualità, 10 partecipanti | ~45 Mbit/s in upload sull'hub; computer da 8 GB |
| Video Protetta | Nessun requisito di rete in più; qualità limitata dalla banda Tor |
Outpost per Windows 10/11 x64 e Linux x86_64. Avvio automatico, online entro 3 minuti dall'accensione. Per la chat basta un uplink domestico di qualche Mbit/s: il limite pratico è la latenza di Tor, non l'hardware.
Codice
Client e Outpost sono scritti in Rust: Arti per Tor, OpenMLS per la cifratura. L'Outpost è un solo binario, senza installazione e senza diritti di amministratore.
Continua da qui
Per te e il tuo gruppo
Le foto dei bambini, i vocali della nonna, la chat del circolo restano fra voi. Trovi cosa deve fare chi gestisce il gruppo e perché Chat Control ti riguarda.
Per la tua azienda
Progetti sotto NDA, riunioni video, chat fra colleghi: i dati restano su un computer del tuo ufficio. Naisho si affianca agli strumenti che usate già.