封印付きレコードを受け取る方法

封印付きレコードを受け取るには、受信アドレスを共有し、あとはソフトウェアにご自分の鍵で開けるレコードを探させるだけです。サーバーが代わりに埋めてくれるメールボックスはありません。クライアントが公開された Label 309 のフィードをスキャンし、封印された各レコードに対して受信鍵を試し、復号に成功したものを表示します。

この発想の逆転こそが、すべての核心です。受信トレイはサーバーから割り当てられるのではなく、復号によって発見されるのです。チェーンが読み取り可能な受信者フィールドを持つことはなく、ゲートウェイがどのレコードがご自分のものかを知る必要もありません。

封印付きレコードとは

封印付きレコードとは、コンテンツを暗号化した存在証明（Proof of Existence）です。

公開されるレコードは依然として平文のハッシュにコミットしているため、その証明は後から「まさにそのコンテンツが、ある公開ブロック時刻までに存在していた」ことを示せます。ファイル自体は暗号化され、その暗号文は Arweave や IPFS のようなコンテンツアドレス指定の保存先に置かれます。チェーン上に置かれることは決してありません。（公開証明の仕組みについては Label 309 の仕組みをご覧ください。）

対応する鍵を持つ人なら誰でも、暗号文を復号し、元のバイト列を復元し、平文のハッシュを再計算して、復号したファイルがオンチェーンのコミットメントと一致することを確認できます。鍵を持たない人には、封印付きレコードが存在することは見えますが、その中身を読むことはできないはずです。

送信者には何を渡せばよいか

送信者に渡すのは受信アドレスだけです。それ以外は何も渡しません。

Label 309 の封印付きレコードでは、受信アドレスには 2 つの形式があります。

• age1… — 従来の X25519 による受信経路。
• age1pqc1… — ハイブリッドのポスト量子受信経路（X25519 を ML-KEM-768 と組み合わせた X-Wing 構成）。

受信アドレスは公開情報であり、共有しても安全です。これがあれば誰かがご自分宛てにレコードを暗号化できますが、できるのはそれだけです。受信アドレスはご自分のアイデンティティから導出されますが、アイデンティティそのものを明かすことはありません。

送信者に Identity Seed（アイデンティティの種）を渡してはいけません。Identity Seed はアイデンティティの秘密の根であり、署名鍵と受信鍵が決定論的に導出される元となる 32 バイトです。これを手にした人は誰でも、ご自分になりすまして署名し、復号できてしまいます。（なぜ Identity Seed こそが本当のバックアップなのかについては、アイデンティティはシードであるをご覧ください。）

送信者はどのようにレコードを作成するのか

封印は送信者側のソフトウェアがローカルで行います。大まかな流れは次のとおりです。

1. 送信者がファイルまたはメッセージを選びます。
2. ソフトウェアが平文のハッシュを計算します。
3. ソフトウェアが使い捨てのコンテンツ鍵を生成し、コンテンツを暗号化します。
4. 受信者ごとに、そのコンテンツ鍵を受信者の受信鍵に対してラップし、受信者ごとのスロットを作成します。
5. 暗号文をコンテンツアドレス指定ストレージ（ar:// など）へアップロードします。
6. Label 309 レコードを Cardano 上に公開し、平文のハッシュと封印エンベロープを載せます。

オンチェーンのレコードがタイミングを証明し、ラップされた鍵スロットを保持します。保存された暗号文が暗号化されたファイルを保持します。ご自分のスロットを開けるのは、ご自分の秘密鍵です。この一連の流れ（ハッシュ・署名・封印・共有）は、ハッシュ・署名・封印・共有で順を追って解説しています。

自分宛てのレコードをクライアントはどう見つけるのか

クライアントは公開レコードをスキャンし、開けるかどうかを試します。

通常のメールボックスを思い浮かべていると、ここは見慣れない部分かもしれません。ホスティング型の受信トレイでは、サーバーがどのメッセージがどのアカウントに属するかを把握し、振り分けます。封印付きの Label 309 レコードには、そのような振り分け情報がありません。エンベロープにはラップされた鍵スロットが並んでいますが、受信者の公開鍵はワイヤー上のどこにも現れません。読み取れる宛先フィールドは存在しないのです。

そこでクライアントは、Label 309 レコードの公開フィードを同期し、封印された各レコードについて、いずれかのスロットがご自分のアイデンティティの受信鍵で開くかどうかを試します。これが**ローカルでの試行復号（trial-decrypt）**です。各スロットのラップを解こうとする試みが、すべてご自分のデバイス上で行われます。スロットが開けば、そのレコードはご自分のものであり、クライアントが受信トレイに追加します。どのスロットも開かなければ、クライアントはそのレコードを無視します。

ささいながら重要な帰結があります。スロットの並び順も何も漏らしません。送信者は公開前にスロットをシャッフルするため、「主たる受信者」の位置すら何の手がかりにもなりません。

試行復号はすべてのファイルをダウンロードする必要があるのか

いいえ。試行復号はオンチェーンのレコードに載ったエンベロープに対して実行されるのであって、保存されたファイルに対してではありません。

ラップされたスロットと小さな認証タグは、レコードのメタデータそのものの中にあります。クライアントは、暗号文を取得する前に、このオンチェーンのバイト列だけからレコードがご自分宛てかどうかを判定でき、コンテンツ鍵も復元できます。これが重要なのは、暗号文が大きくなり得るからです。デスクトップクライアントは、まずどのレコードがご自分のものかを発見し、開いたときに暗号化ファイルを遅延取得したり、設定に応じて事前にキャッシュしたりできます。

オフラインファーストのクライアントにとって、この分離が土台となります。

• 公開レコードフィードを同期する
• エンベロープに対してローカルで試行復号する
• 必要なら一致した暗号文をキャッシュする
• ファイルを開いたタイミングでオンデマンドに復号する
• すでに同期済みのものは、ネットワークなしでも使えるようにしておく

ゲートウェイは実際には何を知っているのか

ゲートウェイが知っているのは、外部の観察者なら誰でも知り得る範囲に、運営しているサービスの運用上の詳細を加えたものです。

ホスティング型のゲートウェイの場合、そこにはアカウントの操作履歴、API の利用状況、見積もりから公開までの流れ、アップロードの操作、残高の状態、ネットワークレベルのインフラ情報、そして誰もが見られる公開レコードのメタデータが含まれ得ます。（この境界の全体像については、CardanoWall に見えるものをご覧ください。）

一方でゲートウェイが必要としないものは、ご自分の Identity Seed、受信用の秘密鍵、そして封印されたコンテンツをご自分の代わりに復号する能力です。ここでのプライバシー特性は「サーバーは何についても一切学習しない」というものではありません。それは正直ではないからです。もっと狭く、もっと有用なものです。すなわち、受信者の照合と復号はローカルで行われるため、読み取り可能な受信者フィールドは公開されず、秘密鍵がゲートウェイに送られることも決してありません。ゲートウェイは設計上、受信者を識別できません。受信者でレコードを絞り込もうとする試みは単に無視されます。絞り込める受信者カラムが存在しないからです。

なぜ公開の受信者フィールドが存在しないのか

公開の受信者フィールドは、ソーシャルグラフを漏らしてしまうからです。

封印付きの各レコードが「誰宛てか」を正確に名指ししていたら、観察者は平文を 1 バイトも読まずに、送信者と受信者の関係を地図のように描き出せてしまいます。秘匿性が求められるワークフロー（情報源が報道機関に接触する、封印された入札、エスクローされた証拠など）では、その露出自体がリスクのすべてになり得ます。

代わりに Label 309 はラップされた鍵スロットを使います。レコードは、意図された鍵保有者だけが開ける暗号化された素材を載せています。観察者には、そのレコードが封印されていることと、スロットがいくつあるかは見えますが、読み取れる受信者リストは見えません。

これは完全な匿名性ではありませんし、そのように売り込むべきものでもありません。スロット数、公開のタイミング、外部のメタデータからは、なお何かが明らかになり得ます。タイミングの相関を打ち消す必要がある送信者は、機微なタイムラインから外して公開しなければなりません。この設計が排除するのは、最もわかりやすい漏えい、すなわち永続的な台帳上の公開受信者カラムです。

複数のアイデンティティを持っている場合は

クライアントは、ロックを解除済みのアイデンティティをそれぞれ試します。

たとえば、個人用のレコードに 1 つ、会社用に 1 つ、法務の受付用に 1 つ、リスクの高い秘匿チャネル用に 1 つ、とアイデンティティを使い分けることもあるでしょう。それぞれが固有のシードと固有の受信鍵を持つため、あるアイデンティティに封印されたレコードは、そのアイデンティティの鍵を試すまで、ほかのアイデンティティからは見えません。

オフラインファーストのクライアントは、各アイデンティティがレコードフィードをどこまでスキャンしたかを独立して追跡します。この独立性こそが、後から古いシードをインポートしたときに、そのアイデンティティについてフィード全体を再スキャンできる理由です。今日から始めて、インポート以前に送られたものをすべて取りこぼす、ということが起きずに済みます。

古い Identity Seed を復元するとどうなるのか

対応するソフトウェアは、シードから同じ受信鍵を決定論的に再導出します。

つまり、レコードがまだチェーン上にあってスキャンでき、暗号文がまだ取得可能かキャッシュされている限り、古いシードで古い封印付きレコードを見つけられるということです。クライアントは公開フィードを再スキャンし、封印エンベロープを試行復号し、そのアイデンティティの受信トレイの表示を再構築します。シードを復元すれば、そのアイデンティティ宛てのレコードを認識する能力が復元されます。ゲートウェイが返せる秘密のメールボックスを抱えているわけではありません。

これは、シードがこれほど重要である理由のなかでも最も明快なものの 1 つであり、Identity Seed がいまなお注目に値する理由でもあります。受信用アイデンティティのシードを失うと、そのアイデンティティ宛ての封印付きレコードは読めなくなる場合があります。公開された証明はチェーン上に残り、検証され続けるにもかかわらず、です。暗号化には設計上、復旧用の裏口がありません。シードこそが復旧の経路なのです。

デスクトップクライアントはオフラインでレコードを受け取れるか

すでに同期済みのものについては動作します。

CardanoWall Desktop は、オープンソースの Rust SDK 上に Tauri で構築された、オープンソースの Rust アプリケーション（github.com/cardanowall）です。まさにこの考え方を中心に作られています。レコードを同期し、暗号文をキャッシュしてしまえば、ネットワーク接続なしでそのローカルデータを一覧表示し、検索し、検証し、復号できます。まだ同期されていないレコードや、まだ取得されていない暗号文がある場合は、それらを取り寄せるためにネットワークが必要になります。そしてそのことを、黙って失敗するのではなく、はっきりと伝えます。

これは、しっかりしたメールクライアントの振る舞いと同じです。オフラインだからといって世界が止まるわけではありません。ネットワークが戻るまでは、ローカルのミラー、キャッシュ、保管庫が信頼の拠り所になります。（オフラインモデルの詳細は、オフラインの証明と CardanoWall Desktopをご覧ください。）

レコードの送信者をどう検証すべきか

封印付きレコードを受け取れたという事実が証明するのは、ご自分の鍵でそれを開けるということだけです。誰が送ったかを証明するものではありません。

Label 309 では、作成者の表明は任意です。レコードに署名が付いていれば、その署名は特定の鍵がそのレコードを保証したことを示します。それでも、その鍵が誰のものかを判断するには、なお文脈が必要です。レコードが署名されていない場合、送信者がいかなるアイデンティティの紐づけも意図的に避けた可能性があり、それこそが一部の秘匿ワークフローが必要とするものです。

機微な素材については、送信者の鍵と受信アドレスを帯域外で確認してください。アドレス帳を保ち、鍵のフィンガープリントを照合し、すでに信頼しているディレクトリや直接の確認を使うのです。暗号化はコンテンツを保護します。相手の鍵が誰のものかを判断するのは、それとは別の、人間による信頼の判断です。アドレス帳の仕組みは、アドレス帳の仕組みで解説しています。

何がうまくいかなくなり得るか

最も重大な失敗は、シードを失うことです。受信用アイデンティティの Identity Seed を失うと、そのアイデンティティ宛てのレコードを復号する能力を、そのアイデンティティについては永久に失う場合があります。

残りは運用上の問題であり、優れたソフトウェアはそれらを隠すのではなく、正直に表面化させるべきです。

• 暗号文が一度もアップロードに成功していない
• 保存先が一時的に利用できない
• 送信者が誤った受信アドレスを使った
• 誤ったアイデンティティをインポートした
• ローカルのデバイスが侵害されている（ロック解除済みのマシン上の悪意あるプログラムは、メモリ上の秘密を読み取れます。共用コンピューターモードをご覧ください）
• レコードが新しすぎて、必要とする確認深度に達していない
• レコードは有効だが署名されておらず、送信者のアイデンティティが確立されない

証明システムは、不確実性を覆い隠すことによってではなく、それを示すことによって信頼を勝ち得ます。

要点

封印付きレコードを受け取るには、次のとおりです。

1. 受信アドレスを共有する。
2. Identity Seed を安全に保ち、バックアップしておく。
3. クライアントに公開された Label 309 のフィードをスキャンさせる。
4. ローカルで試行復号させる。
5. ご自分の鍵で復号できたレコードを開いて検証する。

受信トレイは、ご自分のアカウント宛てのメッセージをサーバー側に並べたリストではありません。それはご自分のアイデンティティで開ける封印付きレコードのローカルな表示です。そしてそれこそが、ご自分の私的なやり取りからゲートウェイを締め出している仕組みなのです。

最後に、限界についての正直な注記を 1 つ。封印付きレコードは鍵保有者のために平文を暗号化したまま保ちますが、匿名性を保証するものではなく、復号した人はその後で平文を漏らすことを選べてしまいます。証明が示すのは、特定のバイト列がある公開時刻までに存在していたということです。真実性、所有権、作成者を証明するものではありません。証明が証明しないことをご覧ください。

さらに読む

• 受信アドレスとは何か
• ファイルを封印する前に受信者を検証する
• 公開ファイルなしの秘匿開示
• オープンな標準とその参照実装コード： label309.org と github.com/cardanowall。Label 309 は Cardano CIP プロセスに提出され、レビュー中です。