Cifratura end-to-end con Signal Protocol e AES-256 ovunque
SANKET (Sanket.Chat) di Tosh Defence cifra da un'estremità all'altra ogni messaggio, reazione e comunicazione a più destinatari cifrata tramite Signal Protocol e la libreria ufficiale libsignal di Signal, sottoposta a verifica indipendente, utilizzando l'accordo sulle chiavi PQXDH e Double Ratchet con SPQR. File, fotogrammi delle chiamate, trasporto delle chiamate, archiviazione locale e ogni sessione TLS terminata dall'installazione usano AES-256, senza ripiego su AES-128 né modalità di compatibilità.
AES-256 o l'operazione non viene eseguita: questa è la politica di progettazione di Sanket, applicata nel codice. Se la crittografia non può essere eseguita esattamente come previsto, l'operazione viene rifiutata anziché ricorrere a una protezione più debole.
Messaggi: Signal Protocol, senza modifiche
SANKET usa la libreria ufficiale libsignal di Signal per cifrare tutti i messaggi, con la stessa versione su iOS, Android, sistemi da scrivania e serventi. Non contiene alcuna reimplementazione di Signal Protocol né un algoritmo alternativo di cifratura dei messaggi.
Le sessioni vengono stabilite con PQXDH, l'estensione post-quantistica di X3DH, che combina accordi sulle chiavi X25519 con un incapsulamento Kyber. I messaggi vengono quindi cifrati con Double Ratchet: dalla chiave di ciascun messaggio si derivano una chiave AES-256, una chiave HMAC-SHA256 e un IV; il messaggio viene cifrato con AES-256 e autenticato con HMAC-SHA256, poi la chiave viene eliminata dopo l'uso. Lo Sparse Post-Quantum Ratchet di Signal opera in parallelo per ogni sessione.
Nessun meccanismo alternativo, per scelta progettuale
Un client rifiuta di inviare il messaggio se non è possibile cifrarlo con libsignal. I dispositivi che non pubblicano una chiave di identità libsignal vengono esclusi dall'invio anziché ricevere il messaggio in chiaro; i contrassegni preesistenti per il testo in chiaro vengono rifiutati e il server rifiuta i pacchetti di chiavi non conformi al formato libsignal. Non è previsto alcun percorso per trasmettere il contenuto dei messaggi in chiaro o con una cifratura alternativa.
Gruppi senza chiave condivisa
I messaggi di gruppo sono cifrati mediante distribuzione individuale a coppie: il dispositivo mittente cifra il messaggio separatamente per ogni dispositivo attendibile di ogni membro, ciascuno tramite la propria sessione libsignal. Le modifiche ai membri non richiedono la rigenerazione delle chiavi e un membro rimosso viene semplicemente escluso dall'elenco dei destinatari.
Prima di cifrare, il mittente verifica l'elenco dei dispositivi di ogni account destinatario, firmato con la chiave dell'account stesso, e non invia nulla ai dispositivi che non vi figurano.
File e chiamate
Il contenuto, i nomi e i tipi degli allegati vengono crittografati sul dispositivo con AES-256-GCM usando una chiave casuale a 256 bit per ciascun file; la chiave viene trasmessa all'interno del messaggio libsignal.
Voce e video sono protetti due volte. I fotogrammi di ogni partecipante sono cifrati end-to-end con AES-256-GCM mediante una chiave specifica per ciascun mittente che cambia ogni 200 millisecondi, producendo cinque nuove chiavi per i fotogrammi al secondo per ciascun mittente, con una nuova chiave casuale ogni volta che qualcuno entra o esce. Tra ciascun dispositivo e il server multimediale, SRTP accetta solo AEAD_AES_256_GCM. Il server multimediale inoltra fotogrammi cifrati che non può decifrare e l'architettura esclude la registrazione delle chiamate sul server.
- AES-256-GCM per ogni file
- Chiavi di chiamata per ciascun mittente, mai una chiave condivisa per la stanza
- Cinque chiavi per fotogramma al secondo per mittente
- Solo SRTP con AES-256-GCM
Trasmissione e archiviazione
Ogni connessione tra client utilizza TLS 1.3 con TLS_AES_256_GCM_SHA384 oppure, per gli stack di rete delle piattaforme che lo richiedono, TLS 1.2 con ECDHE e AES-256-GCM. AES-128, ChaCha20, le suite in modalità CBC e RSA statico sono esclusi; il gruppo ibrido post-quantistico X25519MLKEM768 viene proposto per primo. Ogni dispositivo approvato può inoltre autenticarsi con il proprio certificato client tramite TLS reciproco.
Sui dispositivi, i database locali sono cifrati con AES-256 e autenticati con HMAC-SHA256; sui telefoni, l'archivio del protocollo e i segreti del dispositivo sono cifrati con una chiave protetta dall'hardware nel Secure Enclave, in StrongBox o nell'ambiente di esecuzione attendibile.
Evidenze tecniche
Leggi i dettagli nel documento tecnico di SANKET
Ogni affermazione contenuta in questa pagina è esposta per esteso nel documento tecnico pubblico sulla sicurezza e sull'architettura di SANKET, consultabile gratuitamente senza registrazione.
Sanket usa Signal Protocol?
Sì. SANKET cifra tutti i messaggi con la libreria ufficiale libsignal di Signal su ogni piattaforma, usando lo scambio di chiavi PQXDH e Double Ratchet con SPQR. Non contiene alcuna reimplementazione del protocollo.
La messaggistica di SANKET è cifrata con AES-256?
Sì. I messaggi usano AES-256-CBC con HMAC-SHA256 all'interno di libsignal; file, fotogrammi delle chiamate, trasporto delle chiamate, archiviazione locale e TLS usano AES-256-GCM. Non è previsto alcun ripiego su AES-128.
Le chiamate vocali e video sono crittografate end-to-end?
Sì. I pacchetti delle chiamate sono cifrati end-to-end con AES-256-GCM mediante chiavi distinte per ciascun mittente, distribuite tramite libsignal, con 5 nuove chiavi per i pacchetti al secondo per ogni mittente, all'interno di SRTP che accetta solo AES-256-GCM.
Le reazioni e i messaggi di diffusione sono cifrati?
Sì. Le reazioni e le comunicazioni cifrate a più destinatari sono messaggi libsignal, cifrati end-to-end come tutti gli altri messaggi. Anche la priorità, il termine e la scadenza di una comunicazione sono inclusi nella cifratura.
Sanket usa le chiavi del mittente per i gruppi?
No. SANKET cifra i messaggi di gruppo separatamente per ogni dispositivo attendibile di ogni membro, ciascuno tramite una propria sessione libsignal, quindi non esiste una chiave di gruppo condivisa.
Quali versioni di TLS accetta Sanket?
È preferito TLS 1.3, esclusivamente con TLS_AES_256_GCM_SHA384. TLS 1.2 è accettato solo con ECDHE e AES-256-GCM. Non sono accettate versioni precedenti a TLS 1.2 e lo scambio di chiavi post-quantistico ibrido X25519MLKEM768 è proposto come prima opzione.
libsignal è stata sottoposta a verifica indipendente?
Sì. SANKET si basa sulla libreria libsignal di Signal, sottoposta a verifiche indipendenti, e il protocollo PQXDH è stato analizzato formalmente.
Esaminate la crittografia di Sanket insieme ai nostri ingegneri
Tosh Defence accompagna gli architetti della sicurezza e i comitati di valutazione nell'esame della progettazione crittografica, livello per livello, mettendo a disposizione la versione ad accesso controllato del documento tecnico previo accordo di riservatezza.