.NET 10の耐量子暗号で未来に備える5つのポイント

量子コンピュータの実用化が現実味を帯びてきた今、「ポスト量子時代」への備えが急務になっています。量子コンピュータは、従来のコンピュータでは解くのに数千年かかる問題を数時間で解いてしまう可能性があり、現在広く使われている暗号技術の多くが無力化される恐れがあります。2025年11月にリリースされた.NET 10では、耐量子暗号（Post-Quantum Cryptography、PQC）が正式にサポートされました。この記事では、.NET 10のPQC機能を実務で活用するための5つのポイントを解説します。

量子コンピュータが暗号を破る日

「量子コンピュータが実用化されたら、現在の暗号は全部破られる」という話を聞いたことがあるでしょうか。これは半分正解で、半分間違いです。すべての暗号が危険というわけではなく、影響を受ける暗号と受けない暗号があります。

実際に影響を受けるのは、RSAや楕円曲線暗号（ECDSA、ECDH）などの「公開鍵暗号」です。これらは「大きな数の素因数分解」や「離散対数問題」の計算困難性に安全性の根拠を置いていますが、量子コンピュータのショアのアルゴリズムを使えば、これらを効率的に解けてしまいます。現在のTLS通信、デジタル証明書、電子署名の多くがこれらの暗号に依存しているため、影響は甚大です。

一方、AESやChaCha20などの「共通鍵暗号」は、グローバーのアルゴリズムで鍵長が実質半分になる程度の影響に留まります。つまり、AES-256を使っていれば、量子コンピュータに対してもAES-128相当の安全性を維持できます。

NISTは長年の標準化プロセスを経て、2024年にML-KEM（旧CRYSTALS-Kyber）、ML-DSA（旧CRYSTALS-Dilithium）、SLH-DSA（旧SPHINCS+）を正式な耐量子暗号標準として発表しました。.NET 10はこれらのアルゴリズムをネイティブでサポートしています。

ポイント1：ML-KEMで鍵交換を量子耐性化

ML-KEM（Module-Lattice-Based Key-Encapsulation Mechanism）は、格子暗号に基づく鍵カプセル化メカニズムです。TLSにおけるECDHの代替として設計されており、安全な鍵交換を実現します。

ML-KEMには、セキュリティレベルに応じて3つのパラメータセットがあります。ML-KEM-512はNISTセキュリティレベル1（AES-128相当）、ML-KEM-768はレベル3（AES-192相当）、ML-KEM-1024はレベル5（AES-256相当）です。多くのユースケースでは、バランスの取れたML-KEM-768が推奨されます。

using System.Security.Cryptography;

// 鍵ペア生成（ML-KEM-768を使用）
using var mlKem = MLKem.GenerateKey(MLKemParameterSet.MLKem768);

// 公開鍵をエクスポート（相手に送信）
byte[] publicKey = mlKem.ExportPublicKey();
Console.WriteLine($"公開鍵サイズ: {publicKey.Length} bytes"); // 約1,184 bytes

// 受信側：公開鍵を使ってカプセル化
var (ciphertext, sharedSecret1) = MLKem.Encapsulate(publicKey);
Console.WriteLine($"暗号文サイズ: {ciphertext.Length} bytes"); // 約1,088 bytes

// 送信側：秘密鍵で復号
byte[] sharedSecret2 = mlKem.Decapsulate(ciphertext);

// sharedSecret1 == sharedSecret2 が成立
// この共有秘密を使って対称暗号（AES等）の鍵として使用

注目すべきは、ML-KEMは「暗号化」ではなく「鍵カプセル化」であるという点です。直接データを暗号化するのではなく、対称鍵を安全に共有するために使用します。実際のデータ暗号化は、この共有秘密から導出した鍵を使ってAESなどで行います。

ポイント2：ML-DSAでデジタル署名を保護

ML-DSAは格子暗号に基づくデジタル署名アルゴリズムです。RSAやECDSAの代替として使用でき、ソフトウェアの署名、証明書の発行、文書の電子署名などに活用できます。

ML-DSAにもML-KEM同様に3つのパラメータセットがあります。ML-DSA-44、ML-DSA-65、ML-DSA-87で、数字が大きいほど安全性が高くなりますが、鍵と署名のサイズも大きくなります。

using System.Security.Cryptography;

// 鍵ペア生成
using var mlDsa = MLDsa.GenerateKey(MLDsaParameterSet.MLDsa65);

// 公開鍵のエクスポート（検証者に配布）
byte[] publicKey = mlDsa.ExportPublicKey();
Console.WriteLine($"公開鍵サイズ: {publicKey.Length} bytes"); // 約1,952 bytes

// 署名対象データ
byte[] data = System.Text.Encoding.UTF8.GetBytes("この文書の内容を保証します");

// 署名生成
byte[] signature = mlDsa.Sign(data);
Console.WriteLine($"署名サイズ: {signature.Length} bytes"); // 約3,293 bytes

// 署名検証
bool isValid = mlDsa.Verify(data, signature);
Console.WriteLine($"署名検証結果: {isValid}"); // True

// 改ざん検出のデモ
byte[] tamperedData = System.Text.Encoding.UTF8.GetBytes("この文書の内容を改ざんしました");
bool isTamperedValid = mlDsa.Verify(tamperedData, signature);
Console.WriteLine($"改ざんデータの検証: {isTamperedValid}"); // False

ポイント3：ハッシュベース署名SLH-DSAの選択肢

SLH-DSA（Stateless Hash-Based Digital Signature Algorithm）は、ハッシュ関数の安全性のみに依存するデジタル署名アルゴリズムです。格子暗号とは異なる数学的基盤を持つため、「もし格子暗号に脆弱性が発見された場合」のバックアップとして重要な役割を果たします。

SLH-DSAの特徴は、数十年にわたって研究されてきたハッシュ関数の安全性に基づいている点です。新しい数学的仮定に依存しないため、保守的なセキュリティ要件がある場面で選択されることがあります。ただし、署名サイズがML-DSAと比べて大きくなる傾向があります。

.NET 10ではSLHDsaクラスとして実装されており、APIはML-DSAと同様のパターンで使用できます。長期保存が必要な文書の署名や、特に高いセキュリティが求められる用途に適しています。

ポイント4：Experimental属性と移行戦略

.NET 10のPQC APIには[Experimental]属性が付与されています。これは、APIが将来変更される可能性があることを示しています。PQCの標準化は進行中であり、パフォーマンス最適化や相互運用性の改善が今後も行われる見込みです。

実務での移行戦略としては、「ハイブリッド暗号方式」の採用がお勧めです。これは、従来の暗号（ECDH + ECDSA）と耐量子暗号（ML-KEM + ML-DSA）を組み合わせて使用するアプローチです。両方の暗号を同時に破らない限り安全性が維持されるため、移行期間中のリスクを最小化できます。

// ハイブリッド鍵交換の概念例
public class HybridKeyExchange
{
    public static (byte[] hybridSharedSecret, byte[] ecdhCiphertext, byte[] mlkemCiphertext) 
        Encapsulate(byte[] ecdhPublicKey, byte[] mlKemPublicKey)
    {
        // 従来のECDH
        using var ecdh = ECDiffieHellman.Create();
        var ecdhResult = ecdh.DeriveKeyMaterial(/* ... */);
        
        // 耐量子暗号 ML-KEM
        var (mlkemCiphertext, mlkemSharedSecret) = MLKem.Encapsulate(mlKemPublicKey);
        
        // 両方の共有秘密を結合してハッシュ
        using var sha = SHA256.Create();
        var combined = ecdhResult.Concat(mlkemSharedSecret).ToArray();
        var hybridSecret = sha.ComputeHash(combined);
        
        return (hybridSecret, /* ecdhCiphertext */, mlkemCiphertext);
    }
}

ポイント5：パフォーマンスと互換性の考慮

PQCの導入にあたっては、パフォーマンスと互換性のトレードオフを理解することが重要です。鍵サイズと署名サイズは従来の暗号と比較して大幅に増加します。これはネットワーク帯域やストレージに影響を与える可能性があります。

一方で、演算速度については格子暗号の方が速いケースも多いです。特にML-KEMの鍵カプセル化は、ECDHよりも高速に動作することがあります。実際のパフォーマンスはハードウェアや実装に依存するため、本番導入前にベンチマークを実施することをお勧めします。

また、既存システムとの互換性も重要な考慮事項です。PQCをサポートしていないシステムとの通信が必要な場合は、ハイブリッド方式や段階的な移行が必要になります。TLSでのPQCサポートも進んでおり、主要なブラウザやサーバーソフトウェアで対応が進んでいます。

「Harvest Now, Decrypt Later」攻撃への備え

PQC移行を今から始めるべき最大の理由は、「Harvest Now, Decrypt Later」（HNDL）攻撃のリスクです。これは、現在暗号化されたデータを傍受・保存しておき、将来量子コンピュータが実用化された際に復号するという攻撃手法です。

長期間機密性を維持する必要があるデータ（医療記録、政府機密、知的財産など）を扱う組織は、量子コンピュータの実用化を待たずに今からPQCへの移行を検討すべきです。データが10年後、20年後も機密である必要があるなら、今日から耐量子暗号で保護することに価値があります。

まとめ

.NET 10の耐量子暗号サポートは、ポスト量子時代への重要な一歩です。ML-KEMで鍵交換を、ML-DSAで署名を、そしてバックアップとしてSLH-DSAを活用することで、量子コンピュータの脅威に備えることができます。量子コンピュータの実用化時期は不確実ですが、HNDL攻撃を考えると、今から準備を始めることには十分な価値があります。まずは開発環境で.NET 10のPQC APIを試し、自社システムへの影響を評価することから始めてみてはいかがでしょうか。

参考リンク

• NIST Post-Quantum Cryptography - 公式サイト
• .NET 10 What's New - Microsoft Learn
• CRYSTALS - Kyber and Dilithium