Så fungerar Varsto

Tekniken bakom Varsto, en mekanism i taget: hur en fil blir krypterade block, vilka nycklar som finns, hur den signerade liggaren håller reda på varje kopia, hur enheter synkroniserar och hittar varandra, och vad som ännu inte är klart.

Allt här är implementerat i kärnan, vars källkod är tillgänglig (crates/varsto-core), och beskrivs med exakta fältlayouter i lagringsformatet. Det är alfaprogramvara: formaten kan fortfarande ändras, och varken designen eller koden har granskats. Hotmodellen och felmodellen beskriver vad den skyddar mot och inte.

Översikt

En bärbar dator och en telefon, som båda har nycklarna, utbyter data med dina lagringsplatser, som rymmer de signerade liggarbatcherna, fillistorna och de krypterade blocken; de två enheterna utbyter också block direkt, peer-to-peer, i det lokala nätverket eller över internet.

Varsto består av två sorters delar, och inget av vårt däremellan.

Dina enheter (bärbara datorer, stationära datorer, telefoner) har nycklarna. De delar upp filer i block, krypterar och dekrypterar, och kör synkroniseringen i en bakgrundstjänst.
Dina lagringsplatser rymmer bara chiffertext: en S3-kompatibel bucket, valfri rclone-remote, en NAS eller nätverksutdelning, en lokal eller flyttbar disk, eller en pool av diskar på en hylla. Varsto behöver inget av dem utöver put, get, list och delete.

Varje lagringsplats rymmer samma tre sorters objekt: krypterade block med filinnehåll, varje enhets krypterade fillistor (manifest) och varje enhets signerade liggare, plus några små krypterade poster för enheter, mappar och regler. Varje sökväg har exakt en skrivare: en enhet skriver bara under sitt eget id, och block namnges efter hashvärdet av sin chiffertext och skrivs aldrig över. Lagringsplatserna behöver därför inga lås, och var och en fungerar också som brevlåda: enheter som aldrig är online samtidigt blir ändå samstämmiga, så länge de delar en lagringsplats. Enheter kan också utbyta block direkt, i det lokala nätverket eller över internet.

Det finns inget Varsto-konto, ingen server och inget relä. Om projektet upphörde i morgon skulle dina installerade enheter fortsätta synkronisera via dina lagringsplatser.

Från fil till krypterade block

På enheten delas en fil upp i bitar som komprimeras och krypteras med en nyckel per bit; bara de krypterade blocken, namngivna efter sitt hashvärde, går till lagringsplatsen, som ser hashvärden och storlekar men inga namn eller innehåll.

Uppdelning. Filen delas upp i innehållsdefinierade bitar vars storlek följer filen: ungefär 256 KiB för filer under 32 MiB, 1 MiB upp till 1 GiB, 4 MiB därutöver (en rullande hash väljer delningspunkterna), så att en ändring mitt i filen påverkar några bitar, inte hela filen.
Identitet. Varje bit får ett id: en nyckelad BLAKE3-hash av klartexten under mappens dedup-hashnyckel. Samma innehåll i samma mapp får samma id på varje enhet, vilket gör att deduplicering fungerar offline; nyckeln hindrar den som saknar den från att testa om du har en känd fil.
Komprimering. Biten komprimeras med zstd när det sparar minst 5 %. Nivån är en formatkonstant, så varje enhet producerar samma byte för samma bit.
Kryptering. XChaCha20-Poly1305 under en bitnyckel och en nonce som härleds ur mappnyckeln och bitens id, med associerade data som anger valvet, mappen, biten och dess längd. Deterministiska nycklar är säkra här eftersom varje nyckel krypterar exakt ett meddelande, och de gör att två enheter kan producera byte-identiska objekt utan att kommunicera.
Namngivning. Det lagrade objektet namnges efter BLAKE3-hashen av sin chiffertext. Varje kopia, var den än finns, kan kontrolleras mot sitt namn utan någon nyckel: det är så repliker, peers, fsck --verify och den automatiska verifieringen kontrollerar kopior de inte kan läsa.

Känd avvägning: deterministisk (konvergent) kryptering inom en mapp innebär att två personer som båda har mappnyckeln kan avgöra om de har en identisk fil, och de komprimerade bitarnas storlekar syns för lagringsplatsen. I en delad mapp gäller det under en nyckelepok; när en medlem tas bort får mappen en ny slumpmässig nyckel, så en borttagen medlem kan inte känna igen något som skrivs därefter.

Nycklar

Allt utgår från en enda slumpmässig 256-bitars valvnyckel, som skapas på den första enheten och aldrig härleds ur något du skriver. Den är den enda hemligheten att ta vara på; återställningspaketet är den nyckeln på papper.

På varje enhet lagras valvnyckeln och enhetens signeringsnyckel i keys.enc, krypterade under en nyckel som Argon2id härleder ur enhetens lösenfras. Att byta lösenfras krypterar om den filen och rör ingenting på lagringsplatserna.
Valvövergripande nycklar härleds ur valvnyckeln efter ändamål: liggare, enhetsregister, mapppost, replikliggare, peer-autentisering och beacon-tagg. Om en härledd nyckel röjs avslöjas inte de andra.
Per mapp publiceras en slumpmässig mappnyckel till dina andra enheter i en krypterad mapppost. Ur den kommer dedup-hashnyckeln, metadatanyckeln (fillistor och miniatyrer) och en nyckel per bit. En mappnyckel öppnar den mappen och inget annat; det är den som lämnas över vid delning.
Per enhet finns en signeringsnyckel (Ed25519 + ML-DSA-65) vars publika del är enhetens identitet; enhetens id är en hash av den.

När en enhet tas bort inleds en ny nyckelepok: en ny slumpmässig valvnyckel, förseglad till var och en av de kvarvarande enheterna med det hybrida nyckelutbytet nedan. Nya liggarbatcher, poster, fillistor och block använder de nya nycklarna, och en kedja av krypterade epokposter låter den nya nyckeln öppna allt äldre. Den borttagna enheten hittar en signerad återkallelse nästa gång den når en lagringsplats och slutar; med en raderingsorder tömmer den också sina mappar och nycklar.

Algoritmerna

Ändamål	Algoritm	Anmärkningar
Kryptering av innehåll och metadata	XChaCha20-Poly1305 (AEAD)	256-bitars nycklar, 192-bitars nonces. Varje chiffertext bär associerade data som anger vad den är, så en lagringsplats kan inte flytta ett objekt till en annan roll.
Hashning och nyckelhärledning	BLAKE3 (nyckelad hash och derive_key)	Bit-id:n och filhashar är nyckelade. Varje härledd nyckel bär kontexten `e2ee-sync-format/0/<purpose>`.
Från lösenfras till nyckel	Argon2id	Minst 64 MiB, 3 pass; ett slumpmässigt salt per enhet. Lösenfrasen lämnar aldrig enheten.
Signaturer (liggare, poster)	Ed25519 + ML-DSA-65, hybrid	Båda signaturerna täcker samma byte och båda måste verifieras. En nyckel med en postkvantdel godtar aldrig en signatur med enbart Ed25519.
Nyckelutbyte (delning, nya epoker)	X25519 + ML-KEM-768, hybrid	Båda delade hemligheterna och hela transkriptet går in i en nyckel; en förseglad hemlighet förblir privat om inte båda algoritmerna knäcks.
Mappar med säkerhetsnyckel	FIDO2 hmac-secret	Säkerhetsnyckeln härleder en 32-byte hemlighet ur en credential och ett salt per mapp efter en beröring.
Återställningspaket	BIP-39-ord, Shamir över GF(256)	24 ord med kontrollsumma; valfritt 2-av-3-andelar.

Liggaren

Den bärbara datorn skriver liggarbatch 42 till dina lagringsplatser; den stationära datorn läser den, kontrollerar den och slår samman den; varje enhets vy svarar sedan på var block 7f3a finns: på box, lagrat av den bärbara datorn och verifierat av den stationära, och på cloud, lagrat av den bärbara datorn men ännu inte verifierat.

Liggaren är Varstos bokföring. Varje enhet för sin egen logg över fakta som bara kan läggas till om vad den har gjort, och ingen enhet skriver någonsin i en annans logg. Fakta är små och konkreta: ”Jag skrev block 7f3a till lagringsplatsen jag kallar box”, ”Jag laddade ner 7f3a från box och hashvärdet stämde”, ”Jag publicerade version 12 av den här mappens fillista”.

Varje enhet läser alla andra enheters loggar via lagringsplatserna och spelar upp dem alla till samma bild: vilka block som finns, var varje kopia finns, vem som skrev den, vem som har kontrollerat den och när. Inget i den betros på grund av var det kom ifrån: varje batch är signerad av enheten som skapade den, och en kopia räknas som verifierad först när en annan enhet har kontrollerat den.

Utan liggaren kan ett synkroniseringsverktyg bara hoppas att dess kopior finns. Med den kan Varsto säga hur många kopior av varje block som finns, på vilka platser, hur nyligen var och en kontrollerades och vilka ingen har kontrollerat än.

Vad den registrerar

Händelse	Betydelse
Enhet registrerad	Den här enheten anslöt till valvet, under det här namnet.
Mapp tillagd	Den här enheten skapade en mapp.
Block lagrat	Den här enheten skrev ett krypterat block till en lagringsplats: mapp, bit-id, objektnamn, storlek och lagringsplats. Ett påstående som bara intygas av skrivaren.
Block verifierat	Den här enheten laddade ner blocket från en lagringsplats och hashvärdet stämde med namnet. Registreras vid nedladdningar, `fsck --verify`, automatisk verifiering och fullständiga diskkontroller.
Block på enhet	Den här enheten har blockets klartext, som del av en fil.
Fillista publicerad	Den här enheten publicerade version n av en mapps fillista, med dess hash och antal filer.
Lagringsplats avvecklad	En lagringsplats togs bort från valvet: påståenden om den som gjorts före den här händelsen räknas inte längre som kopior.

Inga filnamn och inget innehåll: block identifieras med nyckelade bit-id:n och chiffertexthashar, och hela batchen är dessutom krypterad.

Signerad, kedjad och förseglad

Liggarbatcherna 40, 41 och 42, var och en signerad med Ed25519 och ML-DSA-65 och kedjad till den föregående; en andra batch 41 från en tillbakarullad enhet förgrenar kedjan och upptäcks och spärras av de andra enheterna.

Händelser samlas i batcher, vanligen en per synkronisering snarare än en per fil. En batch bär enhetens id, ett sekvensnummer (1, 2, 3, ...), hashen av enhetens föregående batch, en logisk klocka, när den skapades och händelserna.

Innehållet krypteras med XChaCha20-Poly1305 under liggarnyckeln, med enhetens id och sekvensnumret som associerade data.
Enheten signerar sitt id, sekvensnumret och hashen av det krypterade innehållet med både Ed25519 och ML-DSA-65. Eftersom chiffertextens hash signeras kan vem som helst kontrollera kedjan utan nyckeln.
Den signerade batchen skrivs till varje lagringsplats som rymmer poster som ledger/<device>/<sequence>, och skrivs aldrig över.

En läsare godtar en batch bara när båda signaturerna verifieras mot enhetens publika nyckel i enhetsregistret och dess föregående hash stämmer. Postkvantsignaturen kostar ungefär 3,3 KB, och därför färdas händelserna i batcher: liggaren växer med några kilobyte per synkronisering, inte per fil.

Utbyts via dina lagringsplatser

Varje lagringsplats är en brevlåda. När en enhet har sparat en batch laddar den upp alla egna batcher som en lagringsplats saknar; vid varje hämtning listar den liggaren på varje varm lagringsplats, tar de batcher den inte har sett, kontrollerar dem, dekrypterar dem och behåller en lokal kopia. Eftersom varje lagringsplats bär hela liggaren ser en bärbar dator som synkroniserar på natten och en telefon som synkroniserar på morgonen samma historik utan att någonsin mötas. Ingen ordnar något centralt: en logisk klocka (Lamport) ordnar ändringarna, inte väggklockan. Opålitliga repliker och de personer du delar en mapp med skriver också liggare, förseglade under nycklar som bara öppnar deras del: en repliks påståenden anger objekt, inte filer, och en medlems påståenden gäller bara den delade mappen.

Vyn: var varje block finns

När alla batcher spelas upp får varje enhet samma vy: för varje block i varje mapp dess objektnamn och storlek, de lagringsplatser som påstår sig ha en kopia och vilken enhet som påstod det, vilka enheter som verifierade det där och när, och vilka enheter som har klartexten. Den känner också till varje enhets senaste fillista för varje mapp, vilka enheter och mappar som finns och vilka lagringsplatser som är avvecklade. Lagringsplatsernas namn är lokala för varje enhet (”box” här, ”primary” där), så varje lagringsplats bär en slumpmässig identitet, och enheterna matchar varandras påståenden med den.

Vad den används till

Ladda upp en gång. Innan en enhet skickar hoppar den över varje lagringsplats som redan påstår sig ha blocket, så en fil som läggs till på två enheter laddas upp en gång.
Frigöra utrymme säkert. En fil blir en platshållare först när liggaren visar varje block på en lagringsplats som inte är en överföringsdisk, och mappens kopieringsregler fortfarande uppfylls.
Lagringsregler. ”Minst tre kopior, varav en i molnet, var och en verifierad av en annan enhet inom 30 dagar” utvärderas enbart utifrån liggaren, och tjänsten larmar när en mapp försämras.
Automatisk verifiering. Bakgrundstjänsten väljer kopior som andra enheter har skrivit och som ingen har kontrollerat nyligen, laddar ner dem, jämför chiffertextens hash med namnet och registrerar resultatet, inom en daglig budget.
fsck. Jämför liggaren med vad lagringsplatserna faktiskt listar: påståenden utan objekt, block utan kopia någonstans, block som verifierats på annat håll.
Överföringsdiskar. En bärardisk tar bara de block som ingen annan enhet har än, och lämnar tillbaka utrymmet när båda ändar har dem.
Ta bort en lagringsplats. Varsto planerar utifrån liggaren vilka block som skulle hamna under mappens minimum, kopierar dem till andra platser, kontrollerar igen och registrerar först då avvecklingen.
Kostnader. Månadskostnaden för en lagringsplats är de byte som liggaren registrerar på den gånger dess pris.
Ta bort en enhet. En återkallelse anger den borttagna enhetens sista batch som räknas; allt den signerar därefter utelämnas ur varje vy, och bara de fillistor som de batcherna annonserade slås samman.

Förgreningar och återställda enheter

Eftersom varje enhet numrerar och kedjar sina egna batcher kan historiken inte skrivas om i det tysta. Två olika batcher med samma enhet och sekvensnummer, eller en batch vars föregående hash inte stämmer, är en förgrening: varje enhet som ser en sådan markerar enheten som förgrenad, och fsck rapporterar det. Den vanliga orsaken är en enhet som återställts från en gammal säkerhetskopia eller en klonad disk, som skulle fortsätta från ett sekvensnummer som dess nyare jag redan har använt. När en enhet hittar batcher under sin egen identitet som den aldrig skrivit spärrar den sig själv: den slutar signera och skicka tills den registreras på nytt som en ny enhet, så att två divergerande kopior av en identitet aldrig båda skriver historik.

Begränsningar

En signatur bevisar att en enhet sade att den lagrade ett block, inte att blocket fortfarande finns kvar. Därför räknas en kopia som verifierad först när en annan enhet har kontrollerat den; det finns ännu inget lagringsbevis med challenge-response.
En lagringsplats som serverar en äldre men giltig del av liggaren avslöjas inte av signaturerna; det syns först när en annan lagringsplats eller enhet har nyare batcher. Att upptäcka tillbakarullning är ett designmål, inte en testad egenskap.
Liggaren växer vid varje synkronisering. Sedan alpha.8 skriver enheterna kontrollpunkter och rensar bekräftade batcher, så det som lagras förblir begränsat; medlemmar i delade mappar och repliker behåller fortfarande varje batch.
Verifieringstiderna kommer från enheternas klockor: en klocka som går kraftigt fel kan ge falska larm, men ändrar inte ordningen på ändringarna.
Lagringsplatserna ser antalet liggarkataloger (ditt antal enheter) och batchernas storlek och tidpunkter.

Fillistor och synkronisering

Liggaren säger var blocken finns; manifesten säger vad filerna är. Efter en ändring publicerar en enhet hela sin bild av en mapp som ett nytt manifest: varje sökväg med storlek, ändringstid, innehållshash, blocklista och en versionsvektor (för varje enhet klockan för dess senaste ändring). Det krypteras under mappens metadatanyckel och annonseras i liggaren. Andra enheter hämtar de manifest de inte har sett och slår samman dem sökväg för sökväg:

en version som innefattar den andra vinner; identiskt innehåll slås samman;
en ändring vinner över en samtidig radering, så en radering förstör aldrig någons arbete;
två olika samtidiga ändringar ger en deterministisk vinnare (högre klocka, sedan enhetens id), och den andra versionen behålls som name.conflict-<device>-<clock>.ext, så att båda enheterna blir samstämmiga utan ytterligare en runda.

Raderade filer hamnar i en lokal papperskorg och tas aldrig bort direkt. Bakgrundstjänsten bevakar dina mappar och synkroniserar inom några sekunder efter en ändring. Selektiva mappar visar alla filer men behåller platshållare för dem du inte har hämtat, och hämtar en fil när du öppnar den. Manifesten är i dag fullständiga vyer; mycket stora mappar kommer att behöva inkrementella.

Peer-to-peer

Enheter utbyter också block direkt. Eftersom krypteringen är deterministisk inom en mapp kan en enhet som har en fil leverera exakt det objekt som lagringsplatsen har, och mottagaren kontrollerar det mot namnet precis som en kopia från en lagringsplats. En enhet som behöver ett block frågar först sina peers och sedan lagringsplatserna, och fördelar på varandra följande block över de peers som svarar.

Hitta varandra. I det lokala nätverket en multicast-beacon som bär en nyckelad tagg, inte valvets id. Över internet en krypterad mötespost på dina lagringsplatser med varje enhets adresser.
Ta sig igenom NAT. HTTP i det lokala nätverket, QUIC över UDP över internet: STUN berättar för en enhet vilken dess publika adress är, båda sidor slår hål, och när det misslyckas vidarebefordrar en av dina egna nåbara enheter trafiken. Det finns inget leverantörsrelä.
Vem som får ansluta. Varje enhet har ett eget certifikat vars hash är fäst i dess post; varje förfrågan bär också ett kortlivat bevis som skapats med valvets nyckel för peer-autentisering. En främling får ingenting, och en borttagen enhet stryks från listan över peers.

Testat på localhost, i underhållarens egna nätverk och i en uppställning med tre enheter bakom olika NAT. Två symmetriska NAT kan inte genomslås och faller tillbaka på ett relä, vilket kräver en nåbar enhet i valvet (en hemserver, en VPS, en vidarebefordrad port); socketar stöder bara IPv4.

Hur snabbt. Prestandatester mäter nedladdningar mellan Paris, Amsterdam och Warszawa, peer-to-peer jämfört med en S3-bucket, med metoden, siffrorna och vad som fortfarande är långsamt.

Transport och det lokala gränssnittet. Objekten är chiffertext innan de lämnar enheten, så transporten lägger inte till ett andra lager bara för sakens skull: S3 talas över HTTPS med Signature Version 4, rclone-remotes använder rclones egen konfiguration, och S3-hemligheten förvaras i en krypterad fil. Skrivbordsgränssnittet levereras bara på 127.0.0.1, varje förfrågan bär en sessionstoken, Host-huvudet kontrolleras och sidan körs under en strikt Content Security Policy.

Vad varje part kan se

Part	Ser	Kan inte se
En lagringsleverantör (bucket, NAS, disk, rclone-remote)	Objektnamn (hashar av chiffertext), objektstorlekar, hur ofta du skriver och läser, ditt antal enheter utifrån antalet liggarkataloger.	Filnamn, innehåll, mappnamn, vilka block som hör till vilken fil, hashen av din klartext.
En opålitlig replik (en väns NAS)	Samma som en lagringsleverantör, plus att objekten stämmer mot sina namn. Den signerar sina egna påståenden under en nyckel som bara gäller repliken.	Något innehåll, namn eller någon fillista; den får aldrig en mappnyckel eller valvnyckeln.
En peer i det lokala nätverket eller på internet	Att någon enhet begär objekt efter namn, efter att ha bevisat att den har valvets nyckel för peer-autentisering.	Något alls utan den nyckeln: en främling får inget objekt, och beaconen i det lokala nätverket namnger inte valvet.
Någon du delar en mapp med	Den mappen: varje fil i den, och dina enheters signerade påståenden om den.	Någon annan mapp, valvnyckeln, ditt enhetsregister.
En AI-assistent via MCP-servern	De mappar du gav åtkomst till, med enbart läsrätt om du inte sade annat.	Mappar du inte gav åtkomst till; Strongroom-mappar, aldrig.
En tjuv med din upplåsta bärbara dator	Allt som en vanlig mapp innehåller medan enheten är upplåst.	Strongroom-mappar utan din säkerhetsnyckel; inget som skrivits efter att du tagit bort enheten från en annan, utom i mappar som delas med andra personer.

Strongroom: kryptografiskt, inte en dialogruta

En beröring av säkerhetsnyckeln låser upp en Strongroom-mapp: bara credential-id, saltet och den inslagna mappnyckeln lagras, nyckeln stannar i minnet i 15 minuter, och lösenfrasen, valvnyckeln eller en stulen säkerhetskopia kan inte öppna den.

En Strongroom-mapps nyckel finns aldrig i vila. När mappen skapas gör säkerhetsnyckeln en credential och tar sedan fram en 32-byte hemlighet ur den och ett slumpmässigt salt per mapp (FIDO2 hmac-secret). Varsto slår in mappnyckeln under den hemligheten och lagrar bara credential-id, saltet och den inslagna nyckeln. Upplåsning upprepar beröringen och håller nyckeln i minnet under en tidsperiod (15 minuter som standard) och glömmer den sedan. Det finns ingen väg till mappnyckeln utan den fysiska nyckeln: inte via lösenfrasen, valvnyckeln eller en stulen säkerhetskopia. Reservsäkerhetsnycklar får sin egen inslagning av samma mappnyckel. Att konvertera en befintlig mapp ger den ett nytt id och en ny nyckel, krypterar om den och raderar den gamla chiffertexten; att byta nyckel för ett Strongroom gör detsamma med en ny nyckel inslagen för varje registrerad säkerhetsnyckel, för de fall då någon kan ha behållit en nyckel.

Lösenfraser och återställningspaketet

Ett återställningspaket med 24 ord, eller tre andelar av vilka två valfria återskapar valvnyckeln medan en ensam inte avslöjar något.

Enhetens lösenfras går genom Argon2id för att låsa upp keys.enc; bakgrundsappen kan förvara den i operativsystemets nyckelring så att tjänsten låser upp sig själv efter inloggning. Att förlora en lösenfras innebär att förlora den enhetens kopia av nycklarna, inte valvet: en annan enhet, eller återställningspaketet, registrerar en ny.

Återställningspaketet skriver ut valvnyckeln som 24 BIP-39-ord (ett felskrivet ord fångas av kontrollsumman) och, om du vill, tre Shamir-andelar av vilka två valfria återskapar nyckeln medan en ensam inte avslöjar något. Det finns inget konto, ingen deponering och ingen återställning av lösenord: paketet är hur du bär ansvaret. Skriv ut ett nytt paket efter att du tagit bort en enhet, eftersom det gamla innehåller den gamla nyckeln.

Vad som inte är klart

Inte granskat. Algoritmerna är standardalgoritmer och biblioteken välkända Rust-implementationer, men sammansättningen har inte granskats av en extern kryptograf, och lagringsformatet kan fortfarande ändras.
Metadata. Lagringsplatserna ser objektstorlekar, skriv- och läsmönster, antalet enheter och ungefär antalet block. Utfyllnad och skyddstrafik är inte implementerade.
Konvergent kryptering inom en mapp låter de som delar mappnyckeln bekräfta identiska filer.
Att ta bort en enhet skyddar det som skrivs därefter, inte det som enheten redan hade: befintliga data krypteras inte om, delade mappar och Strongroom-mappar behåller sina nycklar, och lagringsplatsernas inloggningsuppgifter byts inte ut. Tills en andra faktor finns kan vilken som helst av dina enheter ta bort vilken annan som helst (i ett valv med en organisation kan bara administratörer det).
Att ta bort en medlem i en delad mapp skyddar det som skrivs därefter; den lagringsplats ni båda når förblir skrivbar för dem tills du ändrar dess åtkomst.
Liggaren har inget lagringsbevis, upptäckt av tillbakarullning är otestad, och kontrollpunkter och rensning (alpha.8) begränsar dess storlek bara för valvets enheter: medlemmar i delade mappar och repliker behåller fortfarande varje batch.
Placering. En mapp kan skrivas till valda lagringsplatser eller platser, och block kan flyttas mellan lagringsplatser (så att bara en kall kopia av oanvända filer behålls). Filer vars block bara finns i kall lagring hämtas inte förrän du flyttar tillbaka dem, och enheter med 0.0.1-alpha.8 eller äldre slutar synkronisera när en flytt har registrerats.
Strongroom skyddar mappnyckeln, inte en fil du har hämtat och lämnat på disken; återställningspaketet omfattar inte Strongroom-mappar.
Valvnyckeln är en enda hemlighet. Förvara återställningspaketet på mer än ett ställe.

Detaljer på fältnivå, bytelayouter och versionsregler: lagringsformat, nyckelhierarki, anteckningar om liggarsignering, säkerhetsprinciper, felmodell.