クライアントサイド暗号化によるPDF共有、正しく理解する。
「エンドツーエンド暗号化」という言葉は曖昧に使われがちです。ここでは、クライアントサイド暗号化PDFリンクの実際の暗号メカニズム — AES-256-GCM、鍵管理、フラグメント対パスフレーズモード、サーバーが文字通りできないこと — を解説します。注記: このページの「ゼロ知識」はサーバーがファイルを復号できる情報を一切保持しないことを指し、正式なゼロ知識証明（ZKP）ではありません。本製品はZKPを使用しません。
「ゼロ知識」がここで意味すること
最初に明確にしておきます: このシステムはゼロ知識証明（ZKP）を使用しません。このページの「ゼロ知識」とは、共有ファイルを保存するサーバーが暗号的にも運用上も復号に使用できる情報を一切持たないという、より弱いが実用的な性質を指します。鍵はサーバーに触れないため、サーバーはいかなる状況でも鍵を開示できません。仕組みは純粋なクライアントサイド暗号化と、URLフラグメントのみで移動する鍵（またはサーバーが見ることのないパスフレーズから導出）です。
window.crypto.subtleを介して実行。DevToolsで確認可能。クライアントサイド暗号化PDFリンクの作成方法
送信者のブラウザ、サーバー、受信者のブラウザがそれぞれ行うことを、実際のWeb Crypto呼び出しと共に解説します。
フラグメントモード対パスフレーズモード
受信者に鍵を届ける2つの方法。暗号文の保証は同一で、使いやすさと漏洩リスクのトレードオフが異なります。
鍵はURLハッシュ（#）に含まれる
最もシンプルな方法: リンクをコピーして受信者のチャットに貼り付けるだけ。#以降のURL部分は、準拠したブラウザによってWebサーバーに送信されることはなく、それが鍵を非公開に保ちます。
- 受信者の操作は1ステップ — リンクをクリックするだけ。
- 摩擦が少なく、低〜中程度の機密性の共有に適しています。
- リスク: スクリーンショットやブラウザ同期でリンクが漏洩すると、ファイルも漏洩します。
- チャンネルを信頼できる場合（署名付きメッセンジャー、社内チャット）に使用。
パスフレーズから鍵を導出（PBKDF2）
送信者がパスフレーズを設定します。ブラウザは128ビットのランダムソルトに対してPBKDF2-SHA256を310,000回繰り返して256ビット鍵を導出します。ソルトはサーバー側に保存され、パスフレーズは帯域外（電話、Signal、対面）で共有されます。
- 2要素共有: リンクとパスフレーズを別々に送付。
- リンクだけでは不十分 — 暗号文は読み取り不可能のまま。
- パスフレーズの強度が重要: 310k回の繰り返しでブルートフォースを遅らせますが、6文字のパスフレーズを救うことはできません。
- リンクが転送されたり、完全に信頼できない場所に保存される可能性がある場合に使用。
| 項目 | フラグメントモード | パスフレーズモード |
|---|---|---|
| 鍵の搬送手段 | URLハッシュ（#） | パスフレーズ + ソルト |
| サーバーが鍵を見るか | いいえ | いいえ |
| サーバーが保存するもの | 暗号文 + IV | 暗号文 + IV + ソルト |
| 受信者の手間 | リンクをクリック | リンクをクリック + パスフレーズを入力 |
| スクリーンショットで漏洩可能か | はい（リンク = 鍵） | いいえ（リンクだけでは無意味） |
| ブルートフォース耐性 | 256ビットランダム | パスフレーズ次第 |
| 最適な用途 | 信頼できるチャンネルでの低摩擦共有 | より高い機密性が必要な共有 |
サーバーに暗号文を保存してもプライバシーが守られる理由
「サーバーにあるなら、どうしてプライベートなの？」とよく聞かれます。答えは、暗号文はファイルではないということです。鍵がなければ、ランダムに見えるバイト列にすぎません。実際にどういう意味かを解説します。
warning正直な制限事項
クライアントサイド暗号化はエンドポイントセキュリティの問題を解決しません。送信者または受信者のデバイス上のマルウェアはメモリから鍵を盗むことができます。侵害されたブラウザ拡張機能は復号されたファイルを読むことができます。そして、グループチャットで転送されたリンクはあらゆる暗号保証を無効にします。このアーキテクチャは侵害のコストを高めますが、すべてのリスクを排除するわけではありません。
クライアントサイド暗号化と他の「安全な」オプションの比較
PDFを共有する一般的な選択肢の明確な比較。「安全」とラベル付けされたオプションのほとんどはトランスポート暗号化であり、転送中のデータを保護しますが、受信サーバーは引き続き平文と鍵を保持します。
| オプション | 転送中のTLS | サーバーがファイルを読めるか | 有効期限 | 受信者アカウント |
|---|---|---|---|---|
| メール添付 | 通常はい | はい — すべての中継点で | 永久 | 不要 |
| 汎用クラウド共有リンク | はい | はい | 任意 | 場合による |
| パスワード保護PDF | はい | はい（ホストがファイルを持つ場合） | なし | 不要 |
| PDF Pro（フラグメントモード） | はい | いいえ | 24時間 / 30日 | 不要 |
| PDF Pro（パスフレーズモード） | はい | いいえ | 24時間 / 30日 | 不要 |
関連資料
信頼が必要な共有 対 ゼロ知識 ライブ対決
同じ目標 — PDFを共有する。2つの信頼モデルが並んで進む様子をご覧ください。
- PDFをサーバーにアップロード
- サーバーが平文を保持平文
- サーバーが削除を約束信頼
- 相手側での侵害リスクリスク
- 受信者が平文をダウンロード露出
- ブラウザ内でPDFを暗号化E2E
- サーバーは暗号文のみを保持ゼロ知識
- 受信者がローカルで復号完了
よくある質問
クライアントサイド暗号化PDF共有とは実際どういう意味ですか？
PDF Proはクライアントサイド暗号化共有にどの暗号化を使用しますか？
フラグメントモードとパスフレーズモードの違いは何ですか？
#以降）に入れ、ブラウザはいかなるサーバーにも送信しません。完全なリンクを持つ人は誰でも復号できます。パスフレーズモードは送信者が設定したパスフレーズから鍵を導出し、それなしでは暗号文は読み取り不可能なままです。リンクが漏洩する場合はパスフレーズモードが安全です。低摩擦共有にはフラグメントモードが便利です。上記の比較表をご参照ください。URLフラグメントは暗号鍵の搬送手段として本当に安全ですか？
#以降）をサーバーに送信しません。クライアントサイドに留まり、受信者のタブで実行されるJavaScriptにのみ表示されます。それが共有リンク自体を復号認証情報にする理由です — 鍵はアップロードではなく受信者と共に移動します。ブラウザのネットワークタブで確認できます: リクエストURLは?または#で切り捨てられています。