1つまたは2つのボリュームを持つクライアントのコンテナ

クライアントのコンテナが main ブランチに入りました。パッケージそのもの、連絡先カードをボリュームに保持するプロファイル、そして jimichi vault init と jimichi vault show の2つのコマンドです。動作中の -peer のクライアントはまだこれを使っておらず、身元はいまもメモリにしかありません。コンテナは研究のページの数値には含まれていません。

1つのファイル、2つの領域

コンテナは一定サイズの1つのファイルで、ソルトと、封をした2つの領域からなります。それぞれのボリュームは自分の領域に自分のパスワードで入り、書き込まれたボリュームが持つのは、相手の連絡先カードひとつだけです。ボリュームのない領域には空のボリュームが入ります。同じコードで、すぐに捨てる無作為な鍵を使って封をしたものです。ボリュームがどちらの領域に入るかも無作為です。ファイルにはヘッダもバージョンも nonce もなく、形式を決めるのはファイルのサイズだけです。

jimichi vault init は1つまたは2つの連絡先カードを受け取り、各ボリュームのパスワードを自分で生成して、一度だけ表示します。jimichi vault show は stdin からパスワードを読み、そのボリュームから導出した自分のカードと、連絡先カードのハッシュを表示します。ボリュームの数や、開いた領域がどちらかは表示しません。

ファイルに鍵がないことと、それが意味しないこと

ファイルには、暗号化した形も含めて、鍵素材が一切ありません。身元の鍵と取り出し権限は、開くたびにボリュームの鍵から導出します。導出は、システムの他の部分と同じ暗号インターフェースを通り、両方のスイートで動きます。これはファイルのバイト列についての事実であって、強度についての主張ではありません。ファイルとボリュームのパスワードがあれば両方を再現できるので、ファイルをパスワードと一緒に押収された場合、コンテナの強度は、そのパスワードで守って保存した鍵と同じです。ファイルがなければパスワードだけでは何もできません。ソルトはファイルにしかないためです。

鍵の導出についての仮定のもとで、ボリュームから作ったカードは、コンテナを使わないクライアントのカードと見分けられません。そのため、連絡先もメールボックスも、カードからコンテナのことを知ることはありません。

一度だけの書き込み

ファイルは作成時にちょうど一度だけ、一時ファイルとハードリンクを通して書き込まれます。その時点で、どのボリュームにもすでに連絡先カードがあります。そのあとの書き込みはなく、開くときは読むだけです。そのため、作成後のファイルの状態はすべてバイト単位で同じで、失敗のあとで書き込みをやり直しても同じバイト列を書きます。別の日の押収、バックアップ、同期をいくつ集めても、1つの状態以上のことはわかりません。ハードリンクは既存のファイルを置き換えないので、すでにあるコンテナが上書きされることもありません。

一度だけ書き込むことの代償として、連絡先やパスワードを変えるには、新しいコンテナ、新しい身元、新しい紹介が必要です。2つ目のボリュームの連絡先カードも、作成の時点で必要です。

主張していること

ある1つの状態のファイルと1つのボリュームのパスワードからは、2つ目のボリュームがあるかどうかはわかりません。これは、パスワードの引き延ばし、一回限りの鍵を使う aead、鍵の導出について明示した仮定と推論に基づくもので、形式的な証明ではありません。また、2つ目のボリュームのパスワードが生成されたものである場合にかぎります。そのため jimichi vault init はパスワードを自分で生成します。-stdin を使えば利用者が自分のパスワードを渡せますが、その場合この主張は当てはまらないと、コマンドが警告します。
作成後のファイルの状態は、バイト単位で同じです。
書き換えられたボリュームは開きません。どの領域も aead で封をしてあり、領域の番号とソルトが鍵に入るため、1ビットの書き換えや領域の入れ替えがあると、開くのに失敗します。サイズの違うファイルは、コンテナではないとして拒否されます。

主張していないこと

人が選んだパスワード。どちらのスイートでも主張しません。そうしたパスワードは、オフラインでの推測が届く範囲にあるためです。gost では引き延ばしにメモリが要らず、推測の費用は c25519 よりさらに小さくなります。どれだけ小さいかは計測していません。
表示したパスワード。jimichi vault init は生成したパスワードを一度だけ表示します。端末の履歴やリダイレクトした出力は対象外です。
強要に対する免疫。どのコンテナにも領域が2つあるため、ソフトウェアを知っていて強要する側は、 2つ目のパスワードを求めます。2つ目のボリュームはもっともらしい説明であり、その説明がもっともらしいのは実際に使われているあいだだけです。メールボックスにある偽装用のキューが動いていないことや、偽装用の連絡先が返事をしないことから見抜かれます。
明かしたパスワード。ファイルと合わせると、そのボリュームの身元の鍵、取り出し権限、連絡先カードを、コンテナが存在するかぎり渡してしまいます。鍵の取り替えも失効もありません。
ファイルシステムとドライブ。タイムスタンプからはコンテナを作った時点と開いた時点がわかります。ジャーナル、シャドウコピー、ウェアレベリング、trim が作成の痕跡をどれだけ残すかは計測していません。リンクの前に強制終了された作成が残した一時ファイルは、自分のソルトを持つ別のコンテナです。次の起動時に削除しますが、削除してもドライブ上のブロックは消えません。
押収と押収のあいだの能動的な攻撃者。もう一方の領域を新しい空のボリュームに置き換えても偽装には影響しませんが、2つ目のボリュームの持ち主には、それがパスワードの誤りと同じに見えます。そこで同じ端末でコンテナを作り直すと、次の押収で、2つ目のボリュームがあったことがわかってしまいます。
動作中の端末。パスワード、その引き延ばし、身元の鍵のコピーがライブラリのメモリに残り、スワップやページファイルに書き出される可能性があります。
パスワードのないファイルがランダムなバイト列と見分けられないことは、kuznyechik-mgm については証明されていない仮定に基づきます。ただし、押収した者には、そのファイルを指定するコマンドライン、パス、一定のサイズから、それがコンテナであることがわかります。隠れているのは、ボリュームが1つか 2つかです。

どう確かめたか

vault のテスト：空のボリュームとボリュームは同じコードで封をされ、ボリュームのない領域はゼロの鍵では開かず、作成のたびに新しい鍵を受け取ります。パスワードの誤りとボリュームの不在は、同じ回数のプロバイダの呼び出しで同じエラーになり、ボリュームの位置は無作為です。
ファイルにも、開いた領域にも、身元の鍵、取り出し権限、途中の鍵、パスワードのバイトはひとつもありません。
開いてもファイルのバイトは変わらず、2回目の書き込みは拒否され、リンクで拒否されたあとのやり直しは同じバイト列を書き、既存のファイルが置き換えられることはありません。
ソルトや領域の1ビットの書き換え、領域の入れ替え、切り詰め、末尾への追加は、どれも開くのに失敗します。
両方のスイートでの、本番のコストでのパスワードの引き延ばしのゴールデン値。

次

再起動のあとも身元をコンテナに保つ -peer のクライアントと、この性質の計測、つまりボリュームが 1つか2つかを見分ける識別器とファイルの状態の追跡です（#20）。このクライアントには固有の限界も生じることになります。取り出し権限が変わらなければキューも変わらないため、メールボックスはそのコンテナでのすべての起動を結び付けることになります。そのあとは、エンドツーエンドの経路の計測のトポロジー（#47）と、攻撃のブロック：メモリダンプからの鍵の取り出し（#24）、リレーの侵害（#117）、タイミングの透かし（#116）です。

全体の一覧は限界のページと適用範囲（英語）に、形式はアーキテクチャ（英語）に、鍵と議論は暗号（英語）に、脅威と対策は脅威モデル（英語）にあります。