Zero-Knowledge Proof in Bestandsoverdracht Systems

Zero-knowledge bewijzen laten één partij bewijzen dat een bewering waar is, zonder iets prijs te geven behalve de waarheid van die bewering zelf. Toegepast op bestandsoverdracht kan een afzender of server via ZKP's aantonen dat een bestand overeenkomt met een verwachte hash, versleuteld is met een specifieke sleutel, of voldoet aan een beleid — zoals "kleiner dan 10 GB en niet op een malwareblokkeerlijst" — zonder de bestandsinhoud te onthullen. De Autoriteit Persoonsgegevens (AP) en de AVG stellen dat privacy by design een vereiste is, geen optie; zero-knowledge technieken zijn een van de meest geavanceerde manieren om aan die eis te voldoen. De technologie, geformaliseerd door Goldwasser, Micali en Rackoff in 1985 en nu praktisch via zk-SNARKs (Groth16, PLONK) en zk-STARKs, verschuift van cryptocurrency naar privacy-behoudende bestandssystemen.

Wat "zero-knowledge" in deze context betekent

Twee gebruikswijzen botsen in de marketing. De eerste is de formele cryptografische betekenis: een interactief of niet-interactief protocol dat kennis van een getuige bewijst zonder deze te onthullen, zoals gedefinieerd in de Fiat-Shamir-heuristiek en moderne zk-SNARK-constructies zoals Groth16 (2016) en PLONK (2019). De tweede is de lossere commerciële betekenis, waarbij "zero-knowledge" aanduidt dat de dienstverlener gebruikersgegevens niet kan ontsleutelen omdat hij de sleutels niet bezit — zoals gebruikt door Proton, Tresorit en Sync.com. Beide zijn geldig, maar ze lossen verschillende problemen op. De commerciële betekenis is eigenlijk client-side end-to-end versleuteling; de cryptografische betekenis opent nieuwe workflows die met E2EE alleen onmogelijk zijn.

Bestandsintegriteitsbewijzen zonder onthulling

Stel je een juridisch ontdekkingsscenario voor. Een reagerende partij overhandigt versleutelde bestanden en wil volledigheid bewijzen — dat niets is achtergehouden — zonder de inhoud te onthullen. Een Merkle-boomtoezegging gecombineerd met een zero-knowledge bewijs kan aantonen dat elk bestand in een afgesproken index aanwezig is, correct gehasht is en versleuteld is met de gedeelde sleutel. De ontvangende partij verifieert het bewijs in milliseconden zonder inhoud te zien totdat er ontsleuteld wordt. Tools gebouwd op Halo 2, Circom en Plonky2 laten circuits die deze beweringen uitdrukken client-side in browsers draaien via WebAssembly-compilatie.

Selectieve onthulling voor naleving

Een arts die de DICOM-studie van een patiënt doorstuurt voor een tweede mening, wil misschien bewijzen — zonder identiteit te onthullen — dat de afzender een erkende arts is bij een HIPAA-gedekte entiteit. Een zero-knowledge credential-bewijs met behulp van het W3C Verifiable Credentials Data Model v2.0 met BBS+ handtekeningen kan dit realiseren. De ontvanger verifieert de referenties van de afzender zonder de naam of instelling te zien. Hetzelfde patroon geldt voor exportcontrole-naleving: bewijs dat het bestemmingsland van het bestand is goedgekeurd zonder het bestand of de exacte bestemming te onthullen.

Bewijs van upload zonder de server te vertrouwen

Een veelvoorkomend probleem bij bestandsoverdracht: de afzender uploadt een bestand, de server beweert het te hebben ontvangen — maar hoe kan de afzender server-side bewijzen wat er werkelijk is opgeslagen? Protocollen gebaseerd op proof-of-retrievability (PoR) en proof-of-data-possession (PDP), geformaliseerd door Juels-Kaliski (2007) en Ateniese et al. (2007), laten de server bewijzen dat hij het volledige bestand bezit door willekeurige uitdagingen te beantwoorden met cryptografische bewijzen. Gedecentraliseerde opslag zoals Filecoin gebruikt deze aanpak om te bewijzen dat opslagproviders de data bezitten die ze claimen. Voor een gecentraliseerde overdrachtsservice geeft PoR de afzender zekerheid zonder vertrouwen in auditlogs.

Private Set Intersection voor deduplicatie

Bestandsoverdrachtsservices dedupliceren vaak identieke bestanden server-side om opslag te besparen. Op een naïeve manier gedaan lekt dit informatie: twee gebruikers die hetzelfde bestand uploaden, ontdekken elkaar. Private Set Intersection (PSI)-protocollen die gebruikmaken van oblivious pseudorandom functions (OPRF) of Bloom filter-versleuteling laten de server duplicaten cryptografisch detecteren terwijl geen van de partijen en ook de server niet leert welke specifieke bestanden overeenkwamen. PSI-bibliotheken zoals Microsofts APSI en Googles PSI-implementatie draaien in browsers via WASM. Dit is relevant voor E2EE-systemen waarbij server-side deduplicatie anders het bedreigingsmodel zou schenden.

Beleidsnaleving bewijzen zonder de inhoud te onthullen

Enterprise-overdrachtsystemen draaien vaak DLP-scans (Data Loss Prevention) om uploads met burgerservicenummers, creditcardnummers of bedrijfseigen markeringen te blokkeren. Een zero-knowledge DLP-bewijs zou de afzender in staat stellen te bewijzen dat "dit bestand geen 16-cijferige strings bevat die overeenkomen met Luhn-geldige creditcardpatronen", zonder het bestand aan de DLP-server te onthullen. Circuits in Circom of Noir kunnen deze controles uitdrukken. Prestaties zijn de bottleneck: het bewijzen dat een bestand van 100 MB voldoet aan een complex beleid kan minuten duren en bewijzen van megabytes produceren. Onderzoek in GKR en vouwschema's zoals Nova (2022) vermindert de bewijstijd aanzienlijk, waardoor praktische inzet binnen een paar jaar haalbaar wordt.

zk-SNARKs versus zk-STARKs voor bestanden

zk-SNARKs (Succinct Non-interactive Arguments of Knowledge) zoals Groth16 en PLONK produceren kleine bewijzen van 200 tot 500 bytes die in milliseconden te verifiëren zijn, maar vereisen een vertrouwde opstelceremonie. zk-STARKs (Scalable Transparent Arguments of Knowledge), gebruikt in de productiesystemen van StarkWare, vereisen geen vertrouwde opstelling en vertrouwen uitsluitend op hashfuncties — waardoor ze post-kwantumveilig zijn — maar bewijzen zijn groter: 50 KB tot enkele MB. Voor bestandsoverdracht passen SNARK-bewijzen goed in HTTP-headers of kleine metadatavelden, terwijl STARK-bewijzen omvangrijker zijn maar vertrouwensveronderstellingen vermijden.

Prestatiebegroting voor bewijs in de browser

Het genereren van een bewijs dat een bestand van 1 MB overeenkomt met een specifieke hash duurt ongeveer 100 ms tot 2 seconden in een browser met Halo 2 of snarkjs gecompileerd naar WASM, afhankelijk van de grootte van het circuit en het apparaat. Voor bestandsintegriteitsbewijzen bij overdrachtstijd is dit acceptabel. Voor complexere beweringen zoals beleidsnaleving over grote bestanden kan het bewijzen vereisen dat naar een server wordt overgedragen of in achtergrondwerkers met OffscreenCanvas en Service Workers wordt uitgevoerd. De Web Crypto API verwerkt standaard hashprimitieven met native snelheid, maar aangepaste ZK-circuits betalen nog steeds de WASM-interpretatie-overhead — ruwweg 2 tot 5 keer langzamer dan native.

Integratiepatronen met bestaande E2EE

ZKP's kunnen bovenop E2EE worden gelaagd in plaats van het te vervangen. Een typisch patroon: de afzender versleutelt het bestand met AES-256-GCM, berekent een SHA-256-hash van de leesbare tekst en genereert een bewijs dat aan die hash is gekoppeld. De server slaat versleutelde tekst, de toezegging en het bewijs op. De ontvanger haalt alle drie op, ontsleutelt, herhasht de leesbare tekst en verifieert het bewijs. Dit detecteert manipulatie en levert ook een overdraagbare integriteitsbevestiging op die de ontvanger aan een derde partij — zoals een toezichthouder — kan tonen zonder het bestand te onthullen.

Waar ZKP's vandaag passen en waar niet

Vandaag passen ZKP's goed voor compacte integriteits- en authenticiteitsbeweringen, deduplicatie zonder onthulling en credential-gebaseerde toegang tot overdrachts-endpoints. Ze passen nog niet voor algemene inhoudscontroles op grote bestanden — de bewijs-tijd en -omvang zijn nog niet gereed. Voor dagelijkse bestandsoverdrachts-privacy verwerkt client-side E2EE met AES-256-GCM en X25519-sleuteluitwisseling, zoals gebruikt in HexaTransfer, het gangbare bedreigingsmodel goed zonder de complexiteit van ZKP-circuits.

Praktische inzet in productie

Projecten die ZKP's toepassen op bestandsworkflows zijn onder meer Iden3 en Polygon ID voor credential-verificatie, Aleo voor privé smart contract-staat en Mina Protocol voor beknopte blockchain-staat. Bestandsspecifieke inzet is nog onderzoeksmatig maar vordert. Verwacht de eerste ZK-verbeterde bestandsoverdrachtsfuncties in productie in 2027 tot 2028, waarschijnlijk beginnend met integriteitsbewijzen en PSI-gebaseerde deduplicatie.

Probeer het op https://hexatransfer.com — gratis, geen account, maximaal 10 GB.