Zero-Knowledge Proof in Prześlij plików Systems

Dowody zero-knowledge pozwalają jednej stronie udowodnić prawdziwość twierdzenia bez ujawniania czegokolwiek poza samą prawdziwością tego twierdzenia. Zastosowane do transferu plików, ZKP umożliwiają nadawcy lub serwerowi udowodnienie, że plik pasuje do oczekiwanego skrótu, że był zaszyfrowany określonym kluczem lub że spełnia warunki polityki — jak „mniejszy niż 10 GB i nieznajdujący się na liście blokowanych złośliwego oprogramowania" — bez ujawniania zawartości pliku. CSIRT NASK, krajowy CERT obsługujący incydenty cyberbezpieczeństwa w Polsce, wskazuje weryfikację integralności danych przesyłanych między podmiotami jako jeden z kluczowych obszarów ochrony. Technologia ta, sformalizowana przez Goldwassera, Micali i Rackoffa w 1985 roku, a teraz praktyczna dzięki zk-SNARKom (Groth16, PLONK) i zk-STARKom, przechodzi z kryptowalut do systemów transferu plików z zachowaniem prywatności.

Co oznacza „zero-knowledge" w tym kontekście

Dwa zastosowania kolidują w marketingu. Pierwsze to formalne znaczenie kryptograficzne: interaktywny lub nieinteraktywny protokół udowadniający wiedzę o świadku bez ujawniania go, zgodnie z heurystyką Fiata-Shamira i nowoczesnymi konstrukcjami zk-SNARK jak Groth16 (2016) i PLONK (2019). Drugie to luźniejsze znaczenie komercyjne, gdzie „zero-knowledge" oznacza, że dostawca usług nie może odszyfrować danych użytkownika, bo nie posiada kluczy — tak jak Proton, Tresorit czy Sync.com. Oba są zasadne, ale rozwiązują różne problemy. Znaczenie komercyjne to właściwie szyfrowanie end-to-end po stronie klienta; znaczenie kryptograficzne otwiera nowe przepływy pracy niemożliwe przy samym E2EE.

Dowody integralności pliku bez ujawniania treści

Wyobraź sobie scenariusz ujawnienia dokumentów sądowych. Strona odpowiadająca przekazuje zaszyfrowane pliki i chce udowodnić kompletność — że nic nie zostało wstrzymane — bez ujawniania treści. Zobowiązanie drzewa Merkle połączone z dowodem zero-knowledge może wykazać, że każdy plik z uzgodnionego indeksu jest obecny, prawidłowo zhashowany i zaszyfrowany wspólnym kluczem. Strona odbierająca weryfikuje dowód w milisekundach bez widzenia treści aż do odszyfrowania. Narzędzia zbudowane na Halo 2, Circom i Plonky2 pozwalają obwodom wyrażającym te twierdzenia działać po stronie klienta w przeglądarkach przez kompilację WebAssembly.

Selektywne ujawnianie dla zgodności z przepisami

Lekarz wysyłający badanie DICOM pacjenta do drugiej opinii może chcieć udowodnić, nie ujawniając tożsamości, że nadawca jest licencjonowanym lekarzem w podmiocie objętym HIPAA. Dowód poświadczeń zero-knowledge przy użyciu modelu danych W3C Verifiable Credentials v2.0 z podpisami BBS+ może to osiągnąć. Odbiorca weryfikuje poświadczenia nadawcy bez poznawania imienia ani instytucji. Ten sam wzorzec ma zastosowanie do zgodności z kontrolą eksportu: udowodnij, że kraj docelowy pliku jest zatwierdzony bez ujawniania pliku ani dokładnego miejsca docelowego.

Dowód uploadu bez zaufania do serwera

Częsty problem w transferze plików: nadawca wysyła plik, serwer twierdzi, że go odebrał — ale jak nadawca może udowodnić, co faktycznie zostało przechowane? Protokoły oparte na proof-of-retrievability (PoR) i proof-of-data-possession (PDP), sformalizowane przez Juels-Kaliski (2007) i Ateniese i in. (2007), pozwalają serwerowi udowodnić, że przechowuje kompletny plik, odpowiadając na losowe wyzwania kryptograficznymi dowodami. Zdecentralizowany storage jak Filecoin używa tych mechanizmów do udowadniania, że dostawcy przechowują deklarowane dane. Dla scentralizowanej usługi transferu, PoR daje nadawcy pewność bez zaufania do logów audytu.

Prywatne przecięcie zbiorów dla deduplikacji

Usługi transferu plików często deduplikują identyczne pliki po stronie serwera, by zaoszczędzić storage. Naiwnie wykonane, ujawnia to informacje: dwóch użytkowników wysyłających ten sam plik odkrywa siebie nawzajem. Protokoły Private Set Intersection (PSI) używające oblivious pseudorandom functions (OPRF) lub szyfrowania filtra Blooma pozwalają serwerowi kryptograficznie wykrywać duplikaty, podczas gdy żadna ze stron ani serwer nie dowiaduje się, które konkretne pliki pasowały. Biblioteki PSI jak Microsoft APSI i implementacja PSI Google działają w przeglądarkach przez WASM. Dotyczy to szczególnie systemów E2EE, gdzie serwerowa deduplikacja w innym przypadku złamałaby model zagrożeń.

Udowadnianie zgodności z polityką bez ujawniania ładunku

Enterprise systemy transferu często uruchamiają skanery DLP (Data Loss Prevention), by zablokować uploady zawierające numery PESEL, numery kart kredytowych lub znaki zastrzeżone. Dowód DLP zero-knowledge pozwoliłby nadawcy udowodnić „Ten plik nie zawiera 16-cyfrowych ciągów pasujących do wzorców kart kredytowych ważnych według algorytmu Luhna" — bez ujawniania pliku serwerowi DLP. Obwody w Circom lub Noir mogą wyrażać te sprawdzenia. Wydajność jest wąskim gardłem: udowodnienie, że plik 100 MB spełnia złożoną politykę, może zająć minuty. Badania w GKR i schematach składania jak Nova (2022) znacznie skracają czas dowodzenia.

zk-SNARKi kontra zk-STARKi dla plików

zk-SNARKi (Succinct Non-interactive Arguments of Knowledge) jak Groth16 i PLONK produkują małe dowody (200 do 500 bajtów) weryfikowalne w milisekundach, ale wymagają ceremonii zaufanego ustawienia. zk-STARKi (Scalable Transparent Arguments of Knowledge), używane w systemach produkcyjnych StarkWare, nie potrzebują zaufanego ustawienia i opierają się wyłącznie na funkcjach skrótu, co czyni je bezpiecznymi post-kwantowo, ale dowody są większe (50 KB do kilku MB). Dla transferu plików, dowody SNARK dobrze mieszczą się w nagłówkach HTTP lub małych polach metadanych, podczas gdy dowody STARK są bardziej obszerne, ale unikają założeń zaufania.

Budżety wydajności dla dowodzenia w przeglądarce

Generowanie dowodu, że plik 1 MB pasuje do określonego skrótu, zajmuje od 100 ms do 2 sekund w przeglądarce przy użyciu Halo 2 lub snarkjs skompilowanego do WASM, w zależności od rozmiaru obwodu i urządzenia. Dla dowodów integralności pliku w czasie transferu jest to akceptowalne. Dla bardziej złożonych twierdzeń jak zgodność z polityką nad dużymi plikami, dowodzenie może wymagać odciążenia do serwera lub uruchomienia w tle przez Service Workers. Web Crypto API obsługuje standardowe prymitywy hashowania z natywną prędkością, ale niestandardowe obwody ZK nadal płacą narzut interpretacji WASM.

Wzorce integracji z istniejącym E2EE

ZKP dobrze nakładają się na E2EE zamiast go zastępować. Typowy wzorzec: nadawca szyfruje plik za pomocą AES-256-GCM, oblicza skrót SHA-256 oryginalnego tekstu i generuje dowód zobowiązujący do tego skrótu. Serwer przechowuje szyfrogram, zobowiązanie i dowód. Odbiorca pobiera wszystkie trzy, odszyfrowuje, ponownie hashuje oryginalny tekst i weryfikuje dowód. To wykrywa manipulacje i zapewnia przenośne potwierdzenie integralności, które odbiorca może pokazać osobie trzeciej — na przykład regulatorowi — bez ujawniania pliku.

Gdzie ZKP pasują dziś, a gdzie nie

Dziś ZKP sprawdzają się dobrze dla zwartych twierdzeń o integralności i autentyczności, deduplikacji bez ujawniania i dostępu opartego na poświadczeniach do punktów końcowych transferu. Nie pasują jeszcze do ogólnych sprawdzeń uwzględniających treść na dużych plikach — czas dowodzenia i rozmiar dowodu jeszcze na to nie pozwalają. Dla codziennej prywatności transferu plików, E2EE po stronie klienta z AES-256-GCM i wymianą klucza X25519, jak stosowane w HexaTransfer, dobrze obsługuje typowy model zagrożeń bez złożoności obwodów ZKP. Oczekuj pierwszych produkcyjnych funkcji transferu plików wzbogaconych o ZK — prawdopodobnie dowodów integralności i deduplikacji opartej na PSI — w latach 2027 do 2028.

Wypróbuj bezpłatnie na hexatransfer.com — bez konta, maksymalnie 10 GB.