End-to-end-codering

Wat we bedoelen met end-to-end versleuteld

Elk bestand dat je via Terashare deelt, wordt versleuteld op je apparaat voordat het de browser verlaat. De server, onze cloudopslaglaag en de peer-to-peer-zwerm zien alleen versleutelde bytes. De decoderingssleutel bereikt onze servers nooit; hij reist in het URL-fragment van de deellink, die browsers nooit via het netwerk verzenden.

Dit is geen marketingclaim bovenop een normale upload. Het is het ontwerp. Er is geen pad in de codebase waarmee de server naar een tekstbestand of een sleutel in platte tekst kan kijken. Als we je bestanden wilden lezen, zouden we nieuwe code moeten verzenden (en je zou deze moeten downloaden) en een externe audit zou deze kunnen ontdekken. Dat is een ander dreigingsmodel dan ‘de server belooft niet te kijken’.

Waarmee we coderen

Primitief	Doel	Waarom deze
AES-256-GCM	Bestandsinhoud + elke ingepakte sleutel	Geauthenticeerd symmetrisch cijfer: knoeien met welke byte dan ook zorgt ervoor dat de decodering luid mislukt. Hetzelfde cijfer dat wordt gebruikt door HTTPS, banken en schijfversleuteling.
Argon2id (opslimit=2, memlimit=64 MiB - libnatrium INTERACTIEF)	Verander je inlogwachtwoord in een sleutelcoderingssleutel	Geheugenharde wachtwoordhashing – hetzelfde profiel dat de webkluis van Bitwarden gebruikt. Ongeveer 1000× duurder per gok bij GPU/ASIC offline-aanvallen dan een vergelijkbare PBKDF2-opstelling. Het algoritme en de parameters worden naast je kluis vastgelegd, zodat we de kosten kunnen afstemmen (of de KDF volledig kunnen omwisselen) zonder bestaande kluizen kapot te maken.
crypto.getRandomValues	Elke sleutel, elke nonce, elk zout	De CSPRNG van de browser, gecontroleerd en op FIPS afgestemd. We genereren nooit sleutels aan de serverzijde.
TSE2 houder	Draadformaat op bestandsniveau	Een klein, versiebeheerd binair formaat dat elk versleuteld stuk uitlijnt met de WebTorrent-stukgrens. Stuk 0 bevat een versleuteld headerslot (bestandsnaam, grootte, basisnonce); elk ander stuk kan onafhankelijk worden gedecodeerd zodra het over de zwerm arriveert - zodat de ontvanger kan beginnen met het schrijven van leesbare tekst naar schijf terwijl de rest van het bestand nog aan het downloaden is. De stukindex is gebonden aan de GCM AAD, dus het opnieuw ordenen of splitsen van stukken mislukt de authenticatie.

Waarom dit veilig blijft in een post-kwantumwereld

De meeste "end-to-end versleutelde" tools voor het delen van bestanden zijn afhankelijk van RSA of elliptische curven om een sleutel uit te wisselen tussen afzender en ontvanger. Op de dag dat er een grote kwantumcomputer arriveert, verbreekt het algoritme van Shor beide – met terugwerkende kracht. Cijfertekst die vandaag is opgenomen, decodeert dan.

Terashare doet geen asymmetrische sleuteluitwisseling. De sleutel reist in het URL-fragment zelf; de afzender en de ontvanger delen het via elk kanaal dat ze al vertrouwen (e-mail, chat, sms). De enige kwantumaanval op AES-256 is het algoritme van Grover, dat de effectieve sleutelgrootte slechts halveert – 256 bits wordt ~128 bits post-kwantumbeveiliging, wat in de nabije toekomst nog steeds buiten het bereik van elke plausibele aanvaller ligt.

Bestanden die je vandaag de dag via Terashare deelt, blijven dus zelfs over tientallen jaren vertrouwelijk, ongeacht wat kwantumcomputers uiteindelijk doen.

Je persoonlijke sleutelkluis

Eén vraag waarmee elke E2EE-tool voor het delen van bestanden uiteindelijk te maken krijgt: "Als alleen de ontvanger en ik de sleutel hebben, wat gebeurt er dan als ik een bestand later opnieuw wil delen en de link kwijt ben?" Het naïeve antwoord is "dat kan niet." Ons antwoord is een sleutelkluis per gebruiker.

De kluis maakt gebruik van een envelopversleuteling-hiërarchie met drie niveaus:

your login password
   │ Argon2id(opslimit=2, 64 MiB, per-user salt)
   ▼
   KEK ──── wraps ────▶ MK (random master secret)
                          │
                          │ wraps every per-file DEK
                          ▼
                       DEK_1, DEK_2, DEK_3, ...
   ▲
   │ also wraps MK ◀──── recovery key (one-time, shown once at signup)
        

• Je wachtwoord wordt omgezet in een Key-Encryption Key (KEK) — geheel in je browser en nooit ergens naartoe verzonden.
• Een willekeurig hoofdgeheim (MK) wordt onafhankelijk verpakt door de KEK en door een eenmalige herstelsleutel. De server slaat beide cijferteksten op. Het is niet mogelijk om het uit te pakken zonder je wachtwoord of de herstelsleutel.
• De sleutel van elk bestand (DEK) wordt door MK ingepakt en naast de share opgeslagen. De kopie van de ontvanger staat nog steeds in het URL-fragment, maar die van je bevindt zich in je kluis, zodat je de link telkens opnieuw kunt opbouwen wanneer je zich aanmeldt.

Waarom drie lagen?

• Wachtwoordrotatie is O(1). Als je je inlogwachtwoord wijzigt, verpakken we MK alleen opnieuw onder een nieuwe KEK. Sleutels per bestand en cijfertekst blijven onaangetast, ongeacht hoeveel bestanden je hebt gedeeld.
• De herstelsleutel is een aparte envelop, niet hetzelfde geheim als MK. We zien het nooit: het wordt in je browser gegenereerd, je krijgt het één keer te zien bij het aanmelden en het wordt weggegooid. Je kunt het kopiëren, downloaden als tekstbestand, opslaan in een wachtwoordbeheerder of afdrukken op papier. Als je je inlogwachtwoord verliest, reconstrueert de herstelsleutel MK; zonder dit is de kluis werkelijk onherstelbaar (verlies dus niet beide).
• Alles kwijt? Bestanden kunnen nog steeds worden hersteld. Iedereen die een deellink heeft opgeslagen, inclusief jijzelf, kan het bestand nog steeds ontsleutelen via de sleutel in de URL. Kluistoegang ≠ bestandstoegang.

Waar je dit patroon eerder hebt gezien

Dit is dezelfde envelopversleutelingshiërarchie die wordt gebruikt door de belangrijkste end-to-end-versleutelde wachtwoordbeheerders en back-upsystemen. De dichtstbijzijnde opgeschreven referentie voor het model dat we gebruiken is Beveiligingswhitepaper van Bitwarden , dat door het wachtwoord loopt → uitgerekte sleutel → een gebruikerssleutel met een lange levensduur bevat → sleutels per item verpakt. 1Password-, Proton-, WhatsApp E2E-back-ups en iCloud Advanced Data Protection gebruiken allemaal dezelfde vorm.

Als je deze producten vertrouwt om je wachtwoorden of je iCloud-reservekopieën te beschermen, kun je dezelfde cryptografische structuur vertrouwen om je bestandsshares te beschermen.

Wat een inbreuk op Terashare eigenlijk zou lekken

Een nuttige test voor elke privacyclaim: vraag wat een aanvaller die het bedrijf volledig in gevaar brengt, zou zien.

Een aanvaller die onze database steelt, ziet…	…en kan ik er wat mee?
Bestandsnaam, grootte, deel-URL, magneetlink, eigenaar	Alleen metadata. Handig voor het routeren van de share, nutteloos voor het lezen ervan.
Verpakte DEK (per gedeeld item) + verpakte MK (per gebruiker)	Beide zijn cijfertekst. Zonder je wachtwoord of je herstelsleutel is geen van beide decodeerbaar.
Bestandscijfertekst op cloud / WebTorrent-zwerm	Lijkt op uniforme willekeurige ruis. Zonder de DEK is er geen manier om het sneller dan brute kracht te lezen.
Je wachtwoord, herstelsleutel, MK, DEK's	Geen van deze bereikt ooit de server, dus ze bevinden zich niet in de inbreuk.

Hoe je dit allemaal zelf kunt verifiëren

• Lees de code die in je browser wordt uitgevoerd. De cryptografie bestaat uit twee korte, zelfstandige JavaScript-modules (bestandsindeling en kluis) die zijn gebouwd op de WebCrypto API van de browser plus de goed gecontroleerde libsodium.js (sumo build, woordelijk door de leverancier verkocht) voor Argon2id. Ze worden aan elke bezoeker aangeboden - open DevTools → Bronnen om ze te lezen:
  • js/services/e2ee.js — bestandsformaat, coderen, decoderen, stukverwerking
  • js/services/e2ee-vault.js — kluis: Argon2id, wikkelen, uitpakken, rotatie, herstel
• Bekijk het tabblad Netwerk. Open DevTools, deel een versleuteld bestand en bevestig dat de bytes die de draad raken niet overeenkomen met de inhoud van je bestand - en dat het URL-fragment (het gedeelte na #) nooit in een verzoek wordt verzonden.
• Bekijk de tests. De crypto-rondreizen aan de browserzijde en de paden voor het ontgrendelen van de kluis worden gedekt door Selenium-tests die echte WebCrypto in echt Chrome uitvoeren.