鍵長とは
鍵長(Key Length)は、暗号鍵のビット数を表し、暗号の強度に直接関係します。鍵長が長いほど、ブルートフォース攻撃(総当たり攻撃)に対する耐性が高くなりますが、計算コストも増加します。
鍵長を1ビット増やすと、鍵の候補数は2倍になります。つまり、128ビット鍵には2^128 ≈ 3.4×10^38通りの候補があり、現在の技術では総当たりでの解読は事実上不可能です。
アルゴリズム別の推奨鍵長
| アルゴリズム | 最小 | 推奨 | 備考 |
|---|---|---|---|
| AES | 128ビット | 256ビット | 量子耐性を考慮すると256推奨 |
| RSA | 2048ビット | 3072-4096ビット | 2030年以降は3072以上推奨 |
| ECDSA/ECDH | 256ビット | 384ビット | P-256, P-384曲線 |
| Ed25519 | 256ビット | 256ビット | 固定長、効率的 |
| Diffie-Hellman | 2048ビット | 3072ビット | Logjam対策 |
セキュリティレベルの等価性
異なるアルゴリズムの鍵長を比較するための等価なセキュリティレベル:
セキュリティビット | 対称鍵 | RSA | ECC
128 | AES-128 | RSA-3072 | P-256
192 | AES-192 | RSA-7680 | P-384
256 | AES-256 | RSA-15360 | P-521
AIエンジニアとしての実体験
AIモデルの保護システムを設計する際、データの機密性に応じて適切な鍵長を選択しました。医療AIプロジェクトでは、規制要件(HIPAA)を満たすためAES-256を採用しています。
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend
import os
def encrypt_with_aes256(data: bytes) -> tuple:
"""AES-256-GCMで暗号化"""
key = os.urandom(32) # 256ビット = 32バイト
nonce = os.urandom(12)
cipher = Cipher(
algorithms.AES(key),
modes.GCM(nonce),
backend=default_backend()
)
encryptor = cipher.encryptor()
ciphertext = encryptor.update(data) + encryptor.finalize()
return key, nonce, ciphertext, encryptor.tag
# RSA鍵長の確認
from cryptography.hazmat.primitives.asymmetric import rsa
def generate_rsa_key(key_size: int = 4096):
"""指定したビット長でRSA鍵を生成"""
private_key = rsa.generate_private_key(
public_exponent=65537,
key_size=key_size,
backend=default_backend()
)
return private_key
自社サーバー運用への応用
TLS設定での鍵長確認
# サーバー証明書の鍵長確認
openssl x509 -in cert.pem -noout -text | grep "Public-Key"
# リモートサーバーの鍵長確認
echo | openssl s_client -connect example.com:443 2>/dev/null | \
openssl x509 -noout -text | grep -E "Public-Key|RSA"
# SSH鍵の鍵長確認
ssh-keygen -l -f ~/.ssh/id_rsa.pub
適切な鍵長の選択ガイドライン
- 短期データ(数日〜数ヶ月):最小推奨値で十分
- 中期データ(数年):推奨値を使用
- 長期データ(10年以上):最大値または次世代アルゴリズムを検討
関連ブログ記事
📝 関連記事
最新動向(2026年)
ポスト量子暗号への移行
量子コンピュータの脅威に備え、NISTはより長い鍵長を持つポスト量子暗号アルゴリズム(Kyber、Dilithium)を標準化しました。これらは従来より大きな鍵サイズを使用します。
RSA鍵長の再評価
計算能力の向上により、NISTとBSIは2030年以降のRSA-2048の使用を非推奨としています。RSA-3072または楕円曲線暗号への移行が推奨されています。
トラブル事例と対策
⚠️ 古い1024ビットRSA鍵の使用
問題:1024ビットRSAは既に安全ではない
対策:最低2048ビット、推奨3072ビット以上のRSA鍵を使用
⚠️ 過剰な鍵長によるパフォーマンス低下
問題:必要以上に長い鍵を使用して処理が遅くなる
対策:ECCを使用すれば短い鍵長で同等のセキュリティを実現可能
権威あるリソース
- keylength.com - 暗号鍵長推奨ガイド
- NIST SP 800-57 - Key Management Recommendations
- BSI TR-02102 - Cryptographic Mechanisms
鍵長設計のメリット・デメリット
鍵長の選択は「安全性」と「処理性能・運用コスト」のトレードオフです。
| メリット | デメリット | |
|---|---|---|
| 長い鍵長 | 総当たり攻撃への耐性が高い。量子コンピュータ(Groverのアルゴリズム等)の将来的な脅威にも余裕を持って対応できる。長期保存データの機密性を確保しやすい。 | 暗号化・復号処理が遅くなる。特にRSAは鍵長増加による処理コスト増が顕著。証明書サイズが大きくなりTLSハンドシェイクの通信量が増える。組込み機器ではメモリ・CPU制約が課題になりやすい。 |
| 短い鍵長 | 処理速度が速く、消費リソースが少ない。IoT機器やモバイル環境など制約の多い環境に適する。 | 計算能力の向上により将来的に解読可能になるリスク。PCI DSSやNISTの基準を満たせず、コンプライアンス違反になる可能性がある。 |
実務では、NIST SP 800-57が示す「2030年」「2031年」といった区切りを目安に、データの保存期間(鍵の暴露期間)を考慮して鍵長を決定することが推奨されます。短期的にしか使わないデータであれば最小推奨値、10年以上保存する必要があるデータには最大値を選択するのが基本方針です。
対称鍵暗号と公開鍵暗号で鍵長の考え方が異なる理由
「AESは128ビットで安全なのに、なぜRSAは2048ビット以上必要なのか」という疑問はよく聞かれます。これは攻撃アルゴリズムの数学的な性質の違いによるものです。
| 項目 | 対称鍵暗号(AES) | 公開鍵暗号(RSA) | 楕円曲線暗号(ECC) |
|---|---|---|---|
| 安全性の根拠 | 総当たり攻撃(指数時間) | 素因数分解問題(準指数時間、一般数体篩法) | 楕円曲線離散対数問題(指数時間) |
| 128ビット相当の安全性に必要な鍵長 | 128ビット | 3072ビット | 256ビット |
| 鍵長を伸ばした際の安全性の伸び方 | 線形的(1ビットで攻撃コスト2倍) | 準指数的(同水準を保つには大幅な鍵長増加が必要) | ほぼ線形的(AESに近い効率) |
RSAには準指数時間で解ける攻撃アルゴリズム(一般数体篩法:GNFS)が存在するため、対称鍵と同じ安全性強度を得るには非常に長い鍵長が必要です。一方ECCは既知の効率的な準指数時間アルゴリズムが存在しないため、AESに近い短い鍵長で高い安全性を実現できます。これが、近年のTLS証明書でRSA-2048/3072よりもECDSA P-256が好まれる技術的な理由です。
関連用語
よくある質問(FAQ)
Q. 暗号鍵長はなぜ重要ですか?
暗号の安全性は鍵長に大きく依存します。鍵長が1ビット増えるごとに総当たり攻撃に必要な計算量が2倍になります。NIST(2022年)はアルゴリズムに応じた推奨鍵長を公表しており、例えばAESは128ビット以上(推奨256ビット)、RSAは3072ビット以上(2031年以降)、ECCは256ビット以上を推奨しています。
Q. AES-128とAES-256はどちらが良いですか?
AES-128もAES-256もともに現時点では安全ですが、AES-256は量子コンピュータ(Groverのアルゴリズム)への対策としてNISTが推奨しています。量子コンピュータはAES-128の実効鍵長を64ビットに半減させるため、長期的なセキュリティが必要な場合はAES-256を選ぶべきです。ただし、パフォーマンスへの影響は通常1〜5%程度です。
Q. RSAの推奨最小鍵長は何ビットですか?
NIST SP 800-131A Rev. 2(2019年)では2031年以降はRSA-2048が使用禁止となり、RSA-3072以上が必要です。現在のTLS証明書でよく見られるRSA-2048は2030年まで許容されます。ただし新規システムではRSA-3072またはECC P-256(RSA-3072相当)の使用を推奨します。
