暗号化を導入していても、使うアルゴリズムが時代遅れだったり、鍵長が短すぎたりすれば「気休め」にしかなりません。かつて標準だったDES暗号（56ビット鍵）は現在の計算能力では短時間で解読可能とされており、すでに廃止済みです。それでも古いシステムでは今なお使われているケースがあります。
この記事では、AES・RSA・楕円曲線暗号（ECC）・SHA-256など主要な暗号アルゴリズムの仕組みと強度を、NIST（米国国立標準技術研究所）の推奨基準と合わせて整理します。SSL/TLS設定、データの保管、SSH鍵、パスワード保存など、現場で判断が求められる場面を念頭に解説します。
暗号強度とは何か？
暗号強度とは、暗号化されたデータを解読するのに要する計算量のことです。総当たり攻撃（ブルートフォース）で解読するのに現実的な時間内では不可能であれば「安全」と判断されます。
暗号強度に影響する主な要素は2点です。
・アルゴリズムの安全性: 数学的な構造に既知の脆弱性がないか（攻撃手法が確立されていないか）
・鍵長: 鍵のビット数が1ビット増えるだけで組み合わせが2倍になる。128ビットなら2の128乗通り（約3.4×10の38乗）の組み合わせ
重要なのは「アルゴリズム」と「鍵長」の両方が適切であることです。どちらかが欠けても安全性は保たれません。
また、量子コンピュータの発展によりRSAや楕円曲線暗号は将来的に解読されるリスクが指摘されています。NISTは2024年に耐量子暗号（Post-Quantum Cryptography）の標準アルゴリズムを発表しており、将来への移行計画として意識しておく価値があります。
弱い暗号化が狙われる理由（攻撃者の視点）
攻撃者は暗号化そのものを数学的に解読するよりも、以下のような「実装の穴」を突くほうが現実的に有効とされています。
・廃止済みアルゴリズムの継続使用: DES・RC4・MD5など、解読手法が確立されたアルゴリズムが古いシステムでそのまま動き続けているケース
・短すぎる鍵長: RSA-512・RSA-1024は現在の計算技術で現実的な時間内での解読が可能とされる
・暗号モードの誤用: AESのECBモードは同じ平文ブロックから同じ暗号文が生成されるため、パターンが露出しやすい
・ダウングレード攻撃: 通信途中で古いプロトコル（SSLv3・TLS 1.0）に切り替えさせる手口。サーバー側の無効化設定漏れが原因
・鍵管理の不備: コードへのハードコーディングや平文での鍵保存。暗号化が正しくても鍵が露出すれば無意味になる
特にダウングレード攻撃はサーバー設定で容易に防げるにもかかわらず、設定が放置されているケースが少なくありません。
主要暗号アルゴリズムの比較
1. 共通鍵暗号（AES・DES・3DES）
共通鍵暗号（対称暗号）は暗号化と復号に同じ鍵を使います。処理速度が速く、大量データの暗号化に適しています。
| アルゴリズム | 鍵長 | 安全性の現状 | 利用判断 |
|---|---|---|---|
| DES | 56ビット | 解読可能（廃止済み） | 使用禁止 |
| 3DES（TDEA） | 112/168ビット | 脆弱性が報告され廃止方向 | 新規設計では使わない |
| AES-128 | 128ビット | 現在も安全 | 短期利用なら可（長期保管は256を推奨） |
| AES-256 | 256ビット | 高強度 | 推奨（特に長期保管データ） |
AESは2001年にNISTが標準化（FIPS 197）したアルゴリズムで、現在もその数学的安全性に根本的な問題は報告されていません。SSL/TLS・ディスク暗号化・ファイル暗号化など幅広い用途で採用されています。
AESを使う際に注意が必要なのが「暗号モード」です。同じ平文ブロックが同じ暗号文になるECBモードはパターンが漏洩しやすく、使用を避けるべきです。認証付き暗号のGCMモードや、適切にIVを管理するCBCモードが推奨されます。
2. 公開鍵暗号（RSA・楕円曲線暗号）
公開鍵暗号（非対称暗号）は暗号化用の「公開鍵」と復号用の「秘密鍵」のペアで動きます。鍵交換やデジタル署名に使われます。
| アルゴリズム | 推奨鍵長 | 特徴 |
|---|---|---|
| RSA-1024 | — | 現代の計算能力で解読可能なレベル。廃止 |
| RSA-2048 | 2048ビット | 現在の最低ライン。2030年以降は不推奨 |
| RSA-3072 | 3072ビット | 2030年以降も利用するシステムに推奨 |
| ECC（P-256） | 256ビット | RSA-3072相当の強度。処理が速くIoTにも適用可 |
| ECC（P-384） | 384ビット | RSA-7680相当の強度。高セキュリティ用途向け |
ECCは同等の安全性をより短い鍵長で実現できるため、処理性能に制約のあるモバイルデバイスやIoT機器にも適しています。最新のTLS 1.3では鍵交換にRSAではなくECDHE（楕円曲線ディフィー・ヘルマン）が主流になっています。
公開鍵暗号の仕組みについては、公開鍵暗号の詳細解説記事もあわせて参照してください。
3. ハッシュ関数（SHA-256・SHA-3）
ハッシュ関数はデータの「指紋」となる固定長の値を生成する一方向関数です。同じデータからは必ず同じハッシュ値が生成され、ハッシュ値から元データを復元することはできません。
| アルゴリズム | 出力長 | 安全性の現状 |
|---|---|---|
| MD5 | 128ビット | 衝突攻撃が実証済み（証明書偽造等に悪用事例あり）。使用禁止 |
| SHA-1 | 160ビット | 衝突耐性が破られた。新規利用禁止 |
| SHA-256 | 256ビット | 現在の標準。広く推奨 |
| SHA-384 | 384ビット | 高セキュリティ用途向け |
| SHA-3 | 224/256/384/512ビット | SHA-2とは異なる設計原理。NIST標準化済み（FIPS 202） |
ハッシュ関数はデジタル署名の検証・ファイル整合性確認・パスワード保存など幅広く使われます。ただし、パスワード保存にSHA-256などの汎用ハッシュをそのまま使うのは危険です。計算コストを意図的に上げた鍵導出関数（KDF）を使う必要があります（後述）。
NIST推奨基準で選ぶ正しい鍵長
NISTはSP 800-57「暗号鍵管理の推奨事項」と SP 800-131Aでアルゴリズムごとの安全性レベルを定義しています。
| アルゴリズム | 2030年まで | 2030年以降も利用する場合 |
|---|---|---|
| AES | 128ビット以上 | 128ビット以上（256ビット推奨） |
| RSA | 2048ビット以上 | 3072ビット以上 |
| ECC | P-224以上 | P-256以上 |
| SHA（ハッシュ） | SHA-256以上 | SHA-256以上 |
長期保管が必要なデータ（医療記録・契約書・個人情報など）は、将来の計算技術向上を見越してより強い設定（AES-256・RSA-3072以上）を選ぶのが適切です。
なお、量子コンピュータ対策として耐量子暗号（PQC）への移行が将来的に必要になります。現時点での既存システムへの即時適用は不要ですが、新規設計では移行コストを見越した設計にしておくと安心です。
用途別アルゴリズム選択指針
1. データの暗号化（保存・転送）
・ファイルおよびディスク暗号化: AES-256（GCMモード推奨）
・HTTPS / TLS通信: TLS 1.3 + ECDHE（P-256以上）による鍵交換 + AES-256-GCM
・メール暗号化（S/MIME）: AES-256 + RSA-2048以上（またはECC P-256）
・クラウドストレージ: AWS S3・Azure Blob・Google Cloud Storageはいずれもサービス側でAES-256暗号化オプションを提供している。設定の有効化を確認すること
TLS設定については、SSLv3・TLS 1.0・TLS 1.1を無効化し、TLS 1.2以上（できればTLS 1.3）を優先することが重要です。詳しくはTLS 1.3移行と暗号スイート設定ガイドを参照してください。
2. デジタル署名と認証
・SSL/TLS証明書の署名: SHA-256 + RSA-2048以上（またはECDSA P-256）
・コード署名: SHA-256以上 + RSA-2048以上
・SSH鍵認証: Ed25519（楕円曲線ベース・256ビット相当・処理が速く現代的）またはRSA-4096
・JWTトークン署名: RS256（RSA-SHA256）またはES256（ECDSA-P256）を使用。HS256（共通鍵）は鍵共有が難しい場面では避ける
SSHの鍵認証ではEd25519への移行を検討する価値があります。古いRSA-2048よりも処理が速く、現代的な設計です。
3. パスワード保存
パスワードをデータベースに保存する際は、汎用ハッシュ（SHA-256など）をそのまま使ってはいけません。高速なハッシュはGPUによる総当たり攻撃を受けやすいためです。
・Argon2id: NISTおよびOWASPが現在推奨する最新のKDF。メモリハード設計によりGPU/ASIC攻撃への耐性が高い
・bcrypt: コスト係数12以上を設定。長年の実績があり信頼性が高い
・scrypt: Argon2idに次ぐ選択肢。一部フレームワークで標準採用
パスワードの保存方式については、パスワードのハッシュ化とソルトに関する解説記事で詳しく解説しています。
中小企業でも今日からできること
暗号アルゴリズムの選定は開発者の領域に思えますが、情シス担当者が確認・設定できることは多くあります。
・Webサーバーの暗号化設定をチェックする: SSL LabsのSSL Server Test（https://www.ssllabs.com/ssltest/）を使えば、外部から見た暗号化設定を無料で確認できる。TLS 1.0/1.1が有効になっていないか、弱い暗号スイートが使われていないかを確認しよう
・クラウドサービスの暗号化設定を確認する: AWS・Azure・GCPなどの管理コンソールで、ストレージ・データベース・バックアップの暗号化が有効になっているか確認する
・SSH鍵の棚卸しをする: サーバーの ~/.ssh/authorized_keys に古いRSA-1024の鍵が残っていないか確認し、Ed25519またはRSA-4096への更新を計画する
・VPN装置の証明書を確認する: 使用しているVPN機器の証明書がSHA-1やRSA-1024を使っていないか、管理コンソールで確認する
・自社アプリのパスワード保存方式を確認する: 自社開発・導入するWebアプリケーションのパスワード保存にMD5やSHA-1が使われていないか開発部門に確認する
まず「Webサーバーの設定確認」からはじめると、即日で現状把握ができます。既存システムへの影響なく調査だけ完了できる点でも着手しやすいです。
よくある誤解と注意点
【誤解1】「AES-256は絶対に安全だ」
アルゴリズム自体は安全でも、鍵管理が間違っていれば意味がありません。鍵をコードにハードコーディングしたり、同じディレクトリに鍵ファイルと暗号化済みファイルを置いたりするケースがよく見られます。暗号化の安全性は鍵の管理と一体です（暗号鍵管理の実践ガイド参照）。
【誤解2】「整合性確認ならMD5でも問題ない」
MD5の衝突攻撃（異なるデータから同じハッシュ値を生成する攻撃）は実証済みです。ファイルの改ざん検知にMD5を使うと、意図的に細工されたファイルを正常と判断してしまう可能性があります。整合性確認にはSHA-256以上を使うことが推奨されます。
【誤解3】「TLS 1.2があれば十分でTLS 1.3に移行しなくてよい」
TLS 1.3では前方秘匿性（PFS）が必須化されており、過去の通信記録が後から解読されるリスクが大幅に下がります。また、RSAによる鍵交換が廃止されECDHEが義務化されました。新規構築はTLS 1.3を優先することが推奨されています。
【誤解4】「暗号化さえしていれば個人情報漏洩の責任を問われない」
個人情報保護法・GDPRなどの観点では、暗号化は「リスク軽減の要素」として評価されますが、漏洩そのものの免責にはなりません。また、鍵の管理状態も含めて適切な保護措置が問われます。
本記事のまとめ
| 用途 | 推奨アルゴリズム | 注意点 |
|---|---|---|
| データ暗号化（保存） | AES-256（GCMモード） | ECBモードは使わない |
| TLS通信 | TLS 1.3 + ECDHE + AES-256 | TLS 1.0/1.1・SSLv3は無効化 |
| デジタル署名 | SHA-256 + ECDSA P-256以上 | SHA-1・MD5は廃止済み |
| SSH鍵認証 | Ed25519またはRSA-4096 | RSA-1024は廃止 |
| パスワード保存 | Argon2idまたはbcrypt | SHA-256単独・MD5は禁止 |
| 公開鍵暗号（一般） | RSA-3072以上またはECC P-256以上 | RSA-1024は廃止。2030年以降はRSA-3072+ |
「暗号化している」と「正しく暗号化している」は別物です。アルゴリズムの選択・鍵長・実装方法・鍵管理のすべてが揃って初めて意味を持ちます。少なくとも年に一度、使用中の暗号アルゴリズムの棚卸しをする習慣をつけると、廃止済みの仕様が残り続けるリスクを防ぐことができます。
Linuxサーバー上でのディスク暗号化やOpenSSLの設定については、姉妹サイトLinuxMaster.JPでも実践的な手順を解説しています。
