QOMPASS AI

POST-QUANTUM OPENSSL CONFIGURATION — SHELL

Qssl

Qssl

Version 1.00Source on GitHub

OVERVIEW

Qssl is the "Qompass AI SSL Solution" (GitHub repo description), titled "Quality SSL: Qompass AI SSL for the Post-Quantum Age" / "Qompass AI on OpenSSL" in its README: a shipped OpenSSL configuration (`qssl/qssl.cnf` plus profile files) that turns on FIPS mode and the OQS provider, pins TLS cipher/group/signature policy including ML-KEM hybrid groups and ML-DSA signature algorithms, and ships scripts to check files for post-quantum algorithm coverage.

HOW IT WORKS

  1. 1OpenSSL loads `qssl/qssl.cnf` (`openssl_conf = openssl_init`, `config_diagnostics = 1`): the init section wires the EVP settings, engines, OID section, providers, random section, and the named SSL configuration.
  2. 2EVP settings turn FIPS mode on (`fips_mode = yes`), and the provider section activates `base`, `default`, `legacy`, `fips`, `oqsprovider`, and `pkcs11` providers — the OQS provider is what supplies the post-quantum algorithms.
  3. 3The OID section registers the ML-DSA OIDs (`mldsa44`/`mldsa65`/`mldsa87`), so certificates and signatures using them parse with names.
  4. 4A connection picks one of the named TLS policies in `[ssl_configuration]` — `system_default`, `level3`, `fips`, `oqs`, or `tpm2` — each pinning `CipherString`/`Ciphersuites`, `Groups`, `MinProtocol`/`MaxProtocol`, and `SignatureAlgorithms`; the `oqs` policy's groups are ML-KEM hybrids only and its signature algorithms are `falcon512:falcon1024:mldsa65:mldsa87`.
  5. 5Certificate work uses the same file's CA/req sections: `CA_default` under `/etc/pki/qompass-ca`, `default_bits = 3072`, `default_md = sha256`, `default_keyalg = EC`, and the `server_cert`/`client_cert`/`v3_ca` extension profiles (also shipped standalone as `qssl/profiles/server_cert.cnf`).
  6. 6Separately, `qssl/scripts/pq_check.sh <file>` scans a target file for occurrences of a fixed list of post-quantum algorithm names (BIKE, FrodoKEM, HQC, ML-KEM, ML-DSA, Falcon, SPHINCS+, MAYO, CROSS, OV and their hybrids) and writes a present/missing/duplicate report to `pq_report.txt`; the repo's test gate runs `scripts/tests/pqctest.sh` against the system OpenSSL and asserts PQ signature algorithms complete key-gen/sign/verify and that a tampered signature does not verify.
How it works, step by step — each step as the project's own documentation states it.

CONCEPTS

ONE CONFIG FILE → PROVIDERS → NAMED POLICIESQSSL.CNF[openssl_init][evp_settings] fips_mode[provider_sect][qai_oid] ML-DSA OIDs[ssl_configuration]CA / req / tsa sectionsconfig_diagnostics = 1PROVIDERS AT STARTUPbase · default · legacyfips · pkcs11oqsproviderML-KEM · ML-DSA · Falconevery provider activate = 1default: security_level=3system_defaultlevel3 — hybrid groupsfips — P-256:P-384:P-521oqs — ML-KEM groups onlytpm2A CONNECTION PICKS ONE POLICYCipherString · Groups · SignatureAlgorithms per policy
One file drives the whole stack: qssl.cnf wires the providers (the OQS provider supplies the post-quantum algorithms), registers the ML-DSA OIDs, and names the TLS policies a connection chooses from — every element as the shipped configuration states it.
CLIENTSERVERencrypted under handshake keysClientHello — key_share: x25519_mlkem768sigalgs offered: mldsa65 · mldsa87 · falcon512 · falcon1024ServerHello — hybrid group chosenEncryptedExtensionsCertificate — ML-DSA-65 chainCertificateVerify · FinishedFinishedapplication dataKEYS FROM ss_ML-KEM ‖ ss_X25519the session holds if either component holds
A TLS 1.3 handshake under the oqs policy: hybrid key exchange (X25519 + ML-KEM-768 in a single key_share), an ML-DSA certificate, and session keys derived from both shared secrets. Message order per RFC 8446; hybrid key exchange per RFC 9954.
\[ss_{\text{hybrid}} = ss_{\text{ML-KEM}} \parallel ss_{\text{X25519}}\]

ss_ML-KEM is the shared secret produced by ML-KEM-768 encapsulation against the peer's encapsulation key; ss_X25519 is the X25519 Diffie–Hellman output; ∥ is byte concatenation. For the hybrid groups Qssl configures (x25519_mlkem768 and its siblings), the concatenated secret is the input keying material to TLS 1.3's HKDF key schedule, so the session is secure if either component holds — the construction RFC 9954 (the IETF hybrid key exchange design) specifies.

The hybrid combiner: both shared secrets, concatenated, feed the TLS 1.3 key schedule.

CONFIGURATION

OptionDefaultWhat it does
config_diagnostics1OpenSSL config diagnostics on
`fips_mode` (`[evp_settings]`)yesFIPS mode for EVP operations
`providers` (`[provider_sect]`)base`, `default`, `legacy`, `fips`, `oqsprovider`, `pkcs11` all `activate = 1Providers loaded at startup
default_sect.properties"provider=default", "security_level=3"Property query for the default provider
fips_sect.algorithmsALL:!X25519:!X448:!Ed25519:!Ed448Algorithm restriction for the FIPS provider
oqs_sect.module/opt/QAI/qompassl/lib64/ossl-modules/oqsprovider.soPath to the OQS provider module as written in the file
`mldsa44` / `mldsa65` / `mldsa87` (`[qai_oid]`)2.16.840.1.101.3.4.3.32` / `.33` / `.34Registered ML-DSA OIDs
`random` (`[random]`)CTR-DRBGRandom generator type (alternatives named in comments: HASH-DRBG, HMAC-DRBG)
random.cipherAES-256-CTRCipher for CTR-DRBG
random.seedJITTEREntropy seed source
system_default.MinProtocol` / `MaxProtocolTLSv1.2` / `TLSv1.3Protocol bounds for the system-default TLS policy
system_default.GroupsP-256:P-384:P-521:X25519:X448Key-exchange groups for the system-default policy
system_default.CiphersuitesTLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256TLS 1.3 ciphersuites for the system-default policy
`level3.Groups` (`tls_seclevel_3`)X25519:P-256:P-384:P-521:X448:x25519_mlkem768:x25519_mlkem1024:p384_mlkem768:mlkem768:mlkem512:mlkem1024Groups for the security-level-3 policy, including ML-KEM hybrids
`oqs.Groups` (`oqs_ssl_sect`)x25519_mlkem768:x25519_mlkem1024:p384_mlkem768:mlkem768:mlkem512:mlkem1024ML-KEM-only groups for the OQS policy
oqs.SignatureAlgorithmsfalcon512:falcon1024:mldsa65:mldsa87Signature algorithms for the OQS policy
`fips.Groups` (`fips_ssl_sect`)P-256:P-384:P-521Groups for the FIPS policy
CA_default.dir/etc/pki/qompass-caCA directory (`certs`, `database`, `serial`, `certificate` derive from it)
CA_default.default_days365Default certificate validity
CA_default.default_crl_days30Default CRL validity
CA_default.default_mdsha256Default CA message digest
req.default_bits3072Default key size for requests
req.default_keyalgECDefault key algorithm for requests
req.promptnoDo not prompt for the distinguished name (the `[dn]` section supplies US / Washington / Spokane / Qompass AI / Security)
tsa_config1.signer_digestsha256Time-stamp authority signer digest (TSA section in the same file)

CONTROLS

ActionControl
Check a file for post-quantum algorithm coverage`qssl/scripts/pq_check.sh <script_file>` (exactly one argument; report written to `pq_report.txt`)
Run the post-quantum test harness`scripts/tests/pqctest.sh` (driven by `tests/test_qssl.py` against the system OpenSSL)
Run the test gate`pytest tests/test_qssl.py` (asserts ML-DSA / SLH-DSA key-gen/sign/verify round-trips, classical ED25519/RSA round-trips, loud failure with no `openssl`, and tampered-signature rejection)
Select a TLS policyChoose a named section from `[ssl_configuration]` (`system_default`, `level3`, `fips`, `oqs`, `tpm2`) in `qssl/qssl.cnf`

NOT COVERED

- The README is boilerplate (badges, contact, funding, FAQ) with no usage instructions; there is no documented install step that copies `qssl.cnf` into an OpenSSL config path or sets `OPENSSL_CONF` — the test deliberately unsets `OPENSSL_CONF`/`OPENSSL_MODULES` and tests the system OpenSSL instead. - Several `.include` lines and engine/module paths in `qssl.cnf` point at `/opt/QAI/qompassl/…`, `/etc/ssl/profiles/…`, and `/usr/lib/…` paths whose provisioning is not documented in the files read. - The remaining profile files (`ca_profiles.cnf`, `ct_log_list.cnf`, `engines_providers.cnf`, `oid.cnf`, `random_sect.cnf`, `tsa_sect.cnf`) were listed but only `server_cert.cnf` was read in full; their individual keys are not tabulated here. - `qssl/scripts/optbuild.sh` (a build script in the tree) was not read for this pack. - Primo clones are known-stale estate-wide; `qssl.cnf` and `pq_check.sh` were read from the primo clone (`~/.GH/Qompass/Qssl/`) and the same paths exist in the GitHub tree listing, but they were not diffed byte-for-byte against GitHub HEAD.

REFERENCES

  1. FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)The standard behind the ML-KEM-512/768/1024 groups in Qssl's level3 and oqs policies.
  2. FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA)The standard behind the mldsa44/65/87 OIDs Qssl registers and the oqs policy's signature algorithms.
  3. RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3The handshake message order, the key schedule, and the ciphersuite/group negotiation the policies pin.
  4. RFC 9954 — Hybrid key exchange in TLS 1.3How hybrid groups concatenate the component shared secrets — the equation above, as specified.
  5. OpenSSL config(5) manual — configuration file formatThe section/provider syntax qssl.cnf is written in, including the provider activation model.
  6. OQS Provider — Open Quantum Safe provider for OpenSSL 3The provider Qssl activates as oqsprovider; its algorithm list is where the ML-KEM/ML-DSA/Falcon names come from.