Chiavi di crittografia
Dove si trova la chiave di decrittazione?
Perché Collogue usa una password inserita separatamente invece di mettere la chiave nell’URL.
Pubblicato: 28 febbraio 2026
Limiti dell’implementazione attuale
Il client attuale cifra il testo nel browser e inserisce il contenuto cifrato nell’URL. La password condivisa separatamente non fa parte del link. Non esiste un server applicativo che memorizzi, recuperi, elimini o consumi i messaggi una sola volta.
Ulteriore contesto
La crittografia sostituisce un problema difficile con un altro.
Le chiavi sono piccole. Le loro conseguenze no.
Una chiave di cifratura simmetrica permette al browser del destinatario di trasformare il testo cifrato autenticato di nuovo in testo in chiaro.
``text https://collogue.net/m/example-message#example-key-material ``
Usa questo esempio solo se corrisponde all’architettura reale.
Il fragment è la parte di un URL che segue #.
``text https://example.test/message/123#key-material ``
``text /message/123 ``
Il browser conserva localmente #key-material e lo rende disponibile alla pagina caricata.
Ma contano tre avvertenze.
Primo, il JavaScript caricato dalla pagina può leggere il fragment. La decifratura lato browser richiede questo o un meccanismo equivalente.
Secondo, il link completo diventa una capacità. Chiunque lo ottenga può ricevere sia il riferimento al testo cifrato sia la chiave.
Terzo, i fragment possono comunque fuoriuscire attraverso il comportamento umano, screenshot, testo copiato, estensioni del browser, cronologia degli appunti, strumenti di sincronizzazione o codice client modificato.
Un fragment è un confine di protocollo utile. Non è un campo di forza.
- log di accesso;
- log del reverse proxy;
- cronologia del browser;
- diagnostica copiata;
- dati del referrer, a seconda della policy e della navigazione;
- sistemi di monitoraggio.
In quel caso, l’articolo pubblico deve spiegare l’esposizione reale invece di descrivere il comportamento dei fragment.
Una passphrase memorabile e una chiave uniformemente casuale non sono intercambiabili. I parametri di derivazione contano.
Gli utenti a volte presumono che un link cifrato sia sicuro da pubblicare perché «contiene solo dati cifrati».
Questa conclusione è errata quando il link fornisce anche la capacità di decifrare.
- issue tracker pubblici;
- canali condivisi con membri non necessari;
- servizi di analisi degli URL;
- abbreviazioni URL pubbliche;
- documenti con accesso ampio.
Il possesso del link può dimostrare che qualcuno possiede il link. Non stabilisce necessariamente l’identità.
Se un attaccante ottiene l’URL prima del destinatario previsto, la crittografia può funzionare perfettamente per l’attaccante.
Questa è la lezione ricorrente delle capacità di tipo bearer: l’autorizzazione è rappresentata dal possesso.
Per i segreti a rischio più elevato, verifica il destinatario e considera un canale separato per il contesto o un’autenticazione aggiuntiva. Non descrivere i canali separati come automaticamente sicuri; cambiano solo i requisiti dell’attacco.
- il mittente condivide il link sbagliato;
- il destinatario lo inoltra;
- il malware del browser legge il fragment;
- uno script malevolo della pagina cattura il testo in chiaro;
- la cronologia degli appunti conserva l’URL;
- uno scanner dei link richiede la pagina;
- il destinatario salva il messaggio decifrato.
Può essere un design utile perché il fragment normalmente non viene inviato nelle richieste HTTP. La sicurezza dipende comunque dalla pagina distribuita, dall’ambiente del browser, dalla gestione del link e dal comportamento del destinatario.
Sì. Il JavaScript eseguito sulla pagina può accedere al fragment. È spesso così che la decifratura lato client ottiene il materiale della chiave.
Se Collogue non conserva né deriva la chiave, perdere il materiale necessario del link può rendere il messaggio irrecuperabile. Conferma l’implementazione prima di pubblicare questa affermazione.