量子コンピュータはまだあなたの暗号を脅かしてはいません。RSA-2048 を破れる量子コンピュータには、誤り訂正された論理量子ビットが数百万個必要ですが、現在私たちが手にしているのは、ノイズの多い物理量子ビットが数百個です。しかし、ここに問題があります。敵対者は、量子ハードウェアが成熟した後に復号することを狙って、今この瞬間に暗号化されたデータを収集している可能性があるのです。そして、暗号インフラの移行には何年もかかります。
これこそが、2024 年の NIST ポスト量子暗号標準が、2035 年ではなく今日の開発者にとって重要である理由です。
実際の脅威: Shor のアルゴリズム
1994 年、Peter Shor は、量子コンピュータが大きな整数を多項式時間 O((log N)³) で素因数分解できることを証明しました。これは、素因数分解が困難であることに安全性を依存している RSA を破ります。同じアルゴリズムは、わずかな変更を加えることで、ECDSA と ECDH の基盤である楕円曲線暗号 (ECC) をも破ります。
破られるもの:
- RSA (暗号化、署名)
- ECDSA (署名 — TLS、SSH、コード署名、Bitcoin で使用)
- ECDH (鍵交換 — TLS、Signal、WhatsApp、iMessage で使用)
- Diffie-Hellman (鍵交換)
破られないもの:
- AES-256 (共通鍵暗号) — Grover のアルゴリズムは二次的な高速化しか提供せず、実効的な鍵強度を 256 ビットから 128 ビットに減らすだけです。これは対処可能です。
- SHA-256、SHA-3 (ハッシュ関数) — 同様に、Grover はわずかな高速化を提供し、安全性は半減しますが、現在の鍵サイズであれば依然として十分に強固です。
- HMAC — 安全
- Argon2、bcrypt (パスワードハッシュ化) — 安全
結論はこうです。非対称暗号は置き換えが必要であり、対称暗号は鍵サイズの引き上げ (AES-128 → AES-256) が必要です。
今収穫し、後で復号する (Harvest Now, Decrypt Later)
脅威は「量子コンピュータが来年には暗号を破る」ということではありません。脅威とは次のようなものです。
- 敵対者が今日、あなたの暗号化された TLS トラフィックを捕捉して保存する
- 2032〜2040 年に、それに対して Shor のアルゴリズムを実行する
- すべてを遡って復号する
「今収穫し、後で復号する」 または HNDL と呼ばれるこの攻撃は、すでに起きています。NSA やその他の諜報機関は、ほぼ間違いなく大量の暗号化トラフィックを保存しています。2022 年の NSA の勧告は、これについて明確に警告しました。
今日 HNDL に対して保護が必要なデータ:
- 国家機密、機密扱いの政府データ
- 長期にわたって有効な個人データ (医療記録、身分証明書類)
- 長期の法的保存要件を伴う金融データ
- 営業秘密と知的財産
- パスワードデータベース (ただし bcrypt/Argon2 は安全)
すぐに心配する必要のないデータ:
- セッショントークン (短命で、10 年後には無価値)
- 一時的なチャットメッセージ (あなたが高価値の標的でない限り)
- 公開情報
NIST のポスト量子標準 (2024)
8 年にわたるコンペティションを経て、NIST は 2024 年 8 月に 3 つのポスト量子暗号アルゴリズムを最終化しました。
ML-KEM (CRYSTALS-Kyber) — 鍵カプセル化
- 置き換え対象: RSA 鍵交換、ECDH
- 安全性の根拠: Module Learning With Errors (MLWE) 問題 — 古典コンピュータと量子コンピュータの双方にとって困難であると考えられている
- 性能: 高速、小さな鍵 (KEM-768 で約 800 バイト)、高速な演算
- 用途: TLS 鍵交換、暗号化された鍵ラッピング、ハイブリッド暗号方式
# Python example using pqcrypto library
from pqcrypto.kem.kyber768 import generate_keypair, encapsulate, decapsulate
public_key, secret_key = generate_keypair()
# Sender encapsulates a shared secret
ciphertext, shared_secret_sender = encapsulate(public_key)
# Receiver decapsulates
shared_secret_receiver = decapsulate(secret_key, ciphertext)
assert shared_secret_sender == shared_secret_receiver
# Now use shared_secret as AES key
ML-DSA (CRYSTALS-Dilithium) — デジタル署名
- 置き換え対象: 署名のための ECDSA、RSA-PSS
- 安全性の根拠: MLWE + MSIS 問題
- 性能: 中程度の鍵サイズ (公開鍵で約 1,312 バイト)、高速な署名
- 用途: コード署名、TLS 証明書、文書署名、JWT 署名
from pqcrypto.sign.dilithium3 import generate_keypair, sign, verify
public_key, secret_key = generate_keypair()
message = b"Deploy to production"
signature = sign(message, secret_key)
# Verify
assert verify(message, signature, public_key)
SLH-DSA (SPHINCS+) — ハッシュベースの署名
- 置き換え対象: 保守的なバックアップとしての ECDSA
- 安全性の根拠: ハッシュ関数のみ — 最も保守的な選択肢
- 性能: より大きな署名 (約 8〜50 KB)、より遅い署名処理
- 用途: 鍵の再利用が懸念される高保証の署名、長期の文書署名
NIST はまた、FALCON (FN-DSA) も標準化しました。これはコンパクトな署名を持つ格子ベースの署名方式で、IoT のような制約の多い環境に適しています。
今すぐやるべきこと: 段階別のアクションプラン
第 1 段階 — 今日やること (低労力・高インパクト)
暗号インベントリを監査する。 カタログ化していないものは移行できません。次を文書化しましょう。
- アプリケーションはどこで TLS を使用しているか? (ほとんどのフレームワークがこれを扱う)
- どこで署名を生成または検証しているか? (JWT、コード署名、PDF 署名)
- どこで非対称鍵交換を使用しているか? (RSA でラップされた AES 鍵、SSH)
- どのライブラリを使用しているか? (OpenSSL、BouncyCastle、AWS KMS など)
AES-128 を AES-256 にアップグレードする。 これは低リスクで即座に実施できます。AES-256 は Grover に対して 128 ビットの安全性に半減しますが、それでも十分に安全です。
あらゆる場所で TLS 1.3 を有効にする。 TLS 1.3 はデフォルトで前方秘匿性 (ECDHE) を使用します。これは、長期鍵が漏洩したとしても過去のセッションを復号できないことを意味します。これにより、TLS トラフィックに対する HNDL が部分的に緩和されます。
第 2 段階 — 今後 6〜18 か月の計画
TLS でハイブリッド鍵交換を採用する。 TLS ワーキンググループは X25519Kyber768 を標準化しました。これは古典的な ECDH と ML-KEM の双方を使用するハイブリッド方式です。Google Chrome、Cloudflare、AWS はすでにこれをサポートしています。これは古典的な安全性を維持しつつ HNDL から保護します。
# Nginx with OpenSSL 3.x + oqs-provider (Open Quantum Safe)
ssl_ecdh_curve X25519Kyber768; # hybrid classical + PQC
新しいシステムでは RSA/ECDSA を ML-DSA に置き換える。 新しいマイクロサービス、新しい JWT 実装、新しい SSH デプロイなど、あらゆる新規構築のものには、ECDSA-256 の代わりに ML-DSA (Dilithium3 または Dilithium5) を使用しましょう。
TLS 証明書のパイプラインを更新する。 ほとんどのパブリック CA はまだ PQC 証明書を発行していませんが、内部署名された証明書やサービスメッシュ証明書には、今日から ML-DSA を使用できます。
第 3 段階 — 長期的な移行 (1〜5 年)
完全な PKI 移行。 RSA/ECC の証明書階層を PQC ベースの CA インフラに置き換えます。これは最も難しい部分です。ハードウェアセキュリティモジュール (HSM)、自動化された証明書ローテーション、証明書チェーンのすべてを更新する必要があります。
ハードウェアと組み込みデバイス。 IoT や組み込みデバイスは、多くの場合リモートでパッチを当てられず、10 年以上の寿命を持ちます。RSA や ECDSA に認証を依存しているそのようなデバイスを監査しましょう。
鍵管理システム。 AWS KMS、Azure Key Vault、HashiCorp Vault — それらの PQC ロードマップと移行スケジュールを確認しましょう。
ライブラリとフレームワークのサポート状況
| プラットフォーム | PQC の状況 |
|---|---|
| OpenSSL 3.x + oqs-provider | プラグイン経由で ML-KEM、ML-DSA、FALCON |
| AWS KMS | ML-KEM ハイブリッド TLS がプレビュー中 |
| Cloudflare | X25519Kyber768 TLS (2023 年から稼働中) |
| Chrome 124+ | X25519Kyber768 TLS |
| Java (BouncyCastle) | CRYSTALS-Kyber、Dilithium |
| Python (pqcrypto) | NIST の全セット |
| Go | golang.org/x/crypto の PQC が開発中 |
| Node.js | ネイティブモジュール経由 (OpenSSL 3.x バインディング) |
| Rust (pqcrypto crate) | NIST の全セット |
1 ページ要約
What breaks: RSA, ECDSA, ECDH, classical DH
What's safe: AES-256, SHA-256, SHA-3, bcrypt, Argon2
New standards: ML-KEM (Kyber) for key exchange
ML-DSA (Dilithium) for signatures
SLH-DSA (SPHINCS+) for conservative signing
Do today: Upgrade AES-128 → AES-256
Enable TLS 1.3 (forward secrecy)
Audit crypto inventory
Do soon: Hybrid TLS key exchange (X25519Kyber768)
ML-DSA for new signature systems
Do in 1-5 yrs: Full PKI migration to PQC
Firmware updates for IoT devices
暗号に対する量子の脅威は現実のものであり、そのタイムラインは不確実です。だからこそ、量子コンピュータが能力を備える前の今、行動を起こすことが正しい判断なのです。