AES暗号化ツール — GCM・CBC・CTR対応

AES暗号化とは?

// AES-256-GCM with a passphrase (PBKDF2-HMAC-SHA256, 600,000 iterations).
// Identical code runs in the browser and in Node.js 20+ via Web Crypto.
async function aesGcmEncrypt(plaintext, passphrase) {
  const enc = new TextEncoder();
  const salt = crypto.getRandomValues(new Uint8Array(16));
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const baseKey = await crypto.subtle.importKey(
    'raw', enc.encode(passphrase), 'PBKDF2', false, ['deriveKey']);
  const key = await crypto.subtle.deriveKey(
    { name: 'PBKDF2', salt, iterations: 600000, hash: 'SHA-256' },
    baseKey, { name: 'AES-GCM', length: 256 }, false, ['encrypt']);
  const ct = new Uint8Array(await crypto.subtle.encrypt(
    { name: 'AES-GCM', iv }, key, enc.encode(plaintext)));
  const packed = new Uint8Array([...salt, ...iv, ...ct]); // salt(16) | iv(12) | ct+tag
  return btoa(String.fromCharCode(...packed));            // self-contained Base64
}

主な機能

AES暗号化の例

素早い茶色の狐がのろまな犬を飛び越える。

ソルト(16B)+ IV(12B)+ 暗号文 + タグ(16B)をBase64エンコード — 実行するたびに異なる値になります

Attack at dawn!

U2FsdGVkX18AESIzRFVmd1PBwxIFQpF+VgIhTK0aDHQ=

AESでテキストを暗号化する方法

1. 1

   モードと鍵長を選ぶ

   モードはGCM(推奨)のまま、鍵長は256のままにしておくのが最も適切なデフォルトです。対象のシステムが要求する場合のみ、CBCまたはCTRに切り替えてください。

2. 2

   パスフレーズか生鍵かを選ぶ

   鍵の種類はパスフレーズのままにして強力なパスフレーズを入力するか、生鍵に切り替えて正確な128/192/256ビットの鍵を16進数またはBase64で貼り付けてください。バイト数バッジで生鍵の長さが正しいかを確認できます。

3. 3

   暗号化するテキストを入力する

   平文を入力または貼り付けてください。暗号化は入力と同時に自動的に実行され、すべてブラウザ内で完結します — ボタンの往復もアップロードも不要です。

4. 4

   自己完結型の暗号文をコピーする

   右側のBase64の結果には、ソルト、IV、認証タグがすでに含まれています。セグメント表示でバイト構成を確認してから「コピー」をクリックしてください。対象システムが16進数を必要とする場合は、出力エンコーディングをHexに切り替えます。

5. 5

   必要なときに復号する

   暗号文、パスフレーズ、同じモードと鍵長を相手に渡すか、AES復号ページを開いて自分で復号してください。

AES暗号化でよくある間違い

Key type: Raw key
Key (hex): correct horse battery staple   (not hex, not 32 bytes)

Key type: Passphrase
Passphrase: correct horse battery staple   (stretched with PBKDF2)

// same key, same IV for two messages
encrypt(key, iv, a); encrypt(key, iv, b);

// fresh random IV each time (the default)
encrypt(key, randomIV(), a);

stored = ciphertext              // salt + IV + tag thrown away

stored = salt + iv + ciphertext + tag   // the full Base64 string

assert(encrypt(msg) === encrypt(msg))   // fails — and should

assert(decrypt(encrypt(msg)) === msg)   // this is what must hold

AES暗号化でできること

AESモードの挙動を学ぶ

同じ入力でGCM、CBC、CTRを切り替えて、認証、IVの長さ、暗号文サイズがどう変わるかを確認しましょう。NIST SP 800-38Dが実際に何を規定しているかを体験的に理解する方法です。

他システムが読める暗号文を作る

OpenSSLのSalted__形式(または生鍵とIVの組み合わせ)で出力を生成すれば、opensslや暗号ライブラリを使うバックエンド、スクリプト、チームメンバーが問題なく復号できます。

短いメモやスニペットを暗号化する

デバイス間で移動中の復元フレーズや、サポートチケットに含まれるスニペットなど、一時的な個人テキストを、自分だけが知るパスフレーズで保護しましょう。規制対象や本番の機密情報には使わないでください。

暗号化フォーマットを試作する

コードを書く前に、ここでソルト/IV/タグの構成やKDF設定を固め、セグメント内訳表示でバイト順と長さを確認しましょう。

テストベクターを生成する

固定のパスフレーズとモードで既知の暗号文を作成し、自分の復号テストに利用したうえで、AES復号ページで往復動作を検証しましょう。

AESのモードと鍵導出

GCM(Galois/Counter Mode) — 認証付き、推奨

機密性に加えて128ビットの認証タグ(NIST SP 800-38D)を提供します。暗号化ごとにランダムに生成される96ビット(12バイト)のIVを使用し、暗号化・復号ともに並列化しやすいのが特徴です。絶対に破ってはいけない唯一のルールは、同じ鍵でIVを再利用しないことです。SP 800-38Dは1つの鍵に対してランダムに生成できるIVを約2^32個までに制限しており、再利用すると2つの平文のXORが漏洩し、タグを保護する認証鍵まで露呈しかねません。ほぼすべての用途に最適です。

CBC(Cipher Block Chaining) — 機密性のみ

各ブロックはランダムな16バイトのIVを使い、直前の暗号文ブロックとXORされます。組み込みの認証機能はないため、暗号化してからMACを付ける方式(encrypt-then-MAC、例えばHMAC生成ツール)と組み合わせる必要があり、歴史的にパディングオラクル攻撃(Vaudenay、EUROCRYPT 2002)に弱いことが知られています。OpenSSLや古いシステムとの相互運用のためにここで提供しています。

CTR(Counter) — 機密性のみ、ストリーム的

カウンターを暗号化することでAESをストリーム暗号に変える方式で、パディングなしで任意のバイト長を扱え、ブロックは自由に並列化できます。CBCと同様、それ単体では完全性を提供せず、同じ鍵でカウンター/IVを再利用すると致命的です。ランダムアクセスやストリーミングのセマンティクスが必要な場合に有用です。

ECB — 提供していません(意図的な設計)

Electronic Codebookは各ブロックを独立して暗号化するため、同一の平文ブロックは同一の暗号文ブロックを生成し、パターンが漏れてしまいます — 悪名高い「ECBペンギン」です。Web Crypto APIは意図的にこれを実装しておらず、私たちも同様です。レガシーな相手がECBを要求する場合は、それを再現すべきフォーマットではなく、修正すべきバグとして扱ってください。

鍵導出:600,000回、10,000回、1回の反復の違い

デフォルトのパスフレーズモードでは、このツールはOWASPに準拠し、16バイトのソルトとともにPBKDF2-HMAC-SHA256を600,000回反復します(同じSHA-256ハッシュを数十万回適用するイメージです)。OpenSSL互換モードでは、PBKDF2はデフォルトでわずか10,000回反復(openssl encのデフォルト)であり、CryptoJSや古いOpenSSLが使うレガシーなEVP_BytesToKey KDFはMD5を1回だけ適用します — 桁違いに弱いものです。反復回数が多いほど、推測1回あたりの総当たり攻撃が遅くなります。これが最新のデフォルトがはるかに高く設定されている理由です。Argon2やscryptはさらに強力ですが、Web Cryptoの一部ではないためここでは対象外です。パスワード保管にはOWASPに従い、Argon2idを優先してください。

AES暗号化のベストプラクティス

相手が要求しない限りGCMを優先する

認証付き暗号化は、CBCやCTRが黙って見逃してしまう改ざんを検出します。相互運用のためだけにCBCやCTRに切り替え、その場合はMACを追加してください。

メッセージごとに新しいランダムIVを使う

このツールは自動的にこれを行います。IVを手動で上書きする場合は、同じ鍵で決してIVを再利用しないでください — GCMでは再利用は致命的であり、CBCでは意味論的安全性が崩れます。

強力なパスフレーズと真にランダムな鍵を選ぶ

PBKDF2は総当たり攻撃を遅くしますが、弱いパスフレーズを救うことはできません。パスワード生成ツールで長いパスフレーズを生成するか、秘密鍵生成ツールで真にランダムな鍵を生成してください。

ソルト、IV、タグを暗号文と一緒に保管する

これらは秘密ではありませんが、なければ復号は失敗します。このツールの自己完結型フォーマットは3つすべてをまとめています。生鍵・ベア暗号文モードを使う場合は、IVを別途コピーし、暗号文と一緒に保管してください。

本番や規制対象の機密情報をオンラインツールで暗号化しない

完全にクライアントサイドであっても、ブラウザツールは学習、デバッグ、個人的な一時利用のためのものです。本当の機密情報は、監査済みの鍵取り扱いとローテーションを備えた、検証済みの鍵管理システムに属すべきです。AES-256自体は強力であり、NSAのCNSA 2.0スイートでTOP SECRETまで承認されていますが、実際の突破は暗号方式ではなく実装ミスから生じます。

AES暗号化に関するFAQ