È stato rilasciato Ad Nihilum 0.4.3 — un servizio minimalista per lo scambio di messaggi crittografati secondo il principio 'ho letto — ho distrutto', concepito principalmente per il self-hosting.
Il server funge solo da un deposito cieco. La crittografia e la decrittografia avvengono esclusivamente dalla parte del cliente, nel browser (tramite AES-GCM).
Caratteristiche
- crittografia e decrittografia locali, un server non vede mai la chiave;
- supporto per uno strato aggiuntivo di crittografia con password, di cui (1) il server non può venire a conoscenza, (2) non può essere dedotto dal link trasmesso;
- il progetto contiene circa 2200 righe di codice server in C e 600 righe di codice client in JS, il che facilita l'audit;
- Ad Nihilum dipende solo da libmicrohttpd. Per la generazione dei codici QR viene fornita una versione modificata di QRCode.js;
- è inclusa una guida per l'installazione rapida del servizio locale senza un IP esterno;
- Ad Nihilum funziona anche su Android, con un corrispondente script per la compilazione in Termux;
- server a thread singolo e sincrono.
Modifiche
Ridisegno sostanziale
- Sparate le pagine di invio e ricezione dei messaggi, il corrispondente codice client.
- In generale, il design è stato notevolmente modificato e adattato in base ai feedback degli utenti.
- Clienti "Semplici" e locali:
- le pagine client possono essere salvate localmente e utilizzate da file://.
Politiche del browser
- implementato CSP per combattere gli XSS;
- il server invia HSTS.
Altre modifiche
- il progetto è stato rinominato da Epha-ots;
- acquistato il dominio adnihilum.net;
- TLS è garantito tramite Let's Encrypt, è importante tenerlo a mente (non ci sono fondi);
- semplificato il lavoro con i file;
- passaggio a fat-pointer;
- risolti problemi minori;
- auto-jsminify e assemblaggio dei file client durante la compilazione tramite CMake.
Panoramica del protocollo
Generare tre valori casuali: chiave K, vettore di inizializzazione N e sale S. K — 256 bit, N — 96 bit, S — 128 bit.
Visualizza ID di K e S con HKDF basato su SHA-256.
Formare una stringa di dati aggiuntivi autenticati aad — è semplicemente una stringa del tipo: id=ID
Se l'utente ha impostato una password:
- mostrare Pk dalla password e S utilizzando PBKDF2, SHA-256, 800000 iterazioni;
- la stessa sale è utilizzata per tutto;
- cifrare i dati con AES-GCM, utilizzando la chiave Pk, IV/nonce N e passare aad.
Aggiungere un tag di due byte ai dati già cifrati, se c'era una password, oppure ai dati originali, se non c'era.
Il primo byte ha un valore: indica se i dati sono stati cifrati con una password:
- 0x73 — i dati sono crittografati con una password;
- 0x13 — i dati non sono crittografati con una password.
Il secondo byte è un valore costante 0x37.
Crittografare nuovamente il risultato utilizzando AES-GCM, mantenendo lo stesso iv = N e lo stesso aad. Questo produce il testo crittografato finale ct.
Unire i byte in una stringa: blob = N .. S .. ct
Inviare blob al server insieme a ID. Il server restituisce blob attraverso questo ID e non può essere sostituito: il client verifica prima ID con l'uso di N e K prima della decifratura, e poi attraverso aad.
Il client memorizza K. K che non viene mai inviato al server. Pk non viene inviato; tutto ciò che è legato alla password viene rimosso dalla memoria.
Il client crea un link: origin/#ID/K
Qui ID e K — stringhe in formato base64url.
Quando il destinatario apre il link:
- il browser ignora tutto ciò che inizia con #; questo si chiama location.hash;
- l'applicazione client viene caricata dal server;
- secondo me, questa è la principale vulnerabilità: ci troviamo nuovamente di fronte al fatto che "TLS è vulnerabile";
- tuttavia, nulla impedisce di mantenere il client offline;
- idealmente dovrebbe esserci un client standalone separato.
Il JavaScript client controlla location.hash, e se è presente ID e K, carica i dati dal server.
Quindi li verifica, li decifra e, se necessario, richiede la password e li decifra nuovamente.
Licenza
Il progetto è distribuito con GPLv3.
Fonte: linux.org.ru
