🧰 UtlKit

AES 暗号化/復号:12 バイトを 28 バイトへ暗号化、16 バイトの認証タグ、12 バイトの IV とキー-IV 再利用警告

ブラウザ内で AES-GCM によりテキストを暗号化・復号:12 バイトの平文は 16 バイトの認証タグを載せた 28 バイトの暗号文になります。32・48・64 桁の 16 進キーがそれぞれ AES-128・192・256 を選び、24 文字の IV は 12 バイト。同じキーと IV の組を再利用すると警告が出る。base64 出力は 12 バイトで 40 文字、100 バイトで 156 文字。すべてローカルです。

ブラウザでのテキスト暗号化は、守衛付きの往復です。平文は鍵で暗号文へ変換され、16 バイトの認証タグが添えられるため、経路上で 1 ビットでも変えれば検出されます。AES 暗号化/復号は AES-GCM でこの往復をブラウザ内で完結します:12 バイトの平文は 28 バイトの暗号文になり、32・48・64 文字の 16 進キーがそれぞれ AES-128・192・256 を選び、24 文字の IV は 12 バイトです。出力は base64——この 12 バイトの例では 40 文字——で、復号側は改ざんされたものを拒否します。何もマシンを離れません。

GCM がブロック暗号に加えるもの

AES そのものはブロック暗号です:16 バイトを 1 単位に取り、固定のラウンド数で混同します——128 ビットキーで 10 ラウンド、192 で 12、256 で 14。ブロック暗号だけではメッセージの長さを隠せず、16 バイトの倍数でないメッセージは受けられず、暗号文が経路で変えられたかも教えてくれません。GCM はその上に 3 つを加えます。カウンタモードで動作し、任意の長のメッセージが流れること。平文と XOR されるキーストリームを導出すること、これが内容を隠す仕組みです。鍵付きハッシュで暗号文から 16 バイトの認証タグを計算すること。タグが守衛です:暗号文の 1 ビットを反転させると、復号側は乱数を返さずエラーを投げます。ハッシュ生成は同一家族の鍵の無いダイジェストを計算し、完全性や重複排除に使います。ダイジェストは逆算できないので、単体ハッシュは永遠に暗号化の代わりになりません——GCM のタグはハッシュの考え方を借りて鍵を付け、それが密文へ添付するのが安全な理由です。

鍵、IV、そして繰り返してはならない 1 組

鍵が材料です:16 進 32 文字は 16 バイト、48 は 24、64 は 32 なので、3 つの合法長がそれぞれ AES-128・AES-192・AES-256 を選び、鍵は importKey 後に抽出不可のハンドルとして Web Crypto に保持され、テキストとして保存も送信もされません。IV(初期化ベクトル)は 16 進 24 文字・12 バイトで、同一鍵で使った他のどの IV とも異ならなければなりません。繰り返してはならない 1 組がこれです:同一鍵に同一 IV を 2 回は GCM を壊す失敗で、2 回の運行のカウンタキーストリームが完全に同じになり、2 本目のメッセージが 1 本目を剥ぐ能力を攻撃者に渡すことになります。ツールはセッション内で使った鍵-IV 組を覚えており、そのどれかをまた使おうとすると即座に警告を表示します。対照として、HMAC 生成は同種の鍵付きハッシュで逆の仕事をします:メッセージを認証しますが隠しません。HMAC は「これは完全で、あなたからのものか」に答え、GCM は「完全で、あなたからで、かつ秘密か」に答えます。

乱数はどこから来る

ページ読み込み時、ツールは 2 つのフィールドを自分で埋めます:64 文字の乱数 16 進キー(32 バイト)と 24 文字の乱数 16 進 IV(12 バイト)。暗号化そのものの下にある同じ Web Crypto getRandomValues パスで生成します。乱数こそが IV を唯一に保つものです:12 バイトの乱数 IV は少量のメッセージ間の衝突確率が無視でき、新しい鍵にすればその確率そのものも消えます。同じブラウザで識別子を作るなら、UUID 生成は v4 UUID に同じ乱数源から取り、同じ注意が当てはまります:乱数は設定ではなく供給であり、ブラウザが出し手です。生成された 2 つのフィールドはパスポートのように扱ってください——持ち去られるもので、誰かと共有するものではありません。

base64 出力の読み方

暗号文はバイナリなので、ツールは base64 で描画します。このエンコーディングは 3 バイトごとに 4 文字へ変換します。これが 12 バイトの平文が 12 文字で戻ってこない理由です:12 バイト加 16 バイトのタグの 28 バイトの暗号文は base64 40 文字になり、末尾の組が埋めで余りを吸収します。増加分は安定しています:100 バイトの平文は 116 バイトの暗号文、すなわち base64 156 文字、1000 バイトは 1016、すなわち 1356 文字。加わる 16 バイトは毎回同じタグなので、長いメッセージでは無視でき、短いものでは目立ちます。生のエンコーディングを期待する場所へバイトを渡す必要があるとき、Base64 エンコーダ/デコーダがテキスト形式と他の表現の間を変換し、内容は触れません。

鍵がシステム全体

AES-GCM の強さは背後の鍵に完全に依存し、秘密としての鍵は秘密としてのパスワードと意味が同じです:強さは長さと予測困難さの関数であり、管理は繰り返さないこと、誰にも読める場所へ書かないことです。ツールはあなたの鍵を判定しません——32 から 64 までの偶数長の 16 進文字列なら受け入れます——ただし誠実なチェックはパスワード強度チェッカーがパスワードに適用する同じ基準を 16 進へ翻訳するものです:反復パターンでできた 64 文字の 16 進文字列は、材料としては 32 バイトでも、エントロピーは 256 ビットよりはるかに下です。手入力ではなく実際の鍵材料が要るとき、パスワード生成ガイドは同じ生成と保存の規律を扱い、乱数 16 進キーも同じ 1 クリックの経路で生成されます。

箱の外での AES

同じ AES-GCM プリミティブはブラウザの玩具ではありません:TLS は AES-GCM を中核レコード暗号の 1 つとして使い、モダン OS の全ディスク暗号化は AES(通常は XTS モード)を使い、ツールが呼ぶ Web Crypto API は、決済ランタイム、サインインフロー、オフラインファーストのアプリがローカル保存の暗号化に呼ぶ API と同じです。このツールの狙いはプリミティブを点検可能にすることです:テキストボックスの中で確かな暗号文、確かなタグのオーバーヘッド、確かな改ざん検出の失敗様式が見えます。トークンは同じスタックの別の見える顔です——JWT デコーダはトークンのヘッダとペイロードを開き、何が署名されて何が署名されていないかを示します。これは暗号化が書き込み方向でやっていることの読み取り専用の双生です。

関連ツール

よくある質問

ツールはどの鍵長を使いますか?

あなたの鍵長が決めます。16 進 32 文字は 16 バイト、48 は 24、64 は 32 なので、3 つの合法長がそれぞれ AES-128・AES-192・AES-256 を選び、ラウンド数は 10・12・14 に従います。ツールはその範囲の偶数長の 16 進文字列なら受け入れ、長さに選択を任せます。

なぜ 12 バイトの入力が暗号化すると 28 バイトになるのですか?

GCM は暗号文の末尾に 16 バイトの認証タグを追加するため、12 バイトの平文はどの鍵長でも 28 バイトの暗号文になり、その 28 バイトは base64 40 文字で描画されます。タグは捨てられるオーバーヘッドではなく、それが改ざん検出を可能にしているもので、無いまま復号すると失敗します。

同一鍵で同一 IV を再利用すると何が起きますか?

ツールは警告を表示します。それが GCM を壊す失敗だからです。同一鍵に同一 IV は 2 回の運行で同じカウンタキーストリームを意味し、2 本目のメッセージが 1 本目を剥ぐために必要なものを攻撃者に渡します。ツールはセッション内で使った全鍵-IV 組を覚え、そのどれかをまた使おうとすると即座に印をつけます。メッセージごとに新しい IV — 理想では新しい鍵 — を生成してください。

暗号文が改ざんされていないことをどう知ればよいですか?

復号側は何も返す前に 16 バイトのタグを検証し、暗号文のどこでも 1 ビットが反転すれば検証は失敗する。ツールは黙って間違ったテキストを返さず、復号エラーを表示します。これが GCM が純粋なカウンタモードに勝る全部分です:出力は検証をとおるか、そもそも戻ってこないかです。

自分のデータはサーバーへ送信されますか?

されません。暗号化、タグ検証、base64 エンコーディングはすべてローカルマシン上の Web Crypto と Web API を通してブラウザ内で走り、鍵、IV、テキストはそこから離れません。これが、フォームに貼らないほうがよいテキストにツールを使える理由です。

関連記事