Post-Quantum Cryptography in .NET 11: Testing ML-KEM and HPKE APIs

For example, the following command displays the installed .NET SDK and runtime information:

dotnet --info

You can also inspect the installed SDKs:

dotnet --list-sdks

These commands help identify your development environment. They do not prove that a particular cryptographic algorithm is supported, so you must also inspect the relevant API documentation and test the implementation.

Creating a Basic Cryptography Test Project

Start by creating a small console application.

dotnet new console -n PostQuantumTests
cd PostQuantumTests

Choose a target framework supported by the cryptographic APIs you intend to test.

For example, a project file may contain the following configuration when the selected SDK supports that target:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net11.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

The target framework setting must match an installed and supported SDK. If the required SDK is unavailable, the project will not build for that target.

For production projects, use a supported runtime and verify the availability of the exact cryptographic APIs required by your application.

Testing ML-KEM Functionality

The most important ML-KEM test checks whether encapsulation and decapsulation produce the same shared secret.

A typical test follows this sequence:

1. Generate an ML-KEM key pair.

2. Use the public key to encapsulate a shared secret.

3. Use the private key to decapsulate the encapsulation value.

4. Compare the two shared secrets.

5. Verify that malformed input is rejected.

The following C# example illustrates the test logic. It is intentionally written as pseudocode because the exact ML-KEM class names, method signatures, and key-handling APIs must be taken from the implementation available in your target environment.

// Conceptual test flow; adapt to the supported ML-KEM API.

var keyPair = GenerateMlKemKeyPair();

var encapsulationResult = Encapsulate(
    keyPair.PublicKey);

byte[] senderSecret = encapsulationResult.SharedSecret;

byte[] receiverSecret = Decapsulate(
    keyPair.PrivateKey,
    encapsulationResult.Encapsulation);

bool secretsMatch = CryptographicOperations.FixedTimeEquals(
    senderSecret,
    receiverSecret);

if (!secretsMatch)
{
    throw new InvalidOperationException(
        "ML-KEM shared-secret verification failed.");
}

This example demonstrates the intended test, not a directly compilable implementation.

The comparison uses CryptographicOperations.FixedTimeEquals, which is designed to compare byte sequences without making the comparison time depend on the first differing byte. This is preferable to ordinary sequence comparison for sensitive cryptographic values.

A complete test should also verify that invalid encapsulation data is rejected according to the implementation's documented behavior.

Do not log private keys, shared secrets, or other sensitive cryptographic material during testing.

Testing HPKE Message Encryption

An HPKE test should verify that a sender can encrypt a message and the intended recipient can decrypt it.

The test should also confirm that modified ciphertext is rejected.

A conceptual test flow looks like this:

// Conceptual HPKE test flow; adapt to the chosen implementation.

var recipientKeys = GenerateRecipientKeyPair();

byte[] message = System.Text.Encoding.UTF8.GetBytes(
    "Sensitive application data");

byte[] encryptedMessage = HpkeEncrypt(
    recipientKeys.PublicKey,
    message);

byte[] decryptedMessage = HpkeDecrypt(
    recipientKeys.PrivateKey,
    encryptedMessage);

if (!message.AsSpan().SequenceEqual(decryptedMessage))
{
    throw new InvalidOperationException(
        "HPKE message verification failed.");
}

The helper methods in this example represent operations provided by a suitable HPKE implementation. They are not built-in .NET method names.

For a real implementation, configure the sender and receiver with compatible cipher suites and the same required application context.

The test should cover successful decryption, incorrect keys, modified ciphertext, and incompatible configuration.

Common Mistakes When Testing PQC

Assuming .NET 11 Supports Every PQC API

The target framework alone does not guarantee that a specific algorithm or API is available.

Check the actual runtime, provider, and implementation before designing the application around an API.

Confusing Key Establishment With Encryption

ML-KEM establishes a shared secret. It does not replace the authenticated encryption component required to protect application messages.

Use the appropriate cryptographic framework for the task.

Ignoring Cipher Suite Compatibility

HPKE requires compatible cryptographic components and configuration. A sender and receiver using incompatible suites cannot complete the expected exchange.

Test the configuration explicitly.

Logging Sensitive Values

Private keys, shared secrets, and sensitive application payloads should not appear in production logs.

Use non-sensitive test data and avoid recording cryptographic material unnecessarily.

Testing Only Successful Operations

A successful encryption and decryption test is not sufficient.

Also test malformed inputs, incorrect keys, modified ciphertext, invalid configurations, and failure handling.

Best Practices for Production Applications

Use these practices when evaluating or adopting post-quantum cryptography:

• Use standardized algorithms and maintained implementations.

• Verify API stability and platform support before deployment.

• Keep private keys and sensitive secrets protected.

• Never implement a custom cryptographic algorithm without specialist review.

• Use established key-derivation and authenticated-encryption mechanisms.

• Validate malformed input and handle errors safely.

• Test compatibility between the sender and recipient implementations.

• Keep cryptographic configuration explicit and documented.

• Review the security properties of the complete protocol, not only the KEM.

• Maintain a migration plan for replacing cryptographic algorithms when requirements change.

Post-quantum security depends on correct implementation, secure key management, and the complete protocol design. Choosing a post-quantum algorithm alone does not guarantee that an application is secure.

Advantages and Disadvantages

Advantages

Post-quantum cryptography provides a path toward protecting applications against future quantum computing threats. ML-KEM can establish shared secrets using a standardized post-quantum mechanism, while HPKE provides a structured way to encrypt messages.

Testing these components early can help teams identify compatibility issues and understand the changes required for future cryptographic migrations.

Disadvantages

Post-quantum integration can introduce compatibility, deployment, and key-management challenges. Support may vary across runtimes, providers, and third-party implementations.

Developers must also understand the difference between standardized algorithms and experimental APIs. Preview or experimental interfaces may change before becoming stable.

Summary

ML-KEM and HPKE serve different but related purposes in modern cryptography. ML-KEM establishes a shared secret, while HPKE combines key establishment, key derivation, and authenticated encryption to protect messages.

For .NET developers, the first step is to verify that the target runtime and chosen implementation support the required APIs. Testing should cover successful key establishment, message encryption and decryption, malformed input, incompatible configurations, and failure handling.

Avoid treating conceptual examples as production-ready code. Use the actual APIs exposed by a maintained implementation, protect sensitive key material, and validate the complete cryptographic design before deploying it.

A careful testing process helps developers evaluate post-quantum capabilities without making unsupported assumptions about API availability or security.