Revault krypterer en stor fil i segmenter på cirka 5 MiB, hver med sit eget autentificeringstag, så hele filen aldrig behøver at ligge i hukommelsen på én gang. I webappen er det det, der giver plads til filer på op til 1 GiB.
Hvorfor ikke kryptere hele filen på én gang?
Store filer bør ikke kræve store mængder hukommelse. Revault læser filer i segmenter på cirka 5 MiB, krypterer hvert segment i browseren og mellemlagrer chiffertekst i IndexedDB. Den oprindelige fil læses aldrig ind i én kæmpe buffer.
Arbejdet i segmenter betyder også, at en afbrudt upload kan fortsætte fra chiffertekst, der allerede er klargjort, i stedet for at kryptere hele filen igen.
Hvad beskytter segmenternes rækkefølge og fuldstændighed?
Hver fil får sin egen krypteringsnøgle, afledt med HKDF fra pengeskabets hovednøgle. Afledningskonteksten omfatter pengeskabets og filens identifikatorer, filens længde i bytes og segmentstørrelsen.
Hvert segments 12-byte-nonce kombinerer et tilfældigt præfiks valgt til den fil, en segmenttæller på fire byte og et flag, der markerer det sidste segment. Segmenter bærer 128-bit GCM-tags. Hvis segmenter byttes om, ændres eller afkortes, mislykkes verificeringen.
Hvad sker der, hvis en upload afbrydes?
Når krypteringen er færdig, kan netværksuploads genoptages fra cachet chiffertekst efter en sideopdatering. Nye forsøg sender de samme krypterede bytes i stedet for at kryptere en ny kilde under gamle nonces. Hvis selve krypteringen afbrydes, skal du annullere den ufuldstændige upload og starte forfra med en ny filidentitet.
Hvordan verificeres downloads?
Downloads autentificerer hvert segment, før det frigives. Fordi kontrollen sker, mens filen streames, kan en fejl sent i en download efterlade en ufuldstændig fil, så sørg for, at downloaden afsluttes korrekt, før du stoler på den.
Hvad er grænserne?
Hver fil i webappen kan være op til 1 GiB. Forhåndsvisninger af billeder og videoer har en separat hukommelsesgrænse. Hvis du rydder det lokale browserlager, kan den chiffertekst, der skal bruges til at genoptage en upload, blive fjernet.
Streamingformatet følger Tinks dokumenterede AES-GCM-HKDF-streamingkonstruktion og bruger native Web Crypto-primitiver. Filens identitet og forventede længde er bundet ind i nøgleafledningskonteksten; segmenttællere og den afsluttende markør beskytter rækkefølgen og fuldførelsen. Denne implementering har ikke gennemgået en uafhængig kryptografisk revision.
Siden om sikkerhedsmodellen beskriver den fulde konstruktion, herunder streamhovedet og nøgleafledningen.