1. Crittografia end-to-end — Messaggi privati
Ogni messaggio inviato in una conversazione privata viene cifrato interamente sul dispositivo del mittente prima di essere trasmesso. La crittografia è end-to-end: il server non può accedere al contenuto dei messaggi nel funzionamento normale del sistema (per il limite legato alla password vedi §3).
- Per ogni messaggio viene generata una coppia di chiavi effimera usa-e-getta. L'accordo di chiave avviene senza che la chiave di sessione venga mai trasmessa in rete.
- Il contenuto è protetto da cifratura autenticata, che garantisce simultaneamente riservatezza e integrità, rilevando qualsiasi manomissione.
Ogni messaggio produce due ciphertext indipendenti: una copia cifrata per il destinatario e una copia cifrata per il mittente. Il server archivia esclusivamente i ciphertext; non è in grado di decifrare nessun messaggio.
I messaggi ricevuti sono inoltre protetti da un protocollo a chiavi effimere per messaggio (Double Ratchet, lo stesso principio del Signal Protocol), con forward secrecy: anche se in futuro la chiave a lungo termine dell'account venisse compromessa, le conversazioni ricevute in passato restano protette, perché le chiavi usate per cifrarle non sono più ricostruibili. I messaggi vocali, per ora, fanno eccezione: usano chiavi effimere per messaggio ma verso la chiave a lungo termine del destinatario, senza il ratchet, e quindi non hanno la forward secrecy descritta qui.
La copia dei messaggi inviati — che permette di rileggere ciò che si è scritto — utilizza invece la chiave a lungo termine dell'account, non il meccanismo a chiavi effimere. Una eventuale compromissione futura di questa chiave potrebbe quindi rendere decifrabili le copie storiche dei messaggi inviati, inclusi quelli vocali, mentre i messaggi ricevuti resterebbero protetti. La rotazione periodica di questa chiave è attualmente sospesa: finché non verrà riattivata, la finestra di esposizione delle copie dei messaggi inviati non è limitata nel tempo. Quando il Double Ratchet non è attivo tra due dispositivi (per esempio finché un contatto non ha accettato il nuovo codice di sicurezza dopo un cambio di dispositivo), il messaggio parte in modalità base: resta cifrato end-to-end, ma senza la protezione aggiuntiva del ratchet.
2. Crittografia end-to-end — Stanze (gruppi)
Le conversazioni di gruppo utilizzano una chiave simmetrica condivisa, distribuita in modo sicuro a ogni partecipante:
- Al momento della creazione, il fondatore genera una chiave AES-GCM-256 casuale.
- La chiave di gruppo viene cifrata individualmente per ogni membro tramite ECDH P-256 e consegnata in modo sicuro.
- Ogni partecipante decifra la chiave sul proprio dispositivo e la conserva localmente nel browser.
- I messaggi nella stanza sono cifrati con la chiave condivisa; ogni messaggio utilizza un IV casuale e unico.
Il server non conosce la chiave di gruppo. Riceve e archivia esclusivamente i ciphertext cifrati con essa.
3. Gestione delle chiavi crittografiche
La coppia di chiavi ECDH P-256 (pubblica e privata) viene generata interamente nel browser tramite la Web Crypto API al momento della registrazione. La chiave privata non lascia mai il dispositivo in forma leggibile:
- La chiave privata viene cifrata localmente usando una chiave derivata dalla password dell'utente tramite funzioni crittografiche standard del browser. La chiave di cifratura viene derivata sul dispositivo. La password, però, viene inviata al server quando ti registri, accedi, la cambi o recuperi l'account, perché il server deve verificarla (ne conserva solo l'impronta Argon2): un server compromesso potrebbe catturarla in quel momento e, con essa, ricostruire la chiave. Separare le due cose, così che il server non riceva mai ciò che serve a cifrare, è un lavoro pianificato.
- Solo il ciphertext della chiave privata viene inviato al server, consentendo l'accesso da dispositivi e browser diversi.
- Al login, il ciphertext viene scaricato e decifrato localmente inserendo la password: il server non ha mai accesso alla chiave privata in chiaro.
La chiave pubblica è archiviata in chiaro sul server e resa disponibile agli altri utenti autorizzati per cifrare i messaggi diretti all'account.
4. Hashing delle credenziali
Le password non vengono mai archiviate in chiaro né in forma reversibile. Orvhalis utilizza Argon2 — vincitore della Password Hashing Competition (PHC) e algoritmo raccomandato per la resistenza ad attacchi brute-force, GPU e ASIC — per derivare un hash unidirezionale. Anche la seed phrase di recupero è archiviata esclusivamente come hash Argon2; il valore in chiaro non viene mai conservato. La password viaggia al server, protetta da HTTPS, soltanto per essere verificata: il server ne conserva solo l'impronta Argon2 e non la scrive nei log.
5. Seed phrase di recupero BIP-39
Al momento della registrazione, Orvhalis genera una seed phrase di 12 parole tratte dal vocabolario standard BIP-39 (2048 parole inglesi). Questo è l'unico metodo di recupero dell'account: non esiste alcun indirizzo email o numero di telefono a cui inviare un link di reset.
La seed phrase va annotata e conservata offline in un luogo sicuro. Non è recuperabile in alcun altro modo: nemmeno Orvhalis può ripristinare un account senza di essa.
6. Nessun identificatore personale
Orvhalis non richiede email, numero di telefono, nome reale o altri dati che identificano una persona. L'identità di ogni utente è un codice casuale nel formato ID-XXXX-XXXX, costruito con un alfabeto privo di caratteri ambigui (esclusi 0, O, I, L, 1). I contatti si aggiungono in tre modi: con il QR code o con il dispositivo NFC, quando due persone sono vicine, oppure a distanza, inserendo l'ID del contatto e una parola segreta che gli hai comunicato. Il QR resta valido al massimo 5 minuti ed è monouso. Per il contatto a distanza la parola segreta è conservata solo come impronta non reversibile, sono ammessi 5 tentativi per richiesta, la richiesta scade dopo 24 ore e ogni persona ne può inviare al massimo 10 al giorno. Chi conosce l'ID di un'altra persona può quindi inviarle una richiesta, ma deve essere accettata; la ricezione delle richieste a distanza si disattiva nelle Impostazioni, e QR e NFC restano sempre attivi.
7. Raccolta minima dei dati
Orvhalis adotta un principio di minimizzazione rigorosa. Le informazioni archiviate sul server sono limitate a:
- Codice utente (ID-XXXX-XXXX), hash Argon2 della password e della seed phrase
- Chiave pubblica ECDH P-256 e ciphertext della chiave privata cifrata
- Ciphertext dei messaggi, IV e ephemeral public key (parametri pubblici di cifratura)
- Metadati minimi: timestamp di invio, stato di lettura, flag di modifica/eliminazione
- Lista contatti: codice del nodo e alias privato opzionale assegnato dall'utente
- Impostazioni dell'account: timer di distruzione, preferenze di notifica
- Immagine del profilo, se caricata: archiviata in chiaro e non cifrata — vedi la sezione 11
- Un contatore anonimo dei messaggi che un dispositivo non è riuscito a decifrare: per ogni giorno si registra soltanto la categoria tecnica dell'errore, mai il contenuto del messaggio, il codice dell'utente o il contatto coinvolto. Serve unicamente a capire se un problema tecnico colpisce molte persone
- Iscrizione alle notifiche di ogni dispositivo
- Chiavi pubbliche del Double Ratchet e copia cifrata dell'identità (vedi §12)
- Registro dei cambi delle tue chiavi di cifratura (data e motivo), mostrato nel Profilo
- Modo in cui è nato ogni contatto (QR, NFC o a distanza) e richieste di contatto in attesa (24 ore, con il messaggio facoltativo, in chiaro)
- Lingua, sfondo e altre impostazioni dell'account
- Alla registrazione, il servizio esterno Cloudflare Turnstile, che vede l'indirizzo IP e il browser di chi si registra e che viene caricato solo quando apri la registrazione
Non vengono raccolti dati di navigazione, fingerprint del dispositivo, dati comportamentali o metriche di utilizzo. Gli indirizzi IP non vengono conservati per intero: nei log di accesso l'ultimo numero è azzerato, nei log dell'app compare solo un'impronta non reversibile, e i log si cancellano da soli dopo 14 giorni. Solo per limitare gli abusi, il server tiene in memoria l'indirizzo completo per poco tempo (15 minuti per gli accessi, fino a mezzanotte per le registrazioni). Le pagine non caricano risorse da servizi di terze parti, a parte Cloudflare Turnstile alla registrazione; i font sono ospitati sul nostro server. Le notifiche push contengono solo un testo generico (per esempio «Nuovo messaggio»), mai il contenuto, titoli o nomi, e passano dal servizio di notifiche del browser (Google, Apple, Microsoft o Mozilla).
8. Architettura stateless e zero conoscenza del server
Il backend è progettato con un'architettura stateless: nessuno stato relativo al contenuto delle comunicazioni viene mantenuto in memoria. Le sessioni autenticate sono token opachi archiviati in Redis: durano 90 giorni, si rinnovano a ogni connessione e ogni dispositivo ha la propria sessione. Il token QR dura al massimo 5 minuti e viene cancellato quando il contatto viene aggiunto. Il cambio password e il recupero con le 12 parole chiudono tutte le sessioni.
I messaggi vengono recapitati in tempo reale tramite WebSocket con architettura Redis pub/sub: il server funge da relay cifrato e non accede mai al contenuto dei messaggi durante la trasmissione.
9. Auto-distruzione e controllo permanente dei dati
Gli utenti dispongono di due meccanismi indipendenti per la cancellazione automatica dei messaggi:
- Timer globale per chat: tutti i messaggi di una conversazione vengono eliminati dopo un intervallo configurabile (1 ora, 6 ore, 24 ore, 1 settimana, 2 settimane, 1 mese).
- Timer per singolo messaggio: applicabile a ogni messaggio individuale (10 secondi, 1 minuto, 1 ora, 24 ore, 7 giorni).
L'eliminazione è permanente e non reversibile: i dati vengono rimossi dal database senza possibilità di recupero, né da parte dell'utente né da parte di Orvhalis.
10. Messaggi vocali
L'accesso al microfono richiesto da Orvhalis per i messaggi vocali è gestito esclusivamente dal browser per la cattura tecnica dell'audio. Il contenuto registrato viene cifrato localmente sul tuo dispositivo prima di qualsiasi trasmissione e non transita mai in chiaro attraverso server di terze parti, inclusi i produttori del browser stesso.
11. Immagine del profilo
L'immagine del profilo non è cifrata end-to-end, come non lo sono alcuni dati che il server usa per mostrare elenchi: il titolo degli Eco; titolo, descrizione, luogo, data e messaggio di annullamento degli Eventi; il nome delle stanze; il messaggio facoltativo di una richiesta di contatto a distanza. Il contenuto dei messaggi, degli Eco e dei vocali è invece cifrato; degli Eventi è cifrato solo il vocale. Questi dati sono archiviati in chiaro, quindi tecnicamente leggibili da chi amministra l'infrastruttura. Le notifiche non li mostrano mai.
Per la foto la scelta è deliberata e il motivo è tecnico: cifrarla per ciascun contatto richiederebbe che il proprietario dell'immagine fosse connesso nel momento esatto in cui un nuovo contatto lo aggiunge, perché solo lui possiede la chiave. L'immagine comparirebbe con un ritardo imprevedibile, in cambio della riservatezza di un dato che per sua natura è destinato a essere mostrato ad altre persone.
L'accesso alla foto resta comunque limitato. L'immagine viene fornita soltanto agli utenti che ti hanno tra i propri nodi: non è raggiungibile da un indirizzo pubblico, non è indicizzabile e non viene mai inviata a chi non è un tuo contatto, incluse le chat temporanee aperte con persone esterne alla tua rete. Caricarla è facoltativo e può essere rimossa in qualsiasi momento dalla pagina Profilo, con cancellazione immediata dal server.
12. Cambio di dispositivo e recupero
L'identità cifrata dell'app viene salvata sul server, cifrata con chiavi derivate dalla tua password e dalle 12 parole. Se cambi dispositivo e inserisci la password o le 12 parole, l'identità si riapre e i tuoi contatti non vedono nessun cambio. Chiunque conosca la tua password o le 12 parole può fare lo stesso: custodiscile come una chiave. Per come funziona oggi, password e parole viaggiano al server quando vengono verificate (vedi §3), quindi la riservatezza di questa copia dipende anche dalla sicurezza del server in quei momenti. Se un contatto cambia dispositivo e il suo codice di sicurezza cambia, l'app ti avvisa: va accettato con «Accetta» (automatico solo per i contatti aggiunti a distanza e mai verificati).
Per segnalare vulnerabilità di sicurezza o richiedere informazioni tecniche sull'architettura contattare: orvhalis@gmail.com