ファイルを封印する前に受信者を検証する

機微なファイルを封印する前に、攻撃者が支配しにくいチャネルを通じて受信者の受信アドレスを検証してください。受信アドレスは公開鍵であって、名前ではありません。間違った鍵に対して暗号化すると、その間違った鍵の保有者がファイルを開けてしまうかもしれません。そして、本来届けたかった相手は開けないかもしれません。

これは、暗号化されたワークフローで最もよく起こる人為的な失敗です。暗号自体は完璧でも、送り先を間違えれば送信そのものが誤りになります。文字列を見ただけでは、それが誰の鍵なのかは何も証明されないからです。暗号化が答えるのは「このバイト列を誰が開けるか」という問いです。「自分は正しい相手を選んだのか」という問いには答えません。

受信アドレスとは何か

受信アドレスとは、送信者がレコードを封印するために使う暗号化の公開鍵です。CardanoWall では、次の 2 つの形式があります。

age1...（古典的な X25519 受信アドレス）。
age1pqc...（ハイブリッドのポスト量子受信アドレス）。

送信者は、受信者が公開したアドレスに対して封印します。受信者は、対応する秘密鍵でレコードを開封します。この秘密鍵は受信者の Identity Seed から導出されます。アドレスは共有するためのものであり、秘密鍵と Identity Seed は秘密に保たれなければなりません。（アドレスとは何か、受信者がどのようにそれを渡すかについては、受信アドレスとは何かを参照してください。）

鍵の検証がこれほど重要なのはなぜか

公開鍵はアイデンティティではないからです。

受信アドレスのように見える文字列は、誰でも送りつけられます。見慣れた表示名の隣に鍵を貼り付けることも、誰にでもできます。文字列そのものは、対応する秘密鍵を誰が支配しているかを何も証明しません。証明されるのは「いずれかの鍵保有者が支配している」ということだけです。自分のアドレスをそっと紛れ込ませた攻撃者は、連絡先「宛て」に封印したものすべてを読めてしまい、その一方で本来の連絡先には何も届きません。

使い捨てのテストファイルなら、それは問題にならないかもしれません。しかし、法的証拠、インシデントデータ、個人情報、未公開の作品、あるいは内部告発の資料については、封印する前に鍵を検証してください。アドレス帳は、その検証を定着させるために存在します。鍵を一度確認して保存し、毎回あらためて信頼し直さなければならない文字列を貼り直す代わりに、保存した項目を再利用するのです。

良い検証チャネルとは何か

攻撃者が支配しにくい経路を使い、鍵を届けてきたチャネルとは別のチャネルで鍵を確認してください。妥当な選択肢を、おおむね強度の高い順に挙げます。

対面での受け渡し（たとえば、一緒に QR コードをスキャンする）。
すでに知っている番号への電話で、鍵のフィンガープリントを読み上げる。
受信者の公式ドメイン上にある .well-known の鍵ページ。
そのドメインの DNS TXT レコード。
受信者の公式サイトからリンクされた署名済みプロフィール。
すでに信頼しているエンドツーエンド暗号化された会話。
組織が承認した鍵ディレクトリ。
信頼できるプロセスを通じて届けられた、印刷された鍵のフィンガープリント。

適切な方法は、何を送ろうとしているかによって変わります。価値の高いファイルの場合は、独立した 2 つのチャネルで確認してください。メールで届いた鍵を電話でも読み合わせれば、どちらか一方だけよりも偽造がはるかに難しくなります。

それだけでは不十分なものは何か

見慣れた名前だけでは不十分です。次のものは、第 2 のチャネルで確認されるまでは未検証として扱ってください。

まったく新しいメールスレッドで届いた鍵。
検証していないアカウントからのダイレクトメッセージ。
鍵のスクリーンショット。
その人物への信頼できるリンクのない公開プロフィール。
第三者から転送されてきたアドレス。
第 2 のチャネルでの確認がない「これが私の新しい鍵です」というメッセージ。

攻撃者は鍵交換の瞬間に狙いを集中させます。すり替えられた鍵がまったく正常に見える唯一の段階だからです。いったん間違った鍵を保存してしまうと、その後のすべての送信が、気づかれないまま間違った宛先に届き続けかねません。

アドレス帳はどう使えばよいか

鍵を検証した後に保存してください。決して検証の前に保存してはいけません。信頼できる連絡先ごとに、アドレス帳は次の情報を記録します。

表示名。
その連絡先の Ed25519 署名公開鍵（レコードをその人物に結びつける識別子）。
age1... 受信アドレス（あれば）。
age1pqc... ポスト量子受信アドレス（あれば）。
鍵をどのように検証したか、そしていつ検証したか。
自由記述のメモ。どのように確認したかを正確に書き留めてください。

後で封印付きレコードを作成するときは、アドレスをあらためて貼り付けるのではなく、アドレス帳から連絡先を選びます。これにより、一度の入念な検証が、より安全な多くの送信へとつながります。アドレス帳の作り方の手順については、アドレス帳を作成するとアドレス帳の仕組みを参照してください。

ポスト量子アドレスを優先すべきか

長年にわたって機微であり続ける可能性のあるファイルについては、はい、優先してください。受信者がポスト量子アドレスを提供している場合は、それを使ってください。

ハイブリッドの age1pqc... アドレスは古典的なものよりはるかに長いですが、今日のうちに封印された暗号文を記録しておき、将来の量子コンピューターで後から復号しようとする攻撃者（「harvest now, decrypt later」）から保護します。レコードが近い将来までしか秘密に保たれる必要がない場合は、古典的な age1... アドレスでたいてい十分です。

どちらを選ぶにしても、原則は変わりません。まずアドレスを検証してください。検証していないポスト量子鍵は、検証していない古典的な鍵より安全になるわけではありません。

受信者が鍵をローテーションしたらどうするか

新しい鍵は、新しい連絡先であるかのように検証してください。鍵が変わったとメッセージが主張するだけで、保存済みの受信アドレスを上書きしてはいけません。それはまさに鍵すり替え攻撃が取る形だからです。新しい鍵を信頼できるチャネルで確認し、項目を更新し、なぜ変わったのかを書き留めてください。

チームや組織では、鍵のローテーションは予測可能な場所で告知されるべきです。公式ドメイン、署名済みプロフィール、あるいは文書化された内部プロセスなどです。鍵が侵害されたと疑われる場合は、古いアドレスへの封印を直ちにやめ、新しいアドレスが確認されるのを待ってください。

読み取れる受信者の一覧ではありません。Label 309 の封印付きレコードは、コンテンツ鍵を受信者ごとに暗号化された 1 つのスロットへとラップし、それらをシャッフルします。そのため、公開されるレコードには平文の「受信者」フィールドが含まれません。受信トレイは、各スロットをご自分の鍵でローカルに試行復号（trial-decrypt）することで、自分宛てのレコードを見つけます。観測者に見えるのは、封印付きレコードが存在すること、いつ公開されたか、いくつのスロットを持つかだけであり、受信者が誰なのかは決して見えません。

この受信者ブラインド性はオンチェーンのプライバシーを保護しますが、鍵の検証については何の役にも立ちません。チェーンは「誰に」封印したかを隠しますが、「正しい」鍵に封印したかどうかは確認できません。正しいアドレスを選ぶことは、依然として完全に送信者の仕事です。そして、反対側にある限界にも注意してください。封印は鍵保有者に対して平文を暗号化されたままに保ちますが、匿名性を保証するものではなく、いったん復号した受信者は誰でも平文を漏らせます。（証明が何を立証でき、何を立証できないかについては、証明が証明しないことを参照してください。）

要点

良い暗号化に悪い鍵チェックが組み合わさっても、やはり悪い送信です。ですから、次のようにしてください。

機微なものを封印する前に受信アドレスを検証してください。できれば 2 つのチャネルで。
検証した鍵をアドレス帳に保存してください。それぞれをどのように確認したかを書き留めてください。
鍵が変わったら再検証してください。新しい鍵は、まったく新しい連絡先のように扱ってください。

暗号は簡単な部分です。検証こそ、ご自分が担う部分です。