トランスクリプト、スイート、方式のバージョンに結び付けた鍵
すべての秘密とすべての鍵が、その交換のトランスクリプト、スイート、鍵の方式のバージョンに依存するようになりました。トランスクリプトが1バイトでも違う2者は別々の鍵を得て、ハンドシェイクやチェーン確立は失敗します。
鍵スケジュールの変更が main ブランチに入りました。回線上のバイトは1つも増えず、 研究のページの数値は、これまでと同じ予備的な計測のままです。
すべての鍵が交換全体に依存する
これまで、導出される鍵は交換全体には依存していませんでした。鍵合意は固定のラベルと、 ソルトとしてひとつの値だけを使い、回線の鍵合意が結び付いていたのは開始側の一時鍵だけでした。
いまは、すべての鍵交換にトランスクリプトがあります。その交換の公開データを、一意に読める 並びにしたものです。チェーン確立では、形式のバージョン、ホップの番号、そのリレーへの回線の 識別子、リレーのオニオン鍵、クライアントの一時鍵です。回線では、バージョン、モード、回線上を 流れたままの両側の一時鍵、そして認証された回線では応答側の回線鍵です。
トランスクリプトのハッシュ、スイート、鍵の方式のバージョンは、すべての鍵合意とすべての鍵の 導出に入ります。暗号のインターフェースはトランスクリプトなしでは鍵を導出しません。呼び出し側が 指定できるのは鍵の用途だけで、独自のラベルは渡せません。認証された回線では、一時鍵どうしの 鍵合意と、開始側の一時鍵と応答側の回線鍵の鍵合意という2つを連結するので、フレーム鍵は両方に 依存します。
リレーは自分の公開鍵のバイト列をトランスクリプトに入れるようになりました。そのため起動時と、 新しいオニオン鍵を使い始める前に、公開鍵が秘密鍵と対応していることを確かめ、対応しない鍵の 組は受け入れません。
なぜ重要か：鍵合意の当事者やパラメータ（公開鍵、回線のモード、スイート、バージョン）の すり替えへの対策です。トランスクリプトが1バイトでも違えば、2者は別々の鍵を得て、最初の aead の検査に失敗し、それとともにハンドシェイクやチェーン確立も失敗します。一時鍵を別の符号化で 書いたチェーン確立のセルのコピーも、層を開けなくなりました。
回線上は変わらず、バージョンは混ざらない
この結び付けは1バイトも使いません。セルは今も 512 バイトで、チェーン確立のセルに入るのは 今も c25519 で4ホップ、gost で3ホップまでです。回線のハンドシェイクのメッセージにも フレームにも、そのためのフィールドはありません。
鍵の方式のバージョンを取り決める仕組みはありません。この変更より前のリレーとクライアントは、 v0.2.0 も含めて、新しいものとは一緒に動きません。回線のハンドシェイクは、理由を示さないまま 確認のフレームで終わります。リレーとクライアントは一緒に更新します。
この結び付けには、チェーン確立のセルの再送防止タグや回線の確認フレームと同じく、切り替えが ありません。結び付けのない構成は2つめの鍵スケジュール、つまり保護を弱める道になってしまう からです。その寄与を計測する実験ブロックはありません。ベンチマークは、両方のスイートで その各部分の時間を計ります。
どう確かめたか
- 両方のスイートで値を固定したテストベクトル（ゴールデンベクトル）が、トランスクリプトと そのハッシュ、導出されるすべての鍵、2つの鍵合意の連結を押さえています。固定した値は すべて、リポジトリの外にある独立した実装で計算し直しました。その実装は、まず規格に 載っている例で確かめてあります。食い違いはありませんでした。
- それぞれの結び付けを、わざと壊してみました。トランスクリプトの一部を抜く、または入れ替える、 ハッシュを鍵の導出から外す、回線の鍵をひとつの鍵合意だけから導く、用途を入れ替える、別の スイートのコンテキストを受け入れる、といった変更です。どの変更でも、名前のついたテストの 検査が失敗しました。
- 両方のスイートでのテスト：別のオニオン鍵、ホップの番号、回線の識別子では、チェーン確立の 層は開きません。モードのバイトを変えるか、応答側の回線鍵が違えば、回線のハンドシェイクは 失敗します。チェーンの各ホップの鍵は、1バイトずつ書き出したトランスクリプトから、テストの 中で計算し直しています。
- 変更は計測環境のクラスタに展開しました。5つのリレーに証明書を発行し、3ホップのチェーンで 往復が通ること、別のアンカーを持つクライアントが拒否されることを確かめました。
これで解決しないこと
- トランスクリプトが結び付けるのは鍵であって、リレーの身元ではありません。他のリレーの回線鍵を 自分のディスクリプタに載せたリレーは、これでは見つかりません。チェーンの検査は回線鍵を 比べないためです。
- 回線の応答側は依然として開始側を認証せず、ハンドシェイクには開始側からの明示的な確認も ありません。リレー間の回線で開始側を認証することは計画中です。
- トランスクリプトの中身が正しいことを支えているのは、テストだけです。チェーン確立と回線の ハンドシェイクの形式モデルはありません。チェーン確立のモデルは計画中です。
- 鍵スケジュールは noise の交換の形にならっていますが、noise そのものではないため、 公開されている noise のテストベクトルは当てはまりません。この方式には独自のテストベクトルが あります。
- フレーム鍵とホップ鍵は、回線とチェーンが続くあいだ変わりません。その内部での鍵の取り替えは 計画中です。
ロードマップの次の項目は、これまでどおり、エンドツーエンドの層を持つ 受信側クライアントと、クライアント間の否認可能な認証です。
全体の一覧は限界のページと 適用範囲（英語）に あります。トランスクリプト、ラベル、両方のスイートの式は 暗号（英語）の 「key derivation」の節に、脅威と対策は 脅威モデル（英語）に あります。