エンドツーエンド暗号化とは：初心者向け完全ガイド

エンドツーエンド暗号化（E2EE）とは、ファイルを送信者のデバイス上で暗号化し、受信者だけが復号できる鍵を使って保護する仕組みです。転送サービスは暗号文を中継するだけで、復号鍵を一切保持しません。そのため、サービス提供者のスタッフ・ハッカー・政府の令状があっても内容を読むことは技術的に不可能です。実際には、ブラウザが256ビットの AES 鍵をランダムに生成してファイルをローカルで暗号化し、暗号文をアップロードしたうえで、鍵は共有リンクの # 以降のフラグメントに埋め込まれます。ブラウザはフラグメントをサーバーに送信しない仕様になっています。これが E2EE の核心であり、真のプライバシー保護とマーケティングの言葉を分ける境界線です。

「エンドツーエンド」が意味すること

「エンド」とはあなたと受信者の二点を指します。その間にある ISP のルーター・CDN エッジ・転送サービスのサーバー・受信者側の ISP はすべて「中間」です。E2EE では、これらの中間地点には暗号化されたバイト列しか届きません。

トランスポート層の暗号化だけ（TLS のみ）の場合と比較してみましょう。TLS はブラウザからサーバーまでの区間を保護しますが、サーバー側でいったん復号されて平文が保存され、ダウンロード時に再暗号化されます。 WeTransfer の標準プランはこの方式です。法的要請があれば、同社はファイルを提供できます。

E2EE であれば、検察が令状を出してもプロバイダーが引き渡せるのはランダムに見えるバイト列だけです。だからこそジャーナリスト・弁護士・医師が E2EE を強く求めるのです。

TLS だけでは不十分な理由

TLS 1.3 は、カフェの攻撃者や悪意ある ISP による盗聴を防ぐという役割において優秀です。しかし TLS はサーバーで終端します。暗号化トンネルが終了した後、サーバーは生のファイルを処理します。そのサーバーが侵害された場合、たとえば2022年に Dropbox のソースコードや顧客データが漏洩した事件のように、保存中のファイルに対して TLS は何の保護も提供しません。

E2EE はサーバーが侵害されても機能し続ける第二の層を加えます。ファイルはネットワークに触れる前に暗号化され、受信者のブラウザで復号されるまで暗号文のままです。データベースのフルダンプが流出しても、見えるのは暗号文とメタデータだけです。

鍵交換の問題とその解決策

E2EE の難点は、サーバーに見られることなく鍵を受信者に届けることです。現代のブラウザベースサービスはこれを URL フラグメントというトリックで解決しています。共有リンクは次のような形をしています。

https://hexatransfer.com/download/abc123#k=base64エンコードされた256ビット鍵

ブラウザは # 以降をクライアント側フラグメントとして扱います。リンクをクリックすると、サーバーへの HTTP リクエストには /download/abc123 だけが含まれ、フラグメントはブラウザの外に出ません。JavaScript がフラグメントから鍵を読み取り、暗号文を取得して Web Crypto API の crypto.subtle.decrypt() でローカル復号します。

RSA 鍵交換や Diffie-Hellman よりもシンプルで、ブラウザがあれば誰でも使えます。トレードオフとして、リンクを持つ人は誰でもファイルをダウンロードできるため、リンク自体を Signal・対面・暗号化メールなど安全なチャンネルで共有する必要があります。

サーバーに見えるものと見えないもの

適切に実装された E2EE では、サーバーログには通常、ランダムなファイルID・暗号文サイズ・アップロード IP・アップロードタイムスタンプ・重複排除用の暗号文の SHA-256 ハッシュが記録されます。サーバーには見えないのは、ファイル名・ファイル内容・受信者の身元・復号鍵です。ファイル名はコンテンツとともに暗号化されて暗号文ヘッダーの一部として保存されることが多くあります。

有用なテストとして、プロバイダーに「令状があれば何を提出するか」と尋ねましょう。誠実な E2EE サービスであれば「暗号化されたバイト列と IP ログ」と答えるはずです。平文ファイルを提示できると言うなら、その暗号化はエンドツーエンドではありません。

内部で動くアルゴリズム

実際の E2EE スタックは、入念に監査された少数のプリミティブに収束します。

AES-256-GCM：ファイルの一括暗号化に使用。GCM は機密性と認証の両方を提供するため、改ざんされた暗号文は復号に失敗します。
PBKDF2（最低10万回以上のイテレーション）または Argon2id：パスワード保護を追加する際の鍵導出に使用。
SHA-256：整合性ハッシュ用。
TLS 1.3：外部トランスポートとして使用。多重防御は安価です。

HMAC なしの AES-CBC（可鍛性あり）・MD5 や SHA-1（解読済み）・1万回未満のイテレーションの PBKDF2（現代の GPU でブルートフォース可能）を使用しているサービスは避けましょう。

ファイル転送とメッセージングの E2EE の違い

Signal はダブルラチェットプロトコルでチャット向け E2EE を普及させました。これはメッセージごとに鍵をローテーションして前方秘匿性を実現します。ファイル転送はワンショット操作のためそこまでの複雑さは必要ありません。アップロードごとに新規生成する単一の対称鍵は、シンプルで監査しやすいという点で優れています。

ファイル転送に必要でメッセージングには不要なものは、再開可能なチャンク分割アップロード（最大10GB）・チャンク間の整合性検証・受信者がアカウントなしで使えるリンクです。Tresorit、Proton Drive、SwissTransfer、HexaTransfer はすべて細部に違いはあれどこのアプローチを採用しています。

サービスが本当にエンドツーエンドか確認する方法

プロバイダーを信頼する前に行う実践的な4つのテストです。

小さなファイルをアップロードしながら DevTools → ネットワークを開き、リクエストボディに平文が見えないか確認する。見えればクライアント側暗号化ではありません。
URL フラグメント（# 以降）に鍵があるか探す。フラグメントに鍵がない場合、サーバーが鍵を保持していることが多いです。
プライバシーポリシーで「当社はファイルにアクセスできません」という記述と、その技術的根拠が示されているか確認する。
クライアントコードが監査可能か確認する。オープンソースであるか、少なくともドキュメント化されているか。クローズドなバイナリで E2EE を主張するサービスには注意が必要です。

4つすべてをパスするサービスとして、SwissTransfer（クライアント側暗号化プラン）・Tresorit Send・Proton Drive 共有リンク・HexaTransfer があります。

E2EE が守れないもの

E2EE は万能ではありません。以下からは守れません。

侵害されたエンドポイント：ラップトップにマルウェアがあれば、暗号化前にファイルを読まれます。
漏洩した共有リンク：リンクを持つ人は誰でもダウンロードして復号できます。
弱いパスワード：PBKDF2 はブルートフォースを遅らせますが、「summer2024」のような単純なものは数秒で解読されます。
メタデータの相関：タイムスタンプ・ファイルサイズ・IP アドレスは依然として情報を伝えることがあります。

E2EE と組み合わせて、有効期限付きリンク（24時間が適切なデフォルト）・ダウンロード回数制限（1〜10回程度）・機密転送用の強力なパスワードを活用しましょう。

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