Zero-Knowledge Proof in ファイル転送 Systems

ゼロ知識証明（ZKP）とは、ある命題が真であることを、その命題の真実以外の何も明かさずに証明できる技術だ。ファイル転送に応用すると、送信者やサーバーはファイルの内容を開示せずに、ファイルが期待するハッシュと一致すること、特定の鍵で暗号化されていること、または「10GB未満でマルウェアブロックリストに載っていない」といったポリシーを満たすことを証明できる。この技術は1985年にGoldwasser、Micali、Rackoffによって定式化され、現在ではzk-SNARKs（Groth16、PLONK）とzk-STARKsにより実用化され、暗号資産からプライバシー保護型ファイルシステムへと展開している。個人情報保護委員会（PPC）が示すプライバシーバイデザインの原則とも整合する技術的アプローチだ。

この文脈での「ゼロ知識」の意味

マーケティングで2つの用法が混在している。第一は正式な暗号学的意味：Fiat-Shamir変換とGroth16（2016年）、PLONK（2019年）のような現代のzk-SNARKの構成に定義されている、証人を明かさずにその知識を証明するインタラクティブまたは非インタラクティブなプロトコル。第二はより緩い商業的意味：Proton、Tresorit、Sync.comが使う「ゼロ知識」のように、鍵を持っていないためサービスプロバイダーがユーザーデータを復号できないことを指す。どちらも有効だが、異なる問題を解決する。商業的な意味は実質的にクライアントサイドのエンドツーエンド暗号化であり、暗号学的な意味はE2EEだけでは不可能な新しいワークフローを開く。

開示なしのファイル整合性証明

法的な証拠開示のシナリオを想像してほしい。応答者が暗号化されたファイルを引き渡し、内容を明かさずに完全性——何も差し控えていないこと——を証明したい。Merkleツリーコミットメントとゼロ知識証明の組み合わせにより、合意されたインデックス内のすべてのファイルが存在し、正しくハッシュされ、共有鍵で暗号化されていることを実証できる。受信者は内容を見ることなくミリ秒で証明を検証する。Halo 2、Circom、Plonky2の上に構築されたツールは、これらの命題を表現する回路をWebAssemblyにコンパイルしてブラウザで実行できる。

コンプライアンスのための選択的開示

医師が2番目の意見を求めてDICOM画像を送る場合、身元を明かさずに自分がHIPAAの対象機関に所属する認定医師であることを証明したいかもしれない。W3C Verifiable Credentials Data Model v2.0とBBS+署名を使ったゼロ知識クレデンシャル証明はこれを実現する。受信者は送信者の名前や機関を見ることなく資格を検証する。輸出管理コンプライアンスでも同様のパターンが適用できる。ファイルや正確な宛先を開示せずに、宛先国が承認済みであることを証明する。経済産業省（METI）の輸出管理規制に関するプライバシー保護型のワークフローに有用だ。

サーバーを信頼せずにアップロードの証明を得る

ファイル転送でよくある問題：送信者がファイルをアップロードし、サーバーが受信したと主張するが、サーバーサイドで実際に何が保存されたかをどうやって証明できるか。Juels-Kaliski（2007年）とAteniese et al.（2007年）によって定式化されたproof-of-retrievability（PoR）とproof-of-data-possession（PDP）のプロトコルにより、サーバーはランダムなチャレンジに暗号証明で答えることで完全なファイルを保有していることを証明できる。Filecoinなどの分散ストレージはこれを使ってストレージプロバイダーがデータを保有しているか確認する。中央集権型の転送サービスでも、PoRは監査ログへの信頼なしに送信者に確信を与える。

重複排除のためのプライベートセット積分

ファイル転送サービスは多くの場合、ストレージを節約するためにサーバーサイドで同一ファイルを重複排除する。素朴に行うと情報が漏洩する：同じファイルをアップロードした2人のユーザーが互いを発見してしまう。Oblivious pseudorandom functions（OPRF）やBloom filter暗号化を使ったPrivate Set Intersection（PSI）プロトコルにより、サーバーはどちらのパーティもサーバーも具体的にどのファイルが一致したか知ることなく、暗号学的に重複を検出できる。MicrosoftのAPSIやGoogleのPSI実装などのPSIライブラリはWASMを通じてブラウザで動作する。これはE2EEシステムにとって重要で、サーバーサイドの重複排除が脅威モデルを壊す可能性がある。

ペイロードを開示せずにポリシー準拠を証明する

企業の転送システムは多くの場合、マイナンバー、クレジットカード番号、機密マーキングを含むアップロードをブロックするためDLP（データ損失防止）スキャンを実行する。ゼロ知識DLP証明は、「このファイルにはLuhnアルゴリズムで有効な16桁の文字列が含まれていない」とDLPサーバーにファイルを開示せずに証明させる。CircomやNoir内の回路はこれらのチェックを表現できる。パフォーマンスがボトルネックだ：100MBのファイルが複雑なポリシーを満たすことの証明には数分かかり、数MBの証明を生成することがある。GKRやNova（2022年）のような折りたたみスキームの研究は証明時間を大幅に短縮しており、数年以内の実用的な展開が現実味を帯びている。

ファイルへのzk-SNARKs対zk-STARKs

zk-SNARKs（Groth16、PLONKなど）は小さな証明（200〜500バイト）を生成してミリ秒で検証できるが、信頼できるセットアップセレモニーが必要だ。StarkWareの本番システムで使われるzk-STARKsはセットアップ不要でハッシュ関数のみに依存するため、量子後セキュリティを持つが、証明がより大きい（50KB〜数MB）。ファイル転送において、SNARK証明はHTTPヘッダーや小さなメタデータフィールドに収まるが、STARK証明は信頼の前提を避ける代わりにかさばる。実用的なシステムは多くの場合、証明する性質に応じて両方を混在させる。

ブラウザ証明のパフォーマンス予算

1MBのファイルが特定のハッシュと一致する証明の生成は、Halo 2やsnarkjsをWASMにコンパイルしてブラウザで実行した場合、回路サイズとデバイスによって100ms〜2秒かかる。転送時のファイル整合性証明としてはこれは許容範囲内だ。大きなファイルに対するポリシー準拠のような複雑な命題では、証明をサーバーにオフロードするか、OffscreenCanvasとService Workersを使ってバックグラウンドワーカーで実行する必要があるかもしれない。Web Crypto APIはネイティブスピードで標準的なハッシュプリミティブを処理するが、カスタムZK回路はまだWASMインタープリテーションのオーバーヘッド（ネイティブより約2〜5倍遅い）を支払う。

既存のE2EEとの統合パターン

ZKPはE2EEを置き換えるのではなく、その上にきれいに重なる。典型的なパターン：送信者がAES-256-GCMでファイルを暗号化し、平文のSHA-256ハッシュを計算し、そのハッシュにコミットする証明を生成する。サーバーは暗号文、コミットメント、証明を保存する。受信者はすべて3つを取得し、復号し、平文を再ハッシュし、証明を検証する。これにより改ざんが検出され、受信者がファイルを開示せずに規制当局などの第三者に示せる移転可能な整合性の主張が得られる。HexaTransferの日常的なファイル転送プライバシーにはAES-256-GCMとX25519鍵交換によるクライアントサイドE2EEが対応し、ZKP回路の複雑さなしに一般的な脅威モデルを扱う。

https://hexatransfer.com — 無料、アカウント不要、最大10GB。