QuantumDataProtection 2.0.2

QuantumDataProtection

Turkce dokumantasyon icin tiklayiniz

Post-quantum key wrapping for ASP.NET Core Data Protection using ML-KEM (FIPS 203).

The first and only NuGet package that replaces RSA key wrapping with quantum-resistant key encapsulation — protecting cookies, sessions, and anti-forgery tokens against harvest-now-decrypt-later attacks.

Why This Exists

ASP.NET Core Data Protection encrypts cookies, session state, and anti-forgery tokens. The payload uses AES-256 (quantum-safe). But the master key is wrapped with RSA (not quantum-safe).

"Harvest now, decrypt later" attackers record encrypted traffic today. When quantum computers arrive, they crack the RSA key envelope and access every cookie and session ever protected.

AES is fine. The RSA envelope is the problem. We replace it with ML-KEM.

As of this writing, no other NuGet package provides ML-KEM-based key wrapping for ASP.NET Core Data Protection. Microsoft ships the raw ML-KEM primitives in .NET 10, but not the Data Protection integration — this package fills that gap.

Quick Start

dotnet add package QuantumDataProtection

builder.Services.AddDataProtection()
    .ProtectKeysWithMlKem(options =>
    {
        options.Algorithm = MlKemAlgorithms.MlKem768;   // FIPS 203, recommended
        options.KeyStoreDirectory = "/var/keys";
        options.KeyStorePassword = config["KeyPassword"];
    });

That's it. Cookies, sessions, anti-forgery tokens — now quantum-resistant.

Migrating from RSA / Certificate Protection

Already using ProtectKeysWithCertificate() or DPAPI? Existing keys remain readable — zero downtime:

builder.Services.AddDataProtection()
    .ProtectKeysWithMlKem(options =>
    {
        options.Algorithm = MlKemAlgorithms.MlKem768;
        options.KeyStoreDirectory = "/var/keys";
        options.KeyStorePassword = config["KeyPassword"];

        // Tell the hybrid decryptor how to read old keys
        options.LegacyDecryptorType = typeof(CertificateXmlDecryptor);
    });

What happens:

Day 0:   Deploy — old cookies/sessions keep working (legacy decryptor)
         New keys are wrapped with ML-KEM (quantum-safe)
Day 90:  Old keys expire naturally
Day 91:  Set EnableLegacyKeyDecryption = false
         Fully quantum-safe, no RSA dependency

How It Works

                    Data Protection Pipeline

    [Application Payload: cookies, sessions, anti-forgery tokens]
                  |
                  | Encrypted by ASP.NET Core Data Protection
                  | (AES-based, quantum-safe — unchanged by this package)
                  ↓
    [Master XML Key] ← must be protected at rest
                  |
        +---------+---------+
        |  DEFAULT           |   RSA key wrapping
        |  (ASP.NET Core)    |   (quantum-VULNERABLE)
        +---------+---------+
                  |
        +---------+---------+
        |  WITH THIS PACKAGE |   ML-KEM key encapsulation (quantum-SAFE)
        |                    |   XML key wrapped with AES-256-GCM
        +--------------------+   using shared secret from ML-KEM

What this package changes: only the key wrapping layer — how the Data Protection master key is protected at rest. The application payload encryption (cookies, sessions) remains handled by ASP.NET Core Data Protection's own AES-based pipeline, which is already quantum-safe for symmetric encryption.

For each Data Protection master key:

1. Generate fresh ML-KEM keypair (per-key isolation — each Data Protection key is cryptographically independent)
2. Encapsulate shared secret + KEM ciphertext
3. Encrypt XML key with AES-256-GCM using the shared secret
4. Store decapsulation key encrypted in IKeyStore
5. Zero shared secret immediately with CryptographicOperations.ZeroMemory()

Platform Support

Automatic provider selection: On .NET 10 with native ML-KEM support, uses the OS crypto library (fastest). Otherwise, falls back to BouncyCastle (works everywhere). Same API, same results, different engine.

Demo API

A live demo API is included in the repo:

cd examples/QuantumDataProtection.Demo
dotnet run

Example:

# Encrypt
curl -X POST http://localhost:5000/protect \
  -H "Content-Type: application/json" \
  -d '{"data":"sensitive-data","purpose":"demo"}'

# Decrypt (paste the encrypted value)
curl -X POST http://localhost:5000/unprotect \
  -H "Content-Type: application/json" \
  -d '{"encrypted":"CfDJ8...","purpose":"demo"}'

# Cookie simulation
curl -X POST http://localhost:5000/protect-cookie \
  -H "Content-Type: application/json" \
  -d '{"userId":"tansel","role":"admin"}'

Key Storage

Built-in FileKeyStore

Stores encrypted decapsulation keys on disk:

options.KeyStoreDirectory = "/secure/keys";
options.KeyStorePassword = Environment.GetEnvironmentVariable("KEY_PASSWORD")!;

Custom IKeyStore

Implement for Azure Key Vault, AWS KMS, HashiCorp Vault:

public interface IKeyStore
{
    Task<byte[]?> LoadPrivateKeyAsync(string keyId);
    Task SavePrivateKeyAsync(string keyId, byte[] encryptedKey);
    Task DeleteKeyAsync(string keyId);
    Task<IReadOnlyList<string>> ListKeyIdsAsync();
}

// Usage
options.KeyStore = new AzureKeyVaultKeyStore(vaultUri);

ML-KEM Algorithm Variants

Logging

All cryptographic operations are logged via ILogger:

Security Design

• Per-key isolation: Each Data Protection key gets its own ML-KEM keypair. Compromise of one key does not cascade to others. Note: this is per-key isolation, not forward secrecy in the strict cryptographic sense — forward secrecy requires ephemeral session keys, which is a different property.
• Shared secret zeroing: All shared secrets immediately cleared with CryptographicOperations.ZeroMemory()
• AES-256-GCM: Authenticated encryption with separate nonce and tag — no ambiguity
• Key encryption: Decapsulation keys stored with PBKDF2 (100K iterations) + AES-256-GCM
• No hardcoded secrets: User-provided password for all key encryption
• Path traversal protection: FileKeyStore sanitizes key IDs

API Reference

Core Classes

Extension Methods

Options

NIST / NSA Timeline

Known Limitations

• ML-KEM APIs in .NET 10 are marked [Experimental] (SYSLIB5006) — may change before GA
• BouncyCastle adds ~2MB to the package size
• IXmlEncryptor.Encrypt() is synchronous — custom IKeyStore implementations with network I/O should handle this carefully
• The ML-KEM shared secret is used directly as the AES-256-GCM key without an HKDF key-derivation step. This is acceptable under authenticated encryption in the current threat model, but deviates from strict NIST SP 800-227 (draft) guidance on domain separation. HKDF-SHA256 derivation with domain-separated info strings is planned for a future major version (format change; will be introduced behind a version header).
• No automatic key rotation for the underlying ML-KEM keypairs yet. ASP.NET Core's own Data Protection key rotation works normally; only the ML-KEM key-encryption-keys persist for the lifetime of the wrapped Data Protection keys. Scheduled rotation is on the roadmap.

License

MIT

Author

Tansel DINCKAYA

GitHub: github.com/tdinckaya