OpenSSL Provider

The Dyber OpenSSL Provider is a drop-in module for OpenSSL 3.x that transparently accelerates post-quantum cryptographic operations using the QUAC 100 hardware. Once installed and configured, any application linked against OpenSSL — NGINX, Apache, HAProxy, curl, PostgreSQL, and thousands more — gains hardware-accelerated PQC without a single line of code change.

Overview #

OpenSSL 3.0 introduced the Provider API, replacing the legacy ENGINE interface with a modular architecture that allows cryptographic implementations to be loaded at runtime. The Dyber provider (quac100-ossl) implements this interface to register ML-KEM, ML-DSA, and SLH-DSA algorithms alongside OpenSSL's built-in classical algorithms.

The provider operates transparently — applications do not need to know that post-quantum algorithms are being used. OpenSSL's EVP API handles all algorithm negotiation, key management, and TLS cipher suite selection internally.

Provider Architecture #

The provider implements OpenSSL's provider dispatch table interface, registering operation handlers for key management, key exchange (KEM), digital signatures, and random number generation. Each handler delegates to the QUAC 100 native API through the SDK's shared library.

/* Provider initialization — called by OpenSSL at load time */
static const OSSL_ALGORITHM quac100_keymgmt[] = {
    { "ML-KEM-512:mlkem512",  "provider=quac100", mlkem512_keymgmt_fns },
    { "ML-KEM-768:mlkem768",  "provider=quac100", mlkem768_keymgmt_fns },
    { "ML-KEM-1024:mlkem1024","provider=quac100", mlkem1024_keymgmt_fns },
    { "ML-DSA-44:mldsa44",    "provider=quac100", mldsa44_keymgmt_fns },
    { "ML-DSA-65:mldsa65",    "provider=quac100", mldsa65_keymgmt_fns },
    { "ML-DSA-87:mldsa87",    "provider=quac100", mldsa87_keymgmt_fns },
    { NULL, NULL, NULL }
};

When an application requests an algorithm via EVP_PKEY_keygen() or a TLS cipher suite negotiation selects a PQC algorithm, OpenSSL routes the operation through the provider's dispatch functions. The provider translates EVP parameters to native QUAC 100 API calls, manages DMA buffers for hardware communication, and returns results through OpenSSL's standard callback mechanism.

Installation & Configuration #

The provider module is included in the QuantaCore SDK package. Installation copies the shared library to OpenSSL's module directory and optionally updates the system openssl.cnf.

# Install the provider module
$ sudo cp /opt/dyber/lib/ossl-modules/quac100.so /usr/lib/ossl-modules/

# Verify OpenSSL can find it
$ openssl list -providers
  quac100
    name: Dyber QUAC 100 PQC Provider
    version: 1.0.0
    status: active
    build info: QuantaCore SDK 1.0.0

# Verify algorithm availability
$ openssl list -kem-algorithms | grep ML-KEM
  ML-KEM-512 @ quac100
  ML-KEM-768 @ quac100
  ML-KEM-1024 @ quac100

openssl.cnf Directives #

The provider is activated through OpenSSL's configuration file. The following configuration loads the QUAC 100 provider alongside the default provider, enabling both classical and post-quantum algorithms.

# /etc/ssl/openssl.cnf (or system-equivalent)

openssl_conf = openssl_init

[openssl_init]
providers = provider_sect
ssl_conf = ssl_sect

[provider_sect]
default = default_sect
quac100 = quac100_sect

[default_sect]
activate = 1

[quac100_sect]
module = /usr/lib/ossl-modules/quac100.so
activate = 1
# Optional: force hardware-only mode (fail if no QUAC 100 present)
# hardware_required = 1
# Optional: enable QRNG as default random source
# qrng_default = 1
# Optional: FIPS mode enforcement
# fips_mode = 1

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Groups = X25519MLKEM768:X25519:P-256
SignatureAlgorithms = mldsa65:ed25519:ecdsa-with-SHA256

The [ssl_sect] configuration controls which algorithms are offered during TLS handshakes. X25519MLKEM768 is the hybrid key exchange that combines X25519 (classical) with ML-KEM-768 (post-quantum), providing security against both classical and quantum attacks.

Algorithm Registration #

The provider registers the following algorithm names with OpenSSL's algorithm lookup system. Applications using EVP APIs can reference these by name or OID.

Hybrid combinations (e.g., X25519MLKEM768) are registered as composite key exchange algorithms that perform both classical and post-quantum operations and combine the resulting shared secrets using HKDF.

TLS 1.3 Integration #

The provider integrates with OpenSSL's TLS stack to enable post-quantum key exchange and authentication during TLS 1.3 handshakes. Hybrid key exchange is the recommended deployment mode — it provides quantum resistance while maintaining backward compatibility with classical-only peers.

/* Programmatic TLS configuration */
SSL_CTX* ctx = SSL_CTX_new(TLS_server_method());

/* Set hybrid PQC key exchange groups */
SSL_CTX_set1_groups_list(ctx, "X25519MLKEM768:X25519:P-256");

/* Set PQC signature algorithms for certificate verification */
SSL_CTX_set1_sigalgs_list(ctx, "mldsa65:ed25519:ecdsa+SHA256");

/* Load PQC certificate and key */
SSL_CTX_use_certificate_file(ctx, "server-mldsa65.pem", SSL_FILETYPE_PEM);
SSL_CTX_use_PrivateKey_file(ctx, "server-mldsa65-key.pem", SSL_FILETYPE_PEM);

During the TLS handshake, the client and server negotiate a mutually supported key exchange group. If both support X25519MLKEM768, the handshake performs a hybrid key exchange. The server advertises available groups in the ServerHello, and the client selects its preferred option. If no PQC groups are mutually supported, the handshake falls back to classical-only key exchange.

Hybrid Key Exchange #

Hybrid key exchange combines a classical key agreement (X25519 or ECDH) with a post-quantum KEM (ML-KEM) in a single TLS handshake. Both shared secrets are derived and combined using HKDF, ensuring security against both classical and quantum adversaries.

The hybrid construction follows the IETF draft specification (draft-ietf-tls-hybrid-design) and is compatible with Cloudflare, Google, and AWS implementations of hybrid PQC TLS. The QUAC 100 hardware accelerates the ML-KEM component while the classical component uses existing optimized implementations.

NGINX Configuration #

NGINX compiled against OpenSSL 3.x automatically benefits from the QUAC 100 provider when it's activated in the system openssl.cnf. The only NGINX-specific configuration needed is cipher suite selection.

# /etc/nginx/conf.d/pqc-tls.conf
server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/certs/server-hybrid.pem;
    ssl_certificate_key /etc/nginx/certs/server-hybrid-key.pem;

    ssl_protocols TLSv1.3;

    # Prefer hybrid PQC key exchange, fallback to classical
    ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

    # Enable both PQC and classical signature algorithms
    ssl_conf_command SignatureAlgorithms mldsa65:ed25519:ecdsa+SHA256:rsa_pss_rsae_sha256;

    # Session resumption (reduces PQC handshake overhead)
    ssl_session_cache shared:PQC:50m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;
}

Apache / HAProxy #

Apache httpd:

# /etc/httpd/conf.d/ssl-pqc.conf
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:prime256v1
SSLOpenSSLConfCmd SignatureAlgorithms mldsa65:ecdsa+SHA256

HAProxy:

# /etc/haproxy/haproxy.cfg
global
    ssl-default-bind-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-bind-options ssl-min-ver TLSv1.3
    ssl-default-bind-curves X25519MLKEM768:X25519

frontend https_in
    bind *:443 ssl crt /etc/haproxy/certs/server-hybrid.pem

Both Apache and HAProxy link against the system OpenSSL library. Once the QUAC 100 provider is activated in openssl.cnf, these applications automatically use hardware-accelerated PQC without recompilation.

QRNG Random Provider #

The provider optionally replaces OpenSSL's default random number generator with the QUAC 100's quantum random number generator (QRNG). When enabled, all calls to RAND_bytes() are fulfilled by hardware-generated quantum entropy.

# Enable in openssl.cnf
[quac100_sect]
module = /usr/lib/ossl-modules/quac100.so
activate = 1
qrng_default = 1  # Route RAND_bytes() to QRNG

The QRNG produces NIST SP 800-90B compliant entropy at rates exceeding 100 Mbps after conditioning. For applications requiring cryptographic-grade randomness (key generation, nonce creation, IV generation), QRNG provides demonstrably higher entropy quality than software-based CSPRNGs seeded from operating system entropy pools.

Performance Tuning #

The provider supports several tuning parameters for high-throughput deployments.

# High-throughput configuration
[quac100_sect]
module = /usr/lib/ossl-modules/quac100.so
activate = 1
batch_size = 32
queue_depth = 64
precompute_keys = 256

Troubleshooting #

Provider not loading: Verify the module path matches your OpenSSL installation: openssl version -d shows the configuration directory. Ensure quac100.so is in the ossl-modules/ subdirectory and has correct permissions (0644).

Hardware not detected: Check that the kernel driver is loaded (lsmod | grep quac100) and the device is visible (lspci | grep Dyber). The provider falls back to software mode if no hardware is available — set hardware_required = 1 in the configuration to force hardware-only mode for debugging.

TLS handshake failures: Enable OpenSSL debug logging with OPENSSL_DEBUG=1 and check for algorithm negotiation failures. Ensure both client and server support at least one common key exchange group. Use openssl s_client -groups X25519MLKEM768 to test specific groups.

Performance lower than expected: Verify DMA is working correctly with quac100-diag --dma-test. Check NUMA affinity — best performance is achieved when the application runs on CPU cores local to the PCIe slot hosting the QUAC 100. Use numactl --cpubind=0 nginx for NUMA-aware binding.