Post-Quantum Support in IPWorks Toolkits and SecureBlackbox

Introduction

IPWorks, IPWorks SSH, IPWorks Encrypt, IPWorks PGP, and SecureBlackbox support post-quantum (PQ) cryptography based on the NIST standards ML-KEM (FIPS 203, formerly known as CRYSTALS-Kyber) for key exchange/encapsulation and ML-DSA (FIPS 204, formerly known as CRYSTALS-Dilithium) for digital signatures. These algorithms are designed to remain secure against attacks from quantum computers and are now standardized through NIST and IANA.

This article describes the algorithms available in our TLS, SSH, OpenPGP, and digital signature components, how to configure them, and the platform prerequisites for using them.

Post-Quantum Support in IPWorks Toolkits

Prerequisites

Post-quantum algorithms in IPWorks, IPWorks SSH, and IPWorks PGP rely on the operating system's underlying cryptographic primitives. The following platforms are currently supported:

• Windows Server 2025
• Windows 11 24H2
• Windows 11 25H2

IPWorks Encrypt utilizes its own implementation of ML-KEM and ML-DSA for every edition, so it is not limited to the platforms above (see IPWorks Encrypt below).

IPWorks (TLS 1.3)

Supported Algorithms

The following named groups are supported for use in TLS 1.3 key exchange. Hybrid groups combine a classical elliptic-curve key exchange with ML-KEM so that a compromise of either component still leaves the shared secret confidential.

Post-quantum key exchange in TLS requires the internal security API (our cross-platform TLS implementation) and TLS 1.3. The PQ groups are not exposed through the platform's SChannel today, so UseInternalSecurityAPI must be enabled. The SSLEnabledProtocols value 12288 (0x3000) is the bit mask for TLS 1.3. The TLS13SupportedGroups configuration setting accepts a comma-separated, ordered list of the identifiers from the table above. The order expresses preference, so the first mutually-supported group wins.

All six groups are enabled by default and are appended to the end of the default TLS13SupportedGroups list, after the classical (non-PQ) groups. Nothing needs to be configured to allow a TLS 1.3 handshake to negotiate one of them. TLS13SupportedGroups can be set explicitly only to change the enabled set or its preference order.

Component Configuration

The same three options are set on both the server and client side, before initiating the connection.

On the server side:

tcpserver.Config("UseInternalSecurityAPI=true"); tcpserver.Config("SSLEnabledProtocols=12288"); tcpserver.Config("TLS13SupportedGroups=mlkem_512,mlkem_768,mlkem_1024,x25519_mlkem_768,secp256r1_mlkem_768");

On the client side:

tcpclient.Config("UseInternalSecurityAPI=true"); tcpclient.Config("SSLEnabledProtocols=12288"); tcpclient.Config("TLS13SupportedGroups=mlkem_512,mlkem_768,mlkem_1024,x25519_mlkem_768,secp256r1_mlkem_768");

The same configuration pattern applies to any TLS-enabled IPWorks component (e.g., HTTP, SMTP, FTP, etc.).

IPWorks SSH

Supported Algorithms

The following SSH key exchange algorithm is supported. It is a hybrid combining X25519 with ML-KEM-768, and is also implemented by OpenSSH for interoperability.

This algorithm is enabled by default, positioned after the other modern algorithms (safe-prime and elliptic-curve Diffie-Hellman) but before the legacy and GSS-API algorithms, in the default SSHKeyExchangeAlgorithms list:

curve25519-sha256, curve25519-sha256@libssh.org, diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha256, diffie-hellman-group16-sha512, diffie-hellman-group18-sha512, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, mlkem768x25519-sha256, diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, gss-group14-sha256, gss-group16-sha512, gss-nistp256-sha256, gss-curve25519-sha256, gss-group14-sha1, gss-gex-sha1

Component Configuration

Since mlkem768x25519-sha256 is included in the default SSHKeyExchangeAlgorithms list, no configuration change is required to allow it to be negotiated. Set SSHKeyExchangeAlgorithms explicitly to change its position in the list, restrict negotiation to it alone, or remove it. The same setting is available on both server- and client-side SSH components.

sftpserver.Config("SSHKeyExchangeAlgorithms=mlkem768x25519-sha256");

On the client side:

sftp.Config("SSHKeyExchangeAlgorithms=mlkem768x25519-sha256");

As with TLS, the configuration value is a comma-separated, ordered list when multiple algorithms are offered. To prefer the PQ algorithm but allow falling back to classical key exchange, include classical algorithms after it:

sftp.Config("SSHKeyExchangeAlgorithms=mlkem768x25519-sha256,curve25519-sha256,ecdh-sha2-nistp256");

IPWorks Encrypt

IPWorks Encrypt provides new, standalone MLKEM and MLDSA components for applications that need direct access to post-quantum key encapsulation and digital signatures, independent of TLS or SSH.

Unlike IPWorks, IPWorks SSH, and IPWorks PGP, IPWorks Encrypt includes its own implementation of both algorithms for every edition, so it is not restricted to the platforms listed under Prerequisites.

MLKEM Component

The MLKEM component implements ML-KEM key encapsulation, letting two parties agree on a shared secret over an insecure channel. All three parameter sets are supported, selected via the ParamSet config:

See ML-KEM in IPWorks Encrypt for a closer look at the component and how to use it.

MLDSA Component

The MLDSA component implements ML-DSA digital signatures, including the pre-hashed HashML-DSA variant. All three parameter sets are supported, selected via the ParamSet config:

See ML-DSA in IPWorks Encrypt for a closer look at the component and how to use it.

IPWorks PGP

IPWorks PGP supports the composite post-quantum algorithms defined by RFC 9980 for OpenPGP v6 keys (RFC 9580), as well as GnuPG's own, non-composite ML-KEM subkey algorithm for interoperability with GnuPG's LibrePGP v5 key format. These algorithms must be selected explicitly when creating a key or subkey, rather than being negotiated automatically.

Supported Algorithms

The following composite signature algorithms may be specified via the PublicKeyAlgorithm config when creating a primary key:

The following composite algorithms may be specified via the SubKeyAlgorithm config when creating a subkey for encryption or signing:

The four RFC 9980 composite algorithms are valid only for OpenPGP v6 keys: the KeyVersion config must be set to 6 when creating the key, together with CompatibilityProfile left at its default value, RFC9580 (they are not supported with CompatibilityProfile=LibrePGP, since LibrePGP does not define a version 6 key). Since each algorithm name already fixes the elliptic curve it pairs with, the Curve and SubKeyCurve configs do not apply to them.

For interoperability with GnuPG's LibrePGP v5 key format, IPWorks PGP also supports GnuPG's own, non-composite ML-KEM subkey algorithm, valid only when creating a LibrePGP v5 key (KeyVersion=5 together with CompatibilityProfile=LibrePGP). Unlike the RFC 9980 composites, it allows the curve and ML-KEM parameter set to be selected independently, via the SubKeyCurve and SubKeyLength configs.

Component Configuration

Creating an RFC 9580 composite key:

keymgr1.Config("KeyVersion=6"); keymgr1.Config("PublicKeyAlgorithm=ML-DSA-65+Ed25519"); keymgr1.Config("SubKeyAlgorithm=ML-KEM-768+X25519");
keymgr1.CreateKey("pqc@example.com", "test");

Once created, the key can be used like any other v6 key for encrypting, decrypting, signing, and verifying using the OpenPGP component. See Post-Quantum Cryptography (PQC) Support for more details.

Creating a LibrePGP key using GnuPG's ML-KEM subkey algorithm:

keymgr1.Config("CompatibilityProfile=LibrePGP"); keymgr1.Config("KeyVersion=5"); keymgr1.Config("PublicKeyAlgorithm=EdDSA"); keymgr1.Config("SubKeyAlgorithm=ML-KEM"); keymgr1.Config("SubKeyCurve=Curve25519"); keymgr1.Config("SubKeyLength=768");
keymgr1.CreateKey("librepgp-mlkem@example.com", "test");

The resulting keyring can be loaded directly by GnuPG 2.5.x, and vice versa. See GnuPG's ML-KEM Algorithm for more details.

Post-Quantum Support in SecureBlackbox

SecureBlackbox supports post-quantum cryptography across all editions, platforms, and protocol layers, with PQC mechanisms enabled by default. Most usage is transparent: when a TLS or SSH negotiation can settle on a post-quantum or hybrid algorithm, or when a digital signature operation finds an ML-DSA key in the supplied certificate, the post-quantum path is taken automatically.

Supported Platforms

SecureBlackbox's PQC support is available on every platform and edition the product ships on. The supported operating systems are Windows (all versions), macOS, Linux, iOS, and Android, and the supported editions are .NET, Java, C++, Delphi, PHP, and Python.

Supported Algorithms

At the foundation level, SecureBlackbox implements both NIST post-quantum standards: ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) for digital signatures, available in the ML-DSA-44, ML-DSA-65, and ML-DSA-87 parameter sets; and ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) for key encapsulation, available in the ML-KEM-512, ML-KEM-768, and ML-KEM-1024 parameter sets. These foundation algorithms surface differently depending on the protocol or document format.

TLS

The following named groups are supported for use in TLS 1.3 key exchange. Hybrid groups combine a classical elliptic-curve key exchange with ML-KEM so that a compromise of either component still leaves the shared secret confidential.

For TLS authentication, X.509 certificates carrying ML-DSA-44, ML-DSA-65, or ML-DSA-87 keys are supported on both the client and server sides.

SSH

The following SSH key exchange algorithms are supported. All three are hybrids combining a classical key exchange with ML-KEM.

For SSH public-key authentication, ssh-mldsa-44, ssh-mldsa-65, and ssh-mldsa-87 are supported.

Digital Signatures

All ML-DSA parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87, are supported for signing and verification in the advanced electronic signature components: CAdES, XAdES, PAdES, and JAdES.

Configuring SecureBlackbox TLS Components

Post-quantum key exchange and ML-DSA authentication are enabled by default in SecureBlackbox's TLS components. The component selects the post-quantum path automatically when the peer's supported groups include a mutually-acceptable ML-KEM or hybrid group, and uses ML-DSA for authentication whenever the supplied certificate chain carries an ML-DSA key.

To enable ML-DSA authentication on the client or server, assign a certificate chain carrying an ML-DSA key to the corresponding chain property:

// CertificateStorage contains an ML-DSA certificate chain tlsClient.TLSClientChain = storage.Certificates; tlsServer.TLSServerChain = storage.Certificates;

This is no different from how the component picks up RSA or ECDSA authentication; it follows the supplied key material.

The set of enabled ML-KEM and hybrid groups is controlled through the TLSSettings.Groups property. The property accepts a semicolon-delimited list using + and - tokens to enable or disable individual groups and the all keyword as a blanket selector. The example below enables x25519mlkem768 and disables secp256r1mlkem768:

tlsClient.TLSSettings.Groups = "+x25519mlkem768;-secp256r1mlkem768";

Configuring SecureBlackbox SSH Components

Post-quantum key exchange and ML-DSA public-key authentication are enabled by default in SecureBlackbox's SSH components.

The set of enabled SSH key exchange algorithms is controlled through the SSHSettings.KexAlgorithms property, using the same semicolon-delimited list syntax as the TLS Groups property. The example below disables every default algorithm and re-enables a single post-quantum hybrid:

sftpClient.SSHSettings.KexAlgorithms = "-all;mlkem768nistp256-sha256";

The set of enabled public-key authentication algorithms, including the ML-DSA variants, is controlled through the SSHSettings.PublicKeyAlgorithms property, which uses the same syntax. The example below enables the smaller two ML-DSA parameter sets and disables the largest, while also disabling the classical rsa-sha2-256:

sftpClient.SSHSettings.PublicKeyAlgorithms = "+ssh-mldsa-44;+ssh-mldsa-65;-ssh-mldsa-87;-rsa-sha2-256";

Configuring SecureBlackbox Digital Signature Components

For the advanced electronic signature components: CAdES, XAdES, PAdES, and JAdES, ML-DSA signing is engaged automatically when the signing certificate carries an ML-DSA key. No additional configuration setting is required: the signature operation selects the appropriate ML-DSA parameter set based on the key material in the supplied certificate.