「このファイルはパスワードで保護してから送って」と頼まれたり、ZIPの暗号化設定に「AES-256」という 文字列を見かけたりしたことはないでしょうか。現代のWeb通信・ファイル暗号化・パスワード管理ソフト—— ありとあらゆる場面の裏側で動いているのがAES（Advanced Encryption Standard）です。 この記事では、AES-256という名前がなぜ出てくるのか、共通鍵暗号の基本から、ブロック暗号のモード・IV・ パスワード派生までを通しで解説します。
AES（Advanced Encryption Standard）とは
AESは、米国国立標準技術研究所（NIST）が2001年に標準化した共通鍵ブロック暗号です。 それ以前の標準だったDES（Data Encryption Standard）が鍵長56ビットで総当たり攻撃に脆弱になったため、 公募・選考を経てベルギーの研究者が設計した「Rijndael（ラインダール）」が後継として採用されました。
鍵長は128ビット・192ビット・256ビットの3種類から選べ、それぞれAES-128・AES-192・AES-256と呼ばれます。 TLS（HTTPS通信）・ディスク暗号化（BitLocker / FileVault）・無線LAN（WPA2/WPA3）・パスワード付きZIP・ iPhoneのデータ保護など、身の回りのほぼすべての暗号化でAESが使われています。
共通鍵暗号と公開鍵暗号の違い
暗号方式は大きく2つに分けられます。AESは「共通鍵暗号」、RSAや楕円曲線暗号は「公開鍵暗号」です。
| 方式 | 鍵の使い方 | 速度 | 代表例 | 主な用途 |
|---|---|---|---|---|
| 共通鍵暗号 | 暗号化と復号で同じ鍵 | 速い | AES・ChaCha20 | 大容量データ・通信本体 |
| 公開鍵暗号 | 公開鍵で暗号化・秘密鍵で復号 | 遅い | RSA・ECC | 鍵交換・デジタル署名 |
共通鍵暗号は「送信者と受信者が同じ鍵を事前に共有しておく必要がある」という課題を抱えています。 この問題を解決するため、実務では公開鍵暗号で共通鍵を安全に共有し、本体データは共通鍵暗号で暗号化するハイブリッド暗号が広く使われています（TLSやPGPがまさにこの構成です）。
ブロック暗号の仕組み — 16バイト単位で処理する
AESはブロック暗号の一種で、平文を16バイト（128ビット）ごとに区切って暗号化します。 鍵長が128ビットでも256ビットでも、ブロックサイズは常に16バイト固定です。
各ブロックに対して、鍵から生成した「ラウンド鍵」を使い、バイト置換・行シフト・列混合・鍵加算という 4種類の変換を10〜14ラウンド繰り返します。この繰り返しによって、入力の1ビット変化が出力の ほぼ全ビットに伝わる「雪崩効果」が生まれ、鍵なしで元に戻すことが事実上不可能になります。
# 16バイトブロックへの分割イメージ
平文: "Hello, panda-tools world!" (25バイト)
├─ ブロック1: "Hello, panda-too" (16バイト)
└─ ブロック2: "ls world!" + パディング (16バイト)
# 各ブロックをAESで変換 → 暗号文ブロックになる
データが16バイトの倍数でない場合はパディング（PKCS#7など）で末尾を埋めます。 復号時にはこのパディングを取り除いて元の平文長に戻します。
暗号化モード — ECB・CBC・GCMの違い
ブロック暗号は「16バイト単位の変換」を定義しているだけなので、長いデータを暗号化するには 「複数ブロックをどうつなげるか」を決める必要があります。これが暗号利用モードです。
| モード | 特徴 | 改ざん検知 | 安全性 | 主な用途 |
|---|---|---|---|---|
| ECB | 各ブロックを独立に暗号化 | なし | ×（使用禁止） | — （使ってはいけない） |
| CBC | 前ブロックの暗号文と連鎖 | なし（別途HMAC必要） | △（実装に注意） | 従来のTLS・ZIP暗号化 |
| GCM | カウンター方式＋認証タグ | あり（AEAD） | ◎（現在の標準） | TLS 1.3・最新のファイル暗号化 |
ECBペンギン問題
ECBモードで画像を暗号化すると、同じ色のピクセルブロックが同じ暗号文ブロックになるため、 Tuxペンギンのような画像では輪郭がそのまま残ってしまいます。これが「ECBを使ってはいけない」と 教科書に必ず書かれている理由です。新規実装で選択肢に入れる必要はありません。
現在の新規実装ではGCMが第一選択です。暗号化と同時に「認証タグ」を生成し、復号時に データが改ざんされていないかを検知できます（AEAD: Authenticated Encryption with Associated Data）。 CBC単体では改ざん検知ができず、別途HMACと組み合わせる必要がありますが、その組み合わせ方を 間違えると脆弱性（Padding Oracle攻撃など）につながります。
IV（初期化ベクトル）とは
同じ平文を同じ鍵で暗号化しても毎回違う暗号文になるように仕組むのがIV（Initialization Vector、初期化ベクトル）です。 GCMモードでは「nonce（ナンス、使い捨て番号）」とも呼ばれます。
IVがなぜ必要かというと、同じ平文＋同じ鍵から常に同じ暗号文が出ると、攻撃者が 「この暗号文はあの文章だ」と推測できてしまうためです。たとえば同じパスワードを使ったログイン通信が 毎回同じバイト列になると、通信を傍受する攻撃者にパターンを読まれます。 IVを毎回変えれば、同じ平文でも毎回異なる暗号文が生成されます。
IVは秘密ではないが、重要
IVは暗号文と一緒に送っても問題ありません（復号側にも必要なので）。 ただし同じ鍵で同じIVを二度使うと致命的です。特にGCMではnonceの再利用で 鍵が実質的に漏れる危険があるため、必ずランダム生成またはカウンターで一意性を確保します。 IV自体のランダム性確保には、ぱんだツールズのランダム文字列生成ツールのような暗号論的乱数生成器（CSPRNG）ベースの仕組みが欠かせません。
パスワードから鍵を作る — PBKDF2・scrypt・Argon2
AESの鍵は128〜256ビットの「ランダムなビット列」が前提ですが、ユーザーが入力するのは 人間が覚えられる短いパスワードです。この2つのギャップを埋めるのが鍵派生関数（KDF: Key Derivation Function）です。
パスワードをそのまま鍵として使うと、いくつか致命的な問題が起きます。①エントロピー不足 （"password123"のような弱い鍵になる）、②長さが足りない（8文字は64ビットでAESには短すぎる）、 ③辞書攻撃（よくあるパスワード数千万件の事前計算で突破される）。 これらを同時に解決するのがKDFの役割です。
| 関数名 | 特徴 | 対耐性 | 採用例 |
|---|---|---|---|
| PBKDF2 | HMAC-SHA256を数十万回反復 | CPU時間 | TLS・WebCrypto API・1Password |
| scrypt | メモリを大量消費する設計 | CPU時間 + メモリ | Litecoin・一部のパスワードマネージャー |
| Argon2 | 2015年のコンペ優勝・最新標準 | CPU時間 + メモリ + 並列度 | 新規実装の推奨（RFC 9106） |
どのKDFも「意図的に遅い計算」を行うのがポイントです。正規ユーザーは1回しか実行しないので 0.1秒程度の遅延は気になりませんが、総当たり攻撃側は数十億回の試行で指数関数的に時間がかかります。 また必ずソルト（ランダムな追加データ）を入れることで、同じパスワードでも 毎回異なる鍵が派生し、レインボーテーブル攻撃を無効化できます。
AES vs ハッシュ関数 — 暗号化とハッシュ化は別物
混同されがちですが、AESによる暗号化とSHA-256のようなハッシュ化は目的も性質もまったく異なります。
| 項目 | AES（暗号化） | SHA-256（ハッシュ化） |
|---|---|---|
| 可逆性 | 可逆（鍵があれば復号可能） | 不可逆（元に戻せない） |
| 鍵 | 必要 | 不要 |
| 出力サイズ | 入力とほぼ同じ | 固定長（256ビット） |
| 主な用途 | 秘密を送る・保存する | 改ざん検知・データ識別・パスワード保存 |
「パスワードを暗号化してDBに保存する」というのは誤った設計で、正しくは「パスワードをハッシュ化して保存する」です。 暗号化だと鍵さえ漏れれば全パスワードが平文に戻せてしまいますが、ハッシュ化なら元に戻す方法が存在しません。 ハッシュ値の詳しい話はハッシュ値生成ツールや関連ガイドを参照してください。
実務でのAESの使われ方
AESは多くの場面で使われていますが、代表的な使い方を3つ整理します。
1. ファイル・メッセージの暗号化
ZIPのAES-256暗号化・BitLocker / FileVaultのディスク暗号化・パスワードマネージャーの金庫などが代表例です。 ユーザーが入力するパスワードからKDFで鍵を派生させ、AES-GCMまたはAES-CBCでデータを暗号化します。 ぱんだツールズのテキスト暗号化/復号ツールもこの方式で、ブラウザ内でAES-256-GCM + PBKDF2によりパスワードから鍵派生を行って暗号化しています。
2. 通信の暗号化（TLS・VPN）
HTTPS通信の内部では、まずTLSハンドシェイクで公開鍵暗号を使いAESの一時セッション鍵を共有し、 その後の本体通信はすべてAES（現代のTLS 1.3ではAES-128-GCMまたはAES-256-GCM）で暗号化されます。 このハイブリッド方式により、公開鍵暗号の「鍵共有のしやすさ」と共通鍵暗号の「速さ」を両立しています。
3. 保存データの暗号化（at-rest encryption）
クラウドストレージ・データベース・スマートフォンの内部ストレージなど、保存中のデータを暗号化する 用途でもAESが使われます。AWS KMS・Google Cloud KMSなどの鍵管理サービスも、実体はAES-256による エンベロープ暗号化で構成されています。ユーザー視点では意識しませんが、裏で常にAESが動いています。
ぱんだツールズでAESを体験する
理屈だけでは掴みにくいので、実際に試すのが一番です。テキスト暗号化/復号ツールにテキストとパスワードを入力すると、ブラウザ内でAES-256-GCMの暗号化が実行され、 同じテキスト＋同じパスワードでも毎回違う暗号文（IVが毎回変わるため）が出力されることを確認できます。
強いパスワードの選定にはパスワード生成ツールを、IVやソルトに必要な高エントロピーのランダム文字列にはランダム文字列生成ツールを組み合わせると、実務相当の構成をブラウザだけで再現できます。 いずれのツールもファイル・入力データはサーバーに送信されず、すべてブラウザ内で完結します。
まとめ
- AESは2001年にNISTが標準化した共通鍵ブロック暗号で、鍵長は128/192/256ビットの3種類
- 共通鍵暗号は高速・公開鍵暗号は鍵共有に強く、実務はハイブリッドで組み合わせる
- AESは16バイト単位で処理するブロック暗号。長いデータにはモードが必要
- モードはECB（使用禁止）・CBC（改ざん検知なし）・GCM（現在の推奨）
- IVは毎回変えて同じ平文でも違う暗号文になるようにする。GCMではnonceの再利用は絶対NG
- パスワードから鍵を作るときはPBKDF2・scrypt・Argon2などのKDFを使い、ソルトを必ず入れる
- 暗号化（可逆・鍵あり）とハッシュ化（不可逆・鍵なし）は別物。パスワード保存はハッシュ化
- ZIP暗号化・TLS・ディスク暗号化・クラウドストレージなど、身の回りのほぼすべてでAESが動いている