Color scheme: Light
You are here: start » en » Documentation » Post-Quantum Cryptography » WKL.System.Security.Cryptography overview » Reference » Target frameworks

Target frameworks

The library offers the same algorithms and data formats on every target. This page lists which assembly is built for which target, and where the path to a feature differs because .NET Framework doesn't have a type yet.

Assemblies and targets

AssemblyTargetsContents
WKL.System.Security.Cryptography.Core.NET Framework 4.6.2, .NET Core 3.1, .NET 8, .NET 9PostQuantumConfig, CryptoMode, the policy, and the provider interface
WKL.System.Security.Cryptography.Extensions.NET Framework 4.6.2 and 4.7.2, .NET Core 3.1, .NET 8the extension methods and the OpenSSL provider
WKL.System.Security.Cryptography.WASM.NET 9the Blazor WebAssembly provider, with OpenSSL as a WebAssembly module

An app that targets .NET Framework 4.8 uses the 4.7.2 build, and an app that targets .NET 9 or later uses the .NET 8 build.

Differences on .NET Framework

Area.NET FrameworkReason
Issuing certificatesX509CertificateBuilder on every version; the CertificateRequest extensions on 4.7.2 and laterCertificateRequest exists only starting with .NET Framework 4.7.2
CopyWithPrivateKey with CryptoMode4.7.2 and laterthe .NET method exists only starting with 4.7.2
Self-signed certificate on 4.6.2The library associates the RSA or ECDSA key through an in-memory PFX file. A key that can't be exported in plaintext stays unassociated.4.6.2 can't associate a key with a certificate directly
Chain validation with your own trust anchorsThe anchors go into ExtraStore. The chain is valid only if it ends in one of the anchors, and ChainStatus then also reports UntrustedRoot.X509ChainPolicy.CustomTrustStore doesn't exist
Issuing CRLsX509CrlBuilder; the CertificateRevocationListBuilder overloads only on .NET 8CertificateRevocationListBuilder exists only starting with .NET 7
PFX with PbeParametersThe library provides PbeParameters and PbeEncryptionAlgorithm in the System.Security.Cryptography namespace.NET Framework doesn't have these types
ECDSA and ECDH on 4.6.2with keys of type ECDsaCng and ECDiffieHellmanCngECParameters exists only starting with .NET Framework 4.7
Composite ML-KEMpairs with RSA work as on .NET 8; pairs with ECDH throw PlatformNotSupportedExceptionthe combiner needs the raw ECDH secret, which .NET exposes only starting with .NET 8
Loading OpenSSLThe library loads libcrypto by its full path from PostQuantumConfig.OpenSslPath.NET Framework can't resolve library names at run time

Everything else behaves on .NET Framework the same way it does on .NET 8: hybrid and pure ML-DSA certificates, chains, signatures, CMS and XML signatures, KemEnvelopedCms, PFX files, key storage, and the policy.

Differences by operating system

AreaWindowsLinuxmacOS
.NET Frameworkyes––
Key files next to the certificate storeDPAPIwith Secret Servicenot available
Chain with a pure ML-DSA issueryesif .NET also loads OpenSSL 3.5 or laternot stated
PFX import of a certificate whose main key is ML-DSA or ML-KEMyesnot with .NET 8not stated

Not stated means that there are no guarantees for this combination. For details on Linux, see Configure OpenSSL and Transfer certificates with PQ keys as PFX files.

Limitations

  • .NET Framework on Windows only. Mono and other runtimes for .NET Framework aren't supported.
  • .NET Core 3.1 is out of support at Microsoft. The library still builds for it so that existing apps can adopt PQ algorithms.
en/wiki/pqcrypt/lib/reference/target-frameworks.txt · Last modified: by Wolfgang van der Stille