Crittografia
Come Collogue cifra un messaggio privato
Una spiegazione concisa del flusso di crittografia verificato lato browser usato da Collogue.
Pubblicato: 17 febbraio 2026
Limiti dell’implementazione attuale
Gli attuali link Collogue contengono il contenuto cifrato nell’URL. Il browser utilizza la Web Crypto API: PBKDF2-SHA-256 con 310.000 iterazioni deriva una chiave AES-GCM da 256 bit dalla password inserita separatamente, usando un salt casuale di 16 byte e un IV di 12 byte. Il client attuale non invia richieste a un’API dell’applicazione per creare, recuperare o memorizzare messaggi.
La password non è codificata nel link. L’implementazione non offre visualizzazione monouso, eliminazione lato server o un timer di scadenza. Considera sensibile il link completo e condividi la password tramite un canale separato.
Ulteriore contesto
L’idea è semplice. I problemi interessanti iniziano quando la si implementa correttamente.
Un messaggio inizia come testo leggibile nel browser del mittente.
- l’utente;
- il browser;
- gli script della pagina;
- le estensioni del browser con accesso sufficiente;
- il malware sul dispositivo;
- i sistemi di accessibilità e input.
Non è un difetto esclusivo di Collogue. Un segreto deve esistere da qualche parte in forma leggibile prima di poter essere cifrato.
Una chiave crittografica dovrebbe provenire da una fonte crittograficamente sicura o da un processo di derivazione documentato. La casualità dall’aspetto umano non basta. Un timestamp con punteggiatura decorativa resta un timestamp.
Se è coinvolta una passphrase, l’implementazione deve usare una funzione di derivazione della chiave e parametri appropriati. Se viene generata una chiave casuale, occorre documentare la lunghezza e la fonte di generazione.
- Riservatezza — il testo cifrato non rivela il testo in chiaro senza la chiave.
- Integrità — le modifiche non autorizzate vengono rilevate durante la decifrazione.
La pagina pubblica dovrebbe indicare la costruzione esatta solo dopo la verifica del codice. “AES” da solo non è una descrizione completa. Modalità, nonce, tag di autenticazione, dimensioni delle chiavi, codifica e gestione degli errori sono importanti.
Le API crittografiche sono famose per offrire strumenti affilati con impugnature realizzate professionalmente. Il loro uso corretto fa parte del design.
La forma sicura attesa, se il codice effettivo la supporta, è una richiesta contenente testo cifrato e impostazioni operative invece del testo leggibile del messaggio.
Ispeziona il pannello di rete del browser. Non dedurre questa proprietà dai testi dell’interfaccia.
Questi valori non sono automaticamente segreti. Alcuni sono necessari per la decifrazione e possono accompagnare in sicurezza il testo cifrato. La chiave è la distinzione fondamentale.
Un link sicuro non è necessariamente metadato innocuo. Se il possesso del link completo consente la decifrazione, il link è una capacità del detentore: chiunque lo possieda potrebbe aprire il messaggio.
Per questo il link va trattato con una cura simile a quella riservata al segreto durante la sua breve vita.
Il dettaglio conta perché i sistemi automatizzati possono richiedere i link. Una semplice richiesta GET è più facile da attivare per un bot di anteprima rispetto a un’azione umana esplicita, anche se nessun meccanismo dimostra perfettamente la presenza di una persona.
Il browser del destinatario riceve il testo cifrato e il materiale necessario per la chiave, poi esegue una decifrazione autenticata.
Se l’autenticazione fallisce, l’applicazione dovrebbe segnalare che il messaggio non è stato verificato o decifrato. Non dovrebbe mostrare testo corrotto come se non fosse successo nulla.
Una decifrazione riuscita crea testo in chiaro nel browser del destinatario. Da quel momento la crittografia non può impedire che copie, schermate, fotografie o un dispositivo infetto catturino il messaggio.
La cifratura protegge un percorso. Non può governare il comportamento futuro del destinatario.
Una buona pagina sulla privacy indica il limite invece di sostituirlo con “scomparso per sempre”.
La conclusione corretta non è il pessimismo, ma la precisione.
Collogue dovrebbe fare una promessa limitata, sostenerla con comportamenti osservabili e spiegare le ipotesi. È più utile che aggiungere una grande icona di lucchetto a un piccolo paragrafo.
No. Generazione sicura delle chiavi, cifratura autenticata, nonce unici quando necessari, codifica corretta, controlli di integrità e gestione sicura degli errori fanno tutti parte del protocollo.
Perché la decifrazione deve produrre testo leggibile sul dispositivo del destinatario. La crittografia può controllare l’accesso prima di quel momento, non il comportamento successivo del destinatario.
Crea un link privato Collogue quando devi inviare una password, un token, un codice di recupero o un altro valore sensibile breve.