KeyGenerator.io

AES 鍵ジェネレーター

128・192・256ビットの AES ランダム鍵をブラウザ内で生成。通信なし、記録なし、送信なし。

0 ビットのエントロピー

鍵長
エンコード

スペース キーで再生成、C キーでコピー。鍵は端末上の crypto.getRandomValues で生成し、このページは外部リソースを一切読み込みません。

この鍵の作り方

AES 鍵は長さの決まったランダムなバイト列です。AES-128 なら 16 バイト、AES-192 なら 24 バイト、AES-256 なら 32 バイト。パスワードと違って長さを検討する余地はなく、アルゴリズムはこの三つのいずれかしか受け付けません。そしてその全ビットが推測不可能である必要があります。

バイト列はブラウザの暗号論的擬似乱数生成器である crypto.getRandomValues から直接取得し、16進数または Base64 として出力しています。タイムスタンプもカウンターも Math.random も経路上にありません。どちらの表記も中身は同じバイト列なので、ライブラリや鍵管理サービスが求める方を選んでください。

すべてお使いの端末内で完結します。読み込み後に通信は行わないため、この鍵はこれまでどこにも存在せず、どこにも送られません。再読み込みすれば消えます。

よくある質問

どの鍵長を選ぶべきですか？

制約がなければ AES-256 です。128ビットが破られるからではなく、鍵を長くするコストがほぼゼロで、この議論を将来しなくて済むからです。AES-128 は総当たりに対して依然として完全に安全で、AES 支援命令のない環境では明確に高速です。AES-192 も存在し問題なく使えますが、利用者が少ないため一部のライブラリやハードウェア経路での扱いが他の二つより劣ることがあります。

AES-256 は AES-128 の 2 倍強いのですか？

違います。差は 2 倍ではなく 2^128 倍です。ただしどちらも総当たりが意味を持たない領域をとうに超えています。2^128 を数え上げるのに必要なエネルギーは、どんなハードウェアを想定しても地球全体の予算を超えます。現実のシステムが破られる原因は鍵長ではありません。nonce の再利用、パスワードから直接導出した鍵、守るべきデータの隣に置かれた鍵です。

IV は鍵と同じものですか？

違います。そしてこの二つの混同が AES で最も多い誤りです。鍵は長期間保持する秘密です。IV（GCM では nonce）はメッセージごとの値で、秘密ではまったくなく、通常は暗号文と一緒に平文のまま送られます。IV はメッセージごとに新しく生成し、鍵は一度生成して保持します。

メッセージごとに鍵を変える必要がありますか？

ありません。各メッセージが固有の IV または nonce を持つ限り、一つの鍵で多数のメッセージを暗号化できます。決して繰り返してはならないのは同じ鍵の下での nonce です。GCM で再利用すると二つの平文の XOR が漏れ、攻撃者にメッセージ偽造を許します。これは軽微な弱体化ではなく完全な破綻です。メッセージごとにランダムな 96 ビット nonce を使うのが通例です。

パスワードをそのまま AES 鍵にできますか？

そのままでは使えません。パスワードは短く、狭い空間から選ばれます。一方 AES 鍵はランダムと区別がつかない必要があります。入力を人が覚えなければならないなら、鍵導出関数 —— Argon2id、scrypt、あるいは十分な反復回数の PBKDF2 —— を通し、その出力を鍵として使ってください。パスワードを SHA-256 で一度ハッシュすれば 32 バイトは得られますが、32 バイト分の予測不可能性は得られません。

GCM と CBC のどちらを使うべきですか？

ほとんどの場合 GCM です。暗号化に加えて認証も行うため、暗号文の改竄が検出されます。CBC 単体では改竄が検出されず、意味不明な平文が復号され、それをコードが正しいものとして扱ってしまいます。CBC は完全性を一切提供しないため別途 MAC を、しかも正しい順序で組み合わせる必要があり、これはまさに静かに壊れるたぐいの細部です。

16進数と Base64 のどちらがよいですか？

中身は同じバイト列です。256ビット鍵は16進数で 64 文字、Base64 で 44 文字、強度は同一です。受け取る側が期待する形式を使ってください。クラウドの鍵管理サービスや各言語のライブラリは Base64 を求めることが多く、設定ファイル、コマンドライン引数、シェルを通る値は 0-9 と a-f しか含まない16進数のほうが安全です。

鍵はどこに保管すべきですか？

鍵管理サービスがあればそこへ、なければ環境変数かバージョン管理に入れない機密ファイルへ。守るべき暗号文と同じ場所には絶対に置かないでください。同じデータベース、同じバックアップ、同じリポジトリに鍵があるなら、その保管先が複製された時点で保護は無意味になります。もう一点、AES 鍵の交換はデータの再暗号化を伴うため、ローテーションは定期実行で済む話ではなく計画が要ります。

ブラウザで暗号鍵を生成しても安全ですか？

そのページが鍵を送信できない場合に限り安全で、それは信じる対象ではなく確認できる事柄です。開発者ツールの「ネットワーク」タブを開いたまま何度でも生成してみてください。読み込み後は何もリクエストされません。受け取るサーバーは存在せず、漏らしうる解析ツールや外部スクリプトもありません。