Come Transferify cifra i file nel browser

2026-10-30·Il team di Transferify

Ogni file inviato con Transferify viene cifrato nel browser prima che qualsiasi suo byte lasci il dispositivo. Il cifrario è AES-256-GCM, eseguito dall’API Web Crypto integrata nel browser, e la chiave viene creata sul dispositivo per ogni trasferimento. Le modalità di invio differiscono in una cosa sola: dove va a finire la chiave in seguito.

Questo articolo spiega il meccanismo per i lettori che desiderano verificarlo: come nasce la chiave, come un file viene tagliato e sigillato, che cosa impedisce di alterare un file archiviato e chi può sbloccarlo in ciascuna modalità.

La chiave nasce sul dispositivo

Quando si avvia un trasferimento, il browser chiede all’API Web Crypto una nuova chiave AES casuale a 256 bit. Una sola chiave copre tutti i file inviati insieme. I file aggiunti più tardi a un trasferimento ospitato ricevono una nuova chiave propria.

La chiave non deriva dall’indirizzo e-mail, dall’account o da una password, perciò nulla che La riguardi può servire a indovinarla.

I file vengono cifrati come flusso, in blocchi

Il browser legge ogni file come flusso e lo cifra pezzo per pezzo, così un file molto più grande della memoria del dispositivo viene cifrato senza essere caricato per intero.

• I trasferimenti ospitati usano blocchi da 8 MiB per la maggior parte dei file.
• I file ospitati molto grandi usano un blocco maggiore, un multiplo intero di 8 MiB fino a 256 MiB, in modo che il file rientri comunque nel limite dello storage di 10.000 parti per file.
• I trasferimenti peer-to-peer usano per impostazione predefinita blocchi da 32 KiB, così ogni blocco cifrato sta in un solo messaggio del canale dati che ogni peer WebRTC accetta.

Ogni blocco viene sigillato con AES-256-GCM, che lo cifra e aggiunge un tag di autenticazione di 16 byte. Se cambia un solo bit del blocco, il tag non corrisponde più e la decifratura rifiuta il blocco.

Ogni blocco è legato al proprio posto

Cifrare i blocchi uno per uno lascia una lacuna se nulla lega ogni blocco alla sua posizione: chi possiede la copia archiviata potrebbe riordinare i blocchi, eliminare l’ultimo o inserire un blocco di un altro file. Due elementi chiudono questa lacuna.

Un nonce unico per ogni blocco. AES-GCM richiede un nonce, un numero usato una sola volta, per ogni blocco che sigilla. Il flusso cifrato di ogni file comincia con un valore di 8 byte che il browser sceglie per quel file e scrive nell’intestazione del flusso, e ogni blocco vi aggiunge il proprio contatore di 4 byte. All’interno di un file, nessun blocco condivide un nonce con un altro. Tra file diversi, i valori di 8 byte sono casuali, oppure derivati da un segreto che il browser conserva, quindi una ripetizione è estremamente improbabile. Riutilizzare un nonce con la stessa chiave è l’unica cosa che AES-GCM non deve mai fare.

Dati di posizione autenticati. Ogni blocco viene sigillato insieme a una breve etichetta che indica il trasferimento, il file, l’indice del blocco e se si tratta dell’ultimo blocco del file. L’etichetta non viene archiviata con il blocco. Il browser del destinatario la ricostruisce per il file richiesto, perciò un blocco si decifra solo nel punto esatto per cui è stato sigillato.

Un controllo fallito interrompe il download e scarta ciò che si stava scrivendo, perciò un destinatario ottiene il file esatto oppure un errore, mai una copia silenziosamente danneggiata.

I browser dei mittenti scrivono questa etichetta da ottobre 2026. I file archiviati prima portano un’etichetta precedente che indica soltanto il trasferimento e l’indice del blocco, e i browser dei destinatari continuano a leggerli.

Dove va la chiave: tre casi

Il file viene cifrato allo stesso modo in ogni caso. Cambia il modo in cui il destinatario ottiene la chiave.

Ospitato, modalità predefinita: la chiave è avvolta per il nostro servizio

Nella modalità predefinita, il browser avvolge la chiave del file prima che venga inviato qualsiasi dato. Cifra la chiave con RSA-OAEP (SHA-256) usando la metà pubblica di una coppia di chiavi RSA a 3072 bit, la cui metà privata è custodita in AWS Key Management Service (KMS). La chiave in chiaro non fa mai parte di alcuna richiesta. Archiviamo la chiave avvolta insieme al record del file.

Quando un destinatario apre il link, il nostro servizio verifica prima che il link non sia scaduto e che la password sia corretta, se Lei ne ha impostata una. Solo allora chiede a KMS di sbloccare la chiave e la restituisce al browser del destinatario tramite HTTPS. La decifratura la esegue il browser del destinatario. Il nostro servizio non decifra il contenuto dei file.

Quindi, in questa modalità, siamo tecnicamente in grado di decifrare un file ospitato, e lo diciamo. In cambio si ottiene un link breve senza la chiave al suo interno, un link che si può copiare di nuovo dall’elenco dei trasferimenti, e link che il nostro servizio può inviare per e-mail ai destinatari. Una password impostata in questa modalità viene inviata al nostro servizio, archiviata solo come hash e controllata prima che la chiave venga rilasciata.

Ospitato, modalità Zero-Knowledge: la chiave resta nel link

Con la modalità Zero-Knowledge, il browser non invia alcun materiale della chiave. La chiave finisce nel link di condivisione dopo il simbolo «#». I browser non inviano quella parte di un indirizzo quando richiedono una pagina, perciò i nostri server non la ricevono mai. La pagina del destinatario legge la chiave dal link, la rimuove subito dalla barra degli indirizzi e decifra il download sul dispositivo del destinatario.

Se Lei imposta anche una password, il link contiene una chiave avvolta invece di quella in chiaro. Il browser deriva dalla password una chiave di avvolgimento con PBKDF2 (SHA-256, 600.000 iterazioni, un salt casuale di 16 byte) e sigilla con essa la chiave del file. Il browser del destinatario ripete l’operazione con la password digitata. La password e la chiave in chiaro non ci raggiungono mai, e una password errata semplicemente non riesce a sbloccare la chiave sul dispositivo del destinatario.

Poiché la chiave esiste solo nel link, il nostro servizio non può inviare per e-mail un link Zero-Knowledge ai destinatari: l’e-mail conterrebbe un link senza la sua chiave. Un link Zero-Knowledge lo condivide Lei stesso, attraverso un canale di cui si fida.

Peer-to-peer: cifrato due volte

Un trasferimento peer-to-peer non viene mai archiviato sui nostri server. Il browser crea comunque una chiave per ogni trasferimento istantaneo, la colloca dopo il «#» nel link e sigilla con essa ogni blocco prima che entri nella connessione WebRTC. Quella connessione è a sua volta cifrata con DTLS. Il motivo del secondo strato è spiegato in come funziona un trasferimento peer-to-peer.

Che cosa copre la cifratura e che cosa no

La cifratura protegge il contenuto dei file. Ciò che il nostro servizio elabora per eseguire un trasferimento è indicato nella nostra Informativa sulla privacy.

Vale la pena dichiarare apertamente altri due limiti:

• Un link funziona per chiunque lo possieda, perciò lo condivida solo dove condividerebbe il file e invii l’eventuale password attraverso un canale diverso.
• La cifratura nel browser non può proteggere un file su un dispositivo già compromesso, a una qualsiasi delle due estremità.

Provare

La cifratura viene eseguita a ogni trasferimento, con qualsiasi piano, senza nulla da configurare. Invii un file ora e la chiave nasce nel browser nel momento in cui comincia.