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 in nessuna condizione.

• 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.

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.

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 derivazione avviene interamente sul dispositivo senza che la password raggiunga mai il server.
• 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.

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.

6. Nessun identificatore personale

Orvhalis non richiede email, numero di telefono, nome reale o qualsiasi altro dato personale identificativo. L'identità di ogni utente è un codice alfanumerico generato casualmente nel formato ID-XXXX-XXXX, costruito con un alfabeto privo di caratteri visivamente ambigui (esclusi 0, O, I, L, 1).

L'aggiunta di contatti avviene tramite QR code o dispositivo NFC: due utenti devono trovarsi in prossimità fisica o condividere esplicitamente il codice per entrare in contatto, eliminando qualsiasi possibilità di ricerca involontaria o non consensuale.

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

Non vengono raccolti dati di navigazione, fingerprint del dispositivo, indirizzo IP persistente, dati comportamentali o metriche di utilizzo.

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 con TTL di 24 ore; i token QR hanno TTL di 300 secondi e vengono consumati atomicamente (GETDEL) alla prima lettura.

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.