P2P vs サーバー転送：どちらがより安全か？

P2P とサーバーベースの転送のどちらが本質的に安全かという問いへの答えは、「どちらでもない」です。セキュリティはトポロジーではなく暗号化モデルに依存します。ゼロ知識 AES-256-GCM 暗号化を持つ適切に実装されたサーバー転送は、機密性の観点で P2P と区別できません。どちらの方式でも、サーバーが見るのは暗号文だけです。 P2P はメタデータのプライバシー（第三者が転送の存在を知らない）という利点を加えますが、可用性、 NAT トラバーサル、認証の課題をもたらします。サーバーベースのサービスは信頼性と受信者の利便性に優れています。「 P2P の方が安全」という直感ではなく、脅威モデルと受信者の環境に基づいて選んでください。

2 つのモデルの実際の動作

サーバー転送はファイルを仲介者（ S3 、 OVH 、 Backblaze B2 、 Cloudflare R2 でバックアップされたオブジェクトストレージ）にアップロードし、リンクを返します。受信者は同じ仲介者からダウンロードします。ファイルはどちらの当事者も管理しないサーバーに一時的に存在します。サーバーがエンドツーエンド暗号化を使用していれば、暗号文だけを保持します。

P2P 転送は送信者と受信者の間に直接接続を確立します。通常は WebRTC のデータチャネル経由です。ファイルは永続サーバーに触れません。シグナリングサーバー（接続情報を交換するため）と、 NAT トラバーサルのための TURN リレーのみを使います。 Wormhole.app （実際には E2EE 付きサーバーを使用）、 ToffeeShare 、 FilePizza 、そして大規模共有向けのクラシックな BitTorrent がその例です。

「ピアツーピア」という言葉はスペクトルをカバーします。真の P2P は送信者のデバイスが受信者のデバイスに直接接続することを意味します。現実の WebRTC P2P は直接接続が失敗したときに TURN リレーにフォールバックすることが多く、その時点では一時的なサーバー転送に近くなります。

機密性の問題

両方のモデルが AES-256-GCM を使用し、サーバーが決して見ないキーを使うなら、機密性は同等です。ファイルの内容はどちらのケースでもキーなしには誰も読み取れません。

違いはメタデータにあります。サーバー転送は「ユーザー X が時刻 T にサイズ Y のファイルをアップロードし、ユーザー Z がダウンロードした」という情報を記録します。 P2P 転送が明らかにするのは、 2 つの IP アドレスが短時間通信したという事実だけです。中央でログされたファイルサイズなし、ユーザー間のタイミング相関なし。メタデータが重要な脅威モデル — 調査報道、内部告発、敵対的な国家における活動 — では、 P2P のより小さなメタデータフットプリントが実際に意味を持ちます。

「ファイルを攻撃者に漏らしたくない」という脅威モデルには、クライアントサイド E2EE を持つサーバー転送で十分です。

可用性の非対称性

サーバー転送は保存期間内であれば常にアクセス可能です。一度アップロードすれば、受信者は次の 7 日間いつでも任意のデバイスからダウンロードできます。送信者はノートパソコンを閉じて休暇に行っても構いません。

P2P は両当事者が同時にオンラインである必要があります（直接接続の場合）か、結局一時的なサーバーになるリレーを使う必要があります。 WebRTC 経由で受信者のノートパソコンに 4 GB のファイルを送っているときに受信者のマシンが 20 % 地点でスリープすると、転送は失敗します。再試行するには受信者と調整が必要です。

非同期ワークフロー — フリーランサーが別のタイムゾーンでクライアントが眠っている間にファイルを届ける — にはサーバー転送の方が実用的です。

NAT とファイアウォールの現実

WebRTC の NAT トラバーサルは ICE（ Interactive Connectivity Establishment ）を使い、 STUN でパブリック IP を検出し、直接接続できないときは TURN でリレーします。企業のファイアウォール、厳密な NAT 、モバイルネットワーク上のキャリアグレード NAT 、ゲスト Wi-Fi は、 WebRTC をブロックするか機能不全に陥らせることが多くあります。実測テストでは、実世界の試みの約 15〜20 % で P2P 接続が完全に失敗するか TURN にフォールバックします。

サーバー転送はポート 443 上の通常の HTTPS を使います。 HTTPS が機能する場所、つまりブラウザが機能するすべての場所で動作します。 ICE も STUN も TURN もファイアウォールの問題もありません。

直接比較

| 項目 | P2P 転送（ WebRTC ） | サーバー転送（ E2EE ） | |---|---|---| | 機密性 | エンドツーエンド暗号化 | エンドツーエンド暗号化 | | メタデータ漏洩 | 低い（シグナリングのみ） | 中程度（サーバーがサイズ・時刻を記録） | | 受信者の利便性 | 双方がオンライン必要 | 非同期ダウンロード可能 | | NAT ・ファイアウォール適合性 | 15〜20 % 失敗の可能性 | HTTPS が使える場所すべてで動作 | | 最大実用ファイルサイズ | 理論上無制限、スケールで不安定 | サービス依存（無料で 2〜50 GB ） | | 再開サポート | まれ | 標準（ tus.io 、チャンク） | | 複数受信者 | 各人に再送信 | 1 リンクで複数ダウンロード | | サーバーコスト | 最小（シグナリングのみ） | ストレージ＋帯域幅 | | 信頼の前提 | WebRTC クライアントコードを信頼 | E2EE 実装を信頼 |

P2P が真に優れる場面

同じタイムゾーンにいる 2 人の技術的なユーザーが、協調的なネットワーク環境で大容量の単発転送を行う場合です。 50 GB の .iso を同僚に送る開発者で、双方が自宅の光ファイバー接続を使っており、双方ともブラウザを開いているなら、 P2P はアップリンクを飽和させる時間で完了し、サーバーコストはゼロです。

メタデータに敏感なシナリオも P2P の恩恵を受けます。内部告発者からソースファイルを受け取るジャーナリストは、サードパーティのサーバーに転送の記録が残らないことに価値を見出します。サーバー上の E2EE であっても、転送の存在とサイズは記録されます。

1 つのファイルを何千もの受信者に配布する BitTorrent スタイルの配布は、モデルがエレガントにスケールする別の P2P ユースケースです。帯域幅の負担がスウォーム全体に分散されます。典型的な 1 対 1 や 1 対少数の転送には関係しませんが、注目に値します。

サーバー転送が勝る場面

ほぼすべての通常のファイル配信です。送信者は一度アップロードして離れます。受信者は自分のスケジュールでダウンロードします。ホテルの Wi-Fi やモバイルデータを含む任意のネットワークから機能します。複数の受信者が同じリンクを使えます。保存期間の管理は自動です。

サーバー転送は信頼性でも勝ります。 2.8 GB で失敗した 3 GB のアップロードは、 tus.io チャンクアップロードを使うサーバーでは 2.8 GB から再開します。 2.8 GB で失敗した P2P 転送は通常ゼロから再開します。ブラウザベースの WebRTC 実装が進捗をチェックポイントすることはほとんどありません。

「サーバーを使わない」というマーケティングの主張

一部の P2P ツールは「ファイルは私たちのサーバーに触れない」と主張しますが、これは部分的にしか正確ではありません。シグナリングサーバーは SDP オファーと ICE 候補を交換します。ファイル自体ではありませんが、接続を確立するのに十分なメタデータです。 TURN リレー（使用時）は暗号化されたファイルストリームをプロバイダーのインフラ経由で短時間転送します。

一方、クライアントサイドの AES-256-GCM で適切に実装されたゼロ知識サーバー転送は、同じ機能的主張ができます。「私たちのサーバーはファイルの内容を決して見ない。」暗号文はストレージを通過しますが、平文は送信者と受信者のデバイスにのみ存在します。「ファイルのビットが私たちのインフラを通過しない」と「インフラを通過するものを復号できない」の区別は本物ですが、マーケティングが示唆するほど大きくないことが多いです。

認証と受信者の確認

どちらのモデルも受信者認証を自動で解決しません。どちらも通常「リンクを持つ誰でもファイルを受け取れる」に依存し、オプションでパスワードを追加できます。真の受信者認証（このファイルを実際に Alice が受け取ったか、それとも彼女へのメールを傍受した誰かが受け取ったか）には、帯域外チャネルが必要です。 Signal でパスワードを共有する、電話で受け取りを確認するなどの手段です。

サーバーサービスはダウンロード通知でこれを容易にします。リンクが使用されたときに webhook やメールで送信者に通知されます。 P2P も送信者の UI からこれを提供できますが、セッション中のみです。

トポロジーより実装品質が重要

認証済みのキー交換なしに ECDH を使うずさんな P2P ツールは、検証済みピア証明書付きの X25519 を使う慎重なサーバーベースツールに負けます。 CBC モードの AES-128 を使うサーバーツールは、 AES-256-GCM を使う P2P ツールに負けます。トポロジーよりも暗号化を正しく実装することの方が重要です。

HexaTransfer は URL フラグメント内のキーを使うクライアントサイドの AES-256-GCM 、トランスポート用の TLS 1.3 、暗号文だけを保持するサーバーストレージを採用しています。サーバートポロジーでありながら、ファイルの内容に関しては P2P と同等の機密性を持ちます。

結論

P2P のセキュリティ上の優位性は主にメタデータのプライバシーに関するもので、ファイルの機密性についてではありません。フリーランサー、中小企業、クライアントに成果物を届けるクリエイターなど、ほとんどのユーザーにとって、ゼロ知識暗号化を持つサーバー転送は、意味のある機密性の低下なしに信頼性、利便性、互換性で勝ります。 P2P が適しているのは、メタデータのプライバシーが絶対要件であるとき、または両当事者が同時にオンラインでファイルがサーバーの無料プランには大きすぎるときです。

hexatransfer.comでお試しください — 無料、登録不要、最大10GB。