Reference source · 0.1.0-dev.11

cryptography-evaluation.md

docs/cryptography-evaluation.md · Download original file

# Cryptographic runtime evaluation

Recorded October 1, 2026 for the experimental message prototype. This is implementation-selection evidence, not a cryptographic assessment or a claim of validated modules.

## Selection and independent implementation

The TypeScript prototype uses Node 24's native cryptographic APIs for ML-KEM-768, ML-DSA-65, HKDF-SHA-512 and AES-256-GCM. The tested runtime is Node 24.19.0 with OpenSSL 3.5.7. Local Node 22.23.2 lacks the required KEM encapsulation API despite its OpenSSL version, so it cannot execute this prototype unchanged. [Node crypto API](https://nodejs.org/download/release/v24.19.0/docs/api/crypto.html)

The Python implementation uses pinned `pqcrypto 0.3.4` for PQClean ML-KEM/ML-DSA primitives and `cryptography 46.0.5` for HKDF and GCM, tested on Python 3.12.14/macOS arm64. Its serialization, framing, credential validation and envelope logic are implemented separately. The harness generates Python keys, has the TypeScript development authority certify them, and proves protected exchanges both ways without logging secrets. [pqcrypto package](https://pypi.org/project/pqcrypto/0.3.4/)

.NET is available in the workspace but has not been exercised against this profile. Platform support, provider selection and packaging remain work for its SDK. Browser JavaScript and mobile runtimes are also untested; the Node implementation is server-side. Organization-wide private keys must never be distributed in browser assets or mobile binaries.

Development dependencies are pinned in `package-lock.json` and `python/requirements.txt`. Native runtime versions are documented but not bundled into a redistributable package. Upstream license/notice obligations, reproducible distribution, security update policy and supported-platform matrix need review before release; OPRP original materials now use Apache 2.0; upstream components retain their original licenses.

## Standard algorithms and new composition

[FIPS 203](https://csrc.nist.gov/pubs/fips/203/final) specifies the ML-KEM primitive and [FIPS 204](https://csrc.nist.gov/pubs/fips/204/final) specifies ML-DSA. [NIST SP 800-227](https://csrc.nist.gov/pubs/sp/800/227/final) supplies KEM-use guidance. The prototype's parameter sets and raw-key lengths agree across the tested native implementations.

The application envelope, domain separation, key derivation context, identity credential, discovery document and JWT signature identifier are new OPRP experiments. Standard primitives do not validate their composition. No assertion of registered JOSE support, standardized post-quantum HPKE, TLS certificate quantum resistance or FIPS module validation follows from these tests. An independently assessed construction and encoding contract must precede a production profile.

The present scheme uses fresh KEM encapsulation per message but static recipient keys. It has no forward secrecy. Symmetric-key buffers are cleared where practical; JavaScript/Python runtime copies and long-lived private keys cannot be guaranteed erased by this implementation.

## Verified and outstanding evidence

Verified: native key generation/import, cross-OpenSSL/PQClean signature/KEM compatibility, matching HKDF/GCM/framing, response binding, Python token/snapshot/change/refresh-recovery exchanges, supplied authority constraints and signed-status verification, and independently rejected changed ciphertext. Host-internal encrypted cursors and bounded refresh receipts have failure/restart tests; they are not independently audited wire constructions. See [verification status](implementation-status.md).

Outstanding: deterministic published vectors where supported, full numeric/Unicode encoding corpus, malformed-key and decapsulation fault tests, fuzzing, side-channel assessment, complete platform interoperability, performance/overhead benchmarks, streaming attachments, ephemeral-session behavior, Host/issuer compromise recovery, broader rotation/revocation exercises and external construction review. Requester planned rotation, bounded status and independent archive recovery now have first synthetic tests. The current compact JSON restriction is explicitly narrower than all valid FHIR JSON.