PASETO v4.localの基本
PASETO v4.localトークンがXChaCha20 + BLAKE2bでペイロードを暗号化する仕組み、認証される理由、v4.publicではなくこちらを選ぶ場面を学びましょう。
詳細な説明
v4.local はPASETO v4の対称鍵・暗号化バリアントです。v4.public と異なり、ペイロードは署名されるだけでなく暗号化されており、対称鍵を持たない受信者にとっては不透明な暗号文バイトにしか見えません。同じサービスがトークンを発行も消費もする場合(例:サーバーサイドのセッションクッキー)で、中間者にクレームを読まれたくない時に最適です。
暗号化方式:
v4.local は暗号化にXChaCha20、認証にBLAKE2b鍵付きハッシュを使用します。メッセージ末尾の32バイトのタグは、暗号文・バージョン+用途ヘッダー・ランダムnonce・任意のフッターに対するBLAKE2b-MAC(PAE経由)です。XChaCha20の192ビットnonceは大規模でもランダムnonceが安全であることを意味し、数十億トークンを跨いでもnonce衝突の現実的なリスクはありません。
ワイヤー形式:
v4.local.<base64url(nonce || ciphertext || tag)>[.<base64url(footer)>]
中央のセグメントをデコードすると、32バイトのランダムnonce、可変長の暗号化ペイロード、32バイトの認証タグになります。鍵を持たないデコーダーはバージョン、用途、フッター、おおよその暗号文長を表示できますが、JSONクレームを明らかにすることはできません。
publicではなくlocalを使う理由:
主な理由は3つ:(1) パフォーマンス — 対称プリミティブはEd25519の署名/検証より10〜100倍高速。(2) 機密性 — ペイロードが読めないため、トークン内にセッションデータやPIIを格納する場合に重要。(3) 単一の信頼ドメインしかない場合の鍵管理の簡素化。トレードオフは、鍵を持つ者なら誰でも発行・検証両方ができるため、鍵の漏洩が致命的になることです。
よくある間違い:
v4.localの暗号化を汎用暗号化と混同しないでください。PASETOはトークンのペイロードを暗号化するのであって、任意のバイト列ではありません。任意のデータには高レベルのAEADライブラリを直接使ってください。また、v4.localと他の用途で同じ鍵を使ってはいけません。PASETOの鍵は専用にすべきです。
ユースケース
Webアプリがユーザーセッションデータをサーバーサイド鍵で暗号化したv4.localクッキーに格納 — ブラウザはクッキーを保持しますがクレームを読めず、サーバーだけが検証と復号を行えます。