Vaultedのzero-knowledge暗号化を自分で確認する

1. vaulted.fyi を開く。
2. DevToolsを開いて Network タブに切り替える。Fetch/XHR でフィルタリングする。
3. シークレットフィールドにわかりやすい文字列を入力する — 例えば CANARY-12345。
4. Create をクリックする。

単一の POST リクエストが /api/secrets に表示される。それをクリックして Payload タブを確認する。

ボディには ciphertext フィールドと iv フィールドが含まれている。どちらもbase64urlエンコードされたblobだ。ペイロードで CANARY-12345 を検索しても — 見つからない。平文はリクエストが送信される前にブラウザ内で暗号化された。

念を入れたい場合は、ネットワークスロットリングを「Slow 3G」に設定して繰り返す。暗号文は引き続きノイズのように見え、平文はどこにも見当たらない。

シークレットを作成すると、Vaultedは共有リンクを表示する。こんな形だ：

https://vaulted.fyi/s/abc123#dGhpcyBpcyBhIGtleQ
                              ^^^^^^^^^^^^^^^^^^^^
                              encryption key (base64url)

# の後の部分がURLフラグメントだ。RFC 3986 に従い、ブラウザはフラグメントをローカルで処理する — HTTPリクエストライン、ヘッダー、リファラーには現れない。

これを証明するには：

1. 共有リンクをコピーする。
2. DevToolsのNetworkタブを開いた状態で新しいタブで開く。
3. GET /s/abc123 リクエストを見つける。
4. Headers タブを確認する — 完全なリクエストURL、フラグメントなし。
5. Request タブを確認する — フラグメントなし。
6. 次のページで document.referrer を確認する — フラグメントは除去されている。

受信者がシークレットを復号するために必要なキーはURLの中にあったが、そのブラウザ内に留まった。サーバーが見たのは GET /s/abc123 のみだ。

ターミナルを開いて、curl でシークレットを直接取得する：

curl https://vaulted.fyi/api/secrets/abc123

ciphertext と iv を含むJSONが返ってくる。これがシークレットのサーバーサイドの完全な状態だ。

これを解読しようとしてみよう。URLフラグメントのキーなしでは無理だ。適切に生成されたランダムキーによるAES-256-GCMは、実用的な観点からランダムノイズと区別できない。Vaultedのサーバーからの完全なデータベースダンプでも、得られるのは暗号化されたblobとメタデータだけだ。

これがzero-knowledgeの文字通りの定義だ：サーバーは読めないデータを保存している。

Vaultedは Web Crypto API を使っている。これはブラウザのプリミティブで、難読化されたWASMやネイティブモジュールで処理を隠してはいない。暗号化が行われる様子を直接観察できる。

1. DevToolsで Sources タブを開く。
2. crypto.subtle.encrypt を検索する（グローバル検索には Cmd+Option+F を使う）。
3. crypto.subtle.encrypt を呼び出す行にブレークポイントを設定する。
4. 新しいシークレットの作成をトリガーする。
5. ブレークポイントが当たる。引数を確認すると：平文が Uint8Array として、AES-GCMキー、フレッシュなランダムIVが見える。
6. 呼び出しをステップオーバーする。結果が送信される暗号文だ。

ネットワークリクエストの前に、ブラウザ内で平文が暗号文になる様子をリアルタイムで観察している。データが通る他の経路はない。