Cum criptează Transferify fișierele în browserul tău
Fiecare fișier pe care îl trimiți cu Transferify e criptat în browserul tău înainte ca vreun octet din el să plece de pe dispozitiv. Cifrul e AES-256-GCM, rulat de Web Crypto API, interfața de criptografie integrată în browserul tău, iar cheia e creată pe dispozitivul tău pentru fiecare transfer. Modurile de trimitere diferă printr-un singur lucru: unde ajunge cheia după aceea.
Articolul acesta explică mecanismul pentru cititorii care vor să îl verifice: cum se creează cheia, cum e tăiat și sigilat un fișier, ce împiedică modificarea unui fișier stocat și cine îl poate debloca în fiecare mod.
Cheia e creată pe dispozitivul tău
Când pornești un transfer, browserul tău îi cere lui Web Crypto API o cheie AES nouă, aleatorie, de 256 de biți. O singură cheie acoperă toate fișierele pe care le trimiți împreună. Fișierele pe care le adaugi mai târziu la un transfer găzduit primesc o cheie nouă, a lor.
Cheia nu e derivată din adresa ta de e-mail, din contul tău sau dintr-o parolă, așa că nimic despre tine nu poate fi folosit ca să fie ghicită.
Fișierele sunt criptate ca flux, pe bucăți
Browserul tău citește fiecare fișier ca flux și îl criptează bucată cu bucată, așa că un fișier mult mai mare decât memoria dispozitivului se criptează fără să fie încărcat întreg în memorie.
- Transferurile găzduite folosesc bucăți de 8 MiB pentru majoritatea fișierelor.
- Fișierele găzduite foarte mari folosesc o bucată mai mare, un multiplu întreg de 8 MiB de până la 256 MiB, ca fișierul să încapă în limita stocării de 10.000 de părți pe fișier.
- Transferurile peer-to-peer folosesc implicit bucăți de 32 KiB, ca fiecare bucată criptată să încapă într-un singur mesaj de canal de date pe care îl acceptă orice partener WebRTC.
Fiecare bucată e sigilată cu AES-256-GCM, care o criptează și îi adaugă o etichetă de autentificare de 16 octeți. Dacă se schimbă un singur bit din bucată, eticheta nu mai corespunde, iar decriptarea refuză bucata.
Fiecare bucată e legată de locul ei
Criptarea bucăților una câte una lasă o breșă dacă nimic nu leagă fiecare bucată de poziția ei: cine deține copia stocată ar putea reordona bucățile, ar putea scoate ultima bucată sau ar putea strecura o bucată din alt fișier. Două lucruri închid breșa.
Un nonce unic pentru fiecare bucată. AES-GCM are nevoie de un nonce, un număr folosit o singură dată, pentru fiecare bucată pe care o sigilează. Fluxul criptat al fiecărui fișier începe cu o valoare de 8 octeți pe care browserul tău o alege pentru acel fișier și o scrie în antetul fluxului, iar fiecare bucată îi adaugă propriul contor de 4 octeți. În cadrul unui fișier, două bucăți nu au niciodată același nonce. Între fișiere, valorile de 8 octeți sunt aleatorii sau derivate dintr-un secret pe care îl ține browserul tău, așa că o repetare e extrem de improbabilă. Reutilizarea unui nonce cu aceeași cheie e singurul lucru pe care AES-GCM nu trebuie să îl facă niciodată.
Date de poziție autentificate. Fiecare bucată e sigilată împreună cu o descriere scurtă care numește transferul, fișierul, indexul bucății și dacă e ultima bucată a fișierului. Descrierea nu e stocată cu bucata. Browserul destinatarului o reconstruiește pentru fișierul pe care l-a cerut, așa că o bucată se decriptează doar exact în locul pentru care a fost sigilată.
| Dacă copia stocată ar fi... | Ce se întâmplă la descărcare |
|---|---|
| Modificată chiar și cu un singur bit | Bucata respectivă nu trece de verificarea etichetei, iar descărcarea se oprește |
| Reordonată | Indexul bucății nu corespunde, așa că verificarea eșuează |
| Cu o bucată înlocuită de una din alt fișier sau alt transfer | Fișierul sau transferul din descriere nu corespunde, așa că verificarea eșuează |
| Scurtată | Noua ultimă bucată a fost sigilată ca „nu e ultima”, așa că verificarea eșuează |
| Prelungită cu date în plus | Adevărata ultimă bucată nu mai e ultima, așa că verificarea eșuează |
| Raportată cu altă dimensiune | Dimensiunea decriptată e comparată cu dimensiunea anunțată la descărcare, așa că verificarea eșuează |
O verificare eșuată oprește descărcarea și renunță la ce se scria, așa că destinatarul primește fișierul exact sau o eroare, niciodată o copie deteriorată pe tăcute.
Browserele expeditorilor scriu această descriere din octombrie 2026. Fișierele stocate înainte de atunci au o descriere mai veche, care numește doar transferul și indexul bucății, iar browserele destinatarilor le citesc în continuare.
Unde ajunge cheia: trei cazuri
Fișierul e criptat la fel în toate cazurile. Diferă doar felul în care destinatarul primește cheia.
| Ce comparăm | Găzduit, implicit | Găzduit, Zero-Knowledge | Peer-to-peer |
|---|---|---|---|
| Cum ajunge cheia la destinatar | Împachetată și stocată de noi, despachetată de serviciul nostru când se deschide linkul | Doar în link, după „#” | Doar în link, după „#” |
| Ce stocăm | Fișierul criptat și cheia, împachetată cu o cheie din AWS Key Management Service | Doar fișierul criptat | Nimic: fișierul nu este stocat niciodată pe serverele noastre |
| Cine altcineva poate obține cheia | Serviciul nostru, prin serviciul de gestionare a cheilor | Nimeni | Nimeni |
| Poate Transferify să decripteze fișierul? | Da, tehnic | Nu | Nu |
Găzduit, modul implicit: cheia e împachetată pentru serviciul nostru
În modul implicit, browserul tău împachetează cheia fișierului înainte să fie trimis ceva. O criptează cu RSA-OAEP (SHA-256) cu jumătatea publică a unei perechi de chei RSA de 3072 de biți, a cărei jumătate privată e ținută în AWS Key Management Service (KMS). Cheia brută nu face parte din nicio cerere. Stocăm cheia împachetată în înregistrarea fișierului.
Când un destinatar deschide linkul, serviciul nostru verifică mai întâi că linkul nu a expirat și că parola e corectă, dacă ai setat una. Abia apoi îi cere lui KMS să despacheteze cheia și o trimite browserului destinatarului prin HTTPS. Browserul destinatarului face decriptarea. Serviciul nostru nu decriptează conținutul fișierelor.
Așadar, în acest mod suntem tehnic capabili să decriptăm un fișier găzduit, și o spunem. În schimb primești un link scurt, fără cheie în el, un link pe care îl poți copia din nou din lista transferurilor tale și linkuri pe care serviciul nostru le poate trimite pe e-mail destinatarilor tăi. O parolă setată în acest mod e trimisă serviciului nostru, e stocată doar ca hash și e verificată înainte ca cheia să fie eliberată.
Găzduit, modul Zero-Knowledge: cheia rămâne în link
Cu modul Zero-Knowledge, browserul tău nu trimite niciun material de cheie. Cheia intră în linkul de partajare, după semnul „#”. Browserele nu trimit acea parte a unei adrese când cer o pagină, așa că serverele noastre nu o primesc niciodată. Pagina destinatarului citește cheia din link, o șterge imediat din bara de adrese și decriptează descărcarea pe dispozitivul destinatarului.
Dacă setezi și o parolă, linkul conține o cheie împachetată în locul celei brute. Browserul tău derivă din parolă o cheie de împachetare cu PBKDF2 (SHA-256, 600.000 de iterații, o sare aleatorie de 16 octeți) și sigilează cu ea cheia fișierului. Browserul destinatarului repetă pașii cu parola pe care o tastează. Parola și cheia brută nu ajung niciodată la noi, iar o parolă greșită pur și simplu nu reușește să despacheteze cheia pe dispozitivul destinatarului.
Pentru că cheia există doar în link, serviciul nostru nu poate trimite pe e-mail un link Zero-Knowledge destinatarilor tăi: e-mailul ar conține un link fără cheie. Un link Zero-Knowledge îl partajezi tu, pe un canal în care ai încredere.
Peer-to-peer: criptat de două ori
Un transfer peer-to-peer nu este stocat niciodată pe serverele noastre. Browserul tău creează totuși o cheie pentru fiecare transfer instant, o pune după „#” în link și sigilează cu ea fiecare bucată înainte ca bucata să intre în conexiunea WebRTC. Conexiunea e criptată și ea, cu DTLS. Motivul celui de-al doilea strat e explicat în cum funcționează un transfer peer-to-peer.
Ce acoperă criptarea și ce nu
Criptarea protejează conținutul fișierelor tale. Ce prelucrează serviciul nostru ca să ruleze un transfer e descris în Politica de confidențialitate.
Încă două limite merită spuse direct:
- Un link funcționează pentru oricine îl are, așa că partajează-l doar acolo unde ai partaja și fișierul, iar o eventuală parolă trimite-o pe alt canal.
- Criptarea în browser nu poate proteja un fișier pe un dispozitiv deja compromis, la niciunul dintre capete.
Încearcă
Criptarea rulează la fiecare transfer, pe orice plan, fără nimic de configurat. Trimite un fișier acum și cheia e creată în browserul tău chiar în momentul în care pornești.
Întrebări frecvente
Fișierele mele sunt criptate înainte să plece de pe dispozitiv?
Da. Fiecare fișier găzduit și fiecare fișier peer-to-peer e criptat în browserul tău cu AES-256-GCM înainte să fie trimis vreun octet din el, pe orice plan. Nu există nicio cale de a trimite un fișier necriptat.
Poate Transferify să îmi decripteze fișierele?
În modul găzduit implicit, tehnic, da. Păstrăm cheia fișierului împachetată cu o cheie ținută în AWS Key Management Service, iar când un destinatar deschide linkul, serviciul nostru o despachetează și o predă browserului lui. Așa poate funcționa un link scurt, fără cheie în el. În modul Zero-Knowledge și la transferurile peer-to-peer, cheia călătorește doar în partea linkului de după „#”, pe care browserele nu o trimit serverelor, așa că nu o primim niciodată.
Ce se întâmplă dacă cineva modifică fișierul stocat?
Descărcarea eșuează, în loc să producă un fișier deteriorat. Fiecare bucată are o etichetă de autentificare legată de poziția ei, de fișierul ei și de transferul ei, așa că un fișier modificat, reordonat, cu bucăți înlocuite sau scurtat nu se decriptează.