ouroboros/src/lib/crypt.c, branch master

build: Update copyright to 2026

2026-02-18T06:54:56+00:00

Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Add SLH-DSA tests and per-algorithm PQC gating

2026-02-18T06:53:35+00:00

This replaces the single HAVE_OPENSSL_PQC/DISABLE_PQC with per-algorithm CMake variables (ML-KEM, ML-DSA, SLH-DSA), gated by the OpenSSL versions: ML-KEM and ML-DSA require >= 3.4, SLH-DSA >= 3.5. SLH-DSA was already working, but now added explicit authentication tests for it with a full certificate chain (root CA, intermediate CA, server) to show full support. Rename PQC test files and cert headers to use algorithm-specific names (ml_kem, ml_dsa, slh_dsa) and move cert headers to include/test/certs/. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

irmd: Add strength-based crypto negotiation

2026-02-18T06:52:56+00:00

Each side's configured cipher, KDF, and KEX algorithm now represents a minimum security floor ("at least this strong"). Cipher and KDF use strongest-wins: the server compares ranks and selects the stronger of client vs server config. The negotiated values are sent in the response header. The client verifies the server's response meets its own minimum, which prevents downgrade attacks on the wire. KEX uses a minimum-floor check: the server extracts the client's algorithm from its public key and rejects if it ranks below the server's configured algorithm. A server configured with ML-KEM will reject all classical algorithms. Special case: for client-encap KEM, the client has already derived its key using its KDF, so the server must use the same KDF and can only reject if it is too weak. The supported_nids arrays are ordered weakest to strongest and serve as the single source of truth for ranking. Cipher ranking (weakest to strongest): aes-128-ctr, aes-192-ctr, aes-256-ctr, aes-128-gcm, aes-192-gcm, aes-256-gcm, chacha20-poly1305 KDF ranking (weakest to strongest): blake2s256, sha256, sha3-256, sha384, sha3-384, blake2b512, sha512, sha3-512 KEX ranking (weakest to strongest): ffdhe2048, prime256v1, X25519, ffdhe3072, secp384r1, ffdhe4096, X448, secp521r1, ML-KEM-512, ML-KEM-768, ML-KEM-1024, X25519MLKEM768, X448MLKEM1024 Negotiation outcomes: strong srv cipher + weak cli cipher -> use strongest weak srv cipher + strong cli cipher -> use strongest srv encryption + cli none -> server rejects srv none + cli encryption -> use client's strong srv KEX + weak cli KEX -> server rejects weak srv KEX + strong cli KEX -> succeeds wire tamper to weaker cipher -> client rejects Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

build: Refactor CMake back to in-tree CMakeLists

2026-02-13T08:22:29+00:00

This moves the build definitions back to src/ subdirectories (CMakeLists.txt per component). Configuration and dependencies are kept out of tree. Configuration options are bundled into cmake/config/ modules. Dependencies are grouped by component (system/, crypt/, eth/, coverage/, etc.). It now consistently uses target-based commands (target_include_directories, target_link_libraries) instead of global include_directories(). Proper PRIVATE/PUBLIC visibility for executable link libraries. CONFIG_OUROBOROS_DEBUG now properly set based on being a valid debug config (not just checking the string name). It also adds OuroborosTargets export for find_package() support and CMake package config files (OuroborosConfig.cmake) for easier integration with CMake projects. The build logic now follows more idiomatic CMake practices with configuration separated from target definitions. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Fix OpenSSL includes and explicit_bzero on OSX

2026-02-13T08:22:06+00:00

The include headers and NIDs are different on macOS X. It also doesn't have explicit_bzero. The crypt.h includes are now guarded to work on OS X (trying to avoid the includes by defining the OpenSSL mac header guard led to a whole list of other issues). The explicit zero'ing of buffers temporarily holding secrets has now been abstracted in a crypt_secure_clear() function defaulting to OpenSSL_cleanse, explicit_bzero (if present) or a best-effort option using a volatile pointer. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Replace rdrbuff with a proper slab allocator

2026-01-26T06:50:33+00:00

This is a first step towards the Secure Shared Memory (SSM) infrastructure for Ouroboros, which will allow proper resource separation for non-privileged processes. This replaces the rdrbuff (random-deletion ring buffer) PoC allocator with a sharded slab allocator for the packet buffer pool to avoid the head-of-line blocking behaviour of the rdrb and reduce lock contention in multi-process scenarios. Each size class contains multiple independent shards, allowing parallel allocations without blocking. - Configurable shard count per size class (default: 4, set via SSM_POOL_SHARDS in CMake). The configured number of blocks are spread over the number of shards. As an example: SSM_POOL_512_BLOCKS = 768 blocks total These 768 blocks are shared among 4 shards (not 768 × 4 = 3072 blocks) - Lazy block distribution: all blocks initially reside in shard 0 and naturally migrate to process-local shards upon first allocation and subsequent free operations - Fallback with work stealing: processes attempt allocation from their local shard (pid % SSM_POOL_SHARDS) first, then steal from other shards if local is exhausted, eliminating fragmentation while maintaining low contention - Round-robin condvar signaling: blocking allocations cycle through all shard condition variables to ensure fairness - Blocks freed to allocator's shard: uses allocator_pid to determine target shard, enabling natural load balancing as process allocation patterns stabilize over time Maintains existing robust mutex semantics including EOWNERDEAD handling for dead process recovery. Internal structures exposed in ssm.h for testing purposes. Adds some tests (pool_test, pool_sharding_test.c. etc) verifying lazy distribution, migration, fallback stealing, and multiprocess behavior. Updates the ring buffer (rbuff) to use relaxed/acquire/release ordering on atomic indices. The ring buffer requires the (robust) mutex to ensure cross-structure synchronization between pool buffer writes and ring buffer index publication. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Fix allocation of IV and tags

2026-01-23T07:29:30+00:00

The packet buffer was allocating a fixed header for the IV, but did not account for the tag at all (remnant of the old hardcoded CBC mode-only proof-of-concept). Never ran into issues because we always reserved ample space. But it now properly reserves the correct space for IV and tag. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Add post-quantum cryptography support

2026-01-19T07:29:29+00:00

This adds initial support for runtime-configurable encryption and post-quantum Key Encapsulation Mechanisms (KEMs) and authentication (ML-DSA). Supported key exchange algorithms: ECDH: prime256v1, secp384r1, secp521r1, X25519, X448 Finite Field DH: ffdhe2048, ffdhe3072, ffdhe4096 ML-KEM (FIPS 203): ML-KEM-512, ML-KEM-768, ML-KEM-1024 Hybrid KEMs: X25519MLKEM768, X448MLKEM1024 Supported ciphers: AEAD: aes-128-gcm, aes-192-gcm, aes-256-gcm, chacha20-poly1305 CTR: aes-128-ctr, aes-192-ctr, aes-256-ctr Supported HKDFs: sha256, sha384, sha512, sha3-256, sha3-384, sha3-512, blake2b512, blake2s256 Supported Digests for DSA: sha256, sha384, sha512, sha3-256, sha3-384, sha3-512, blake2b512, blake2s256 PQC support requires OpenSSL 3.4.0+ and is detected automatically via CMake. A DISABLE_PQC option allows building without PQC even when available. KEMs differ from traditional DH in that they require asymmetric roles: one party encapsulates to the other's public key. This creates a coordination problem during simultaneous reconnection attempts. The kem_mode configuration parameter resolves this by pre-assigning roles: kem_mode=server # Server encapsulates (1-RTT, full forward secrecy) kem_mode=client # Client encapsulates (0-RTT, cached server key) The enc.conf file format supports: kex= # Key exchange algorithm cipher= # Symmetric cipher kdf= # Key derivation function digest= # Digest for DSA kem_mode= # Server (default) or client none # Disable encryption The OAP protocol is extended to negotiate algorithms and exchange KEX data. All KEX messages are signed using existing authentication infrastructure for integrity and replay protection. Tests are split into base and _pqc variants to handle conditional PQC compilation (kex_test.c/kex_test_pqc.c, oap_test.c/oap_test_pqc.c). Bumped minimum required OpenSSL version for encryption to 3.0 (required for HKDF API). 1.1.1 is long time EOL. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Move encryption control from QoS to name

2025-09-10T06:21:58+00:00

This removes the flow encryption option (cypher_s) from the qosspec. The configuration file is configured in the security options (default /etc/ouroboros/security/). For this poc, encryption can be disabled client or server side by putting an enc.cfg file. If that file is present in the client folder, the client will require encryption. If that file is present on the server side, the server will require encryption and reject non-encrypted flows. Encryption is now configured outside of any application control. Example: /etc/ouroboros/security/client/oping/enc.cfg exists: irmd(II): Encryption enabled for oping. irmd(DB): File /etc/ouroboros/security/client/oping/crt.pem does not exist. irmd(II): No security info for oping. irmd(DB): Generated ephemeral keys for 87474. irmd/oap(PP): OAP_HDR [caf203681d997941 @ 2025-09-02 17:08:05 (UTC) ] --> irmd/oap(PP): Certificate: irmd/oap(PP): Ephemeral Public Key: [91 bytes] irmd/oap(PP): Data: irmd/oap(PP): Signature: Example: /etc/ouroboros/security/client/oping/enc.cfg does not exist: irmd(II): Allocating flow for 87506 to oping. irmd(DB): File /etc/ouroboros/security/client/oping/enc.cfg does not exist. irmd(DB): File /etc/ouroboros/security/client/oping/crt.pem does not exist. irmd(II): No security info for oping. irmd/oap(PP): OAP_HDR [e84bb9d7c3d9c002 @ 2025-09-02 17:08:30 (UTC) ] --> irmd/oap(PP): Certificate: irmd/oap(PP): Ephemeral Public Key: irmd/oap(PP): Data: irmd/oap(PP): Signature: Example: /etc/ouroboros/security/server/oping/enc.cfg exists: irmd(II): Flow request arrived for oping. irmd(DB): IPCP 88112 accepting flow 7 for oping. irmd(II): Encryption enabled for oping. irmd(DB): File /etc/ouroboros/security/server/oping/crt.pem does not exist. irmd(II): No security info for oping. irmd/oap(PP): OAP_HDR [3c717b3f31dff8df @ 2025-09-02 17:13:06 (UTC) ] <-- irmd/oap(PP): Certificate: irmd/oap(PP): Ephemeral Public Key: irmd/oap(PP): Data: irmd/oap(PP): Signature: irmd(WW): Encryption required but no key provided. The server side will pass the ECRYPT to the client: $ oping -l Ouroboros ping server started. Failed to accept flow: -1008 $ oping -n oping -c 1 Failed to allocate flow: -1008. Encryption on flows can now be changed at runtime without needing to touch/reconfigure/restart the process. Note: The ECRYPT result is passed on via the flow allocator responses through the IPCP (discovered/fixed some endianness issues), but the reason for rejecting the flow can be considered N+1 information... We may move that information up into the OAP header at some point. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

irmd: Add flow authentication

2025-08-18T18:57:23+00:00

This adds initial implementation of peer authentication as part of flow allocation. If credentials are not provided, this will be accepted and logged as info that the flow is not authenticated. Certificates and keys are passed as .pem files. The key file should not be encrypted, else the IRMd will open a prompt for the password. The default location for these .pem files is in /etc/ouroboros/security. It is strongly recommended to make this directory only accessible to root. ├── security │ ├── cacert │ │ └── ca.root.o7s.crt.pem │ ├── client │ │ ├── │ │ | ├── crt.pem │ │ | └── key.pem │ │ └── | | ├──... | | │ ├── server │ │ ├── │ │ | ├── crt.pem │ │ | └── key.pem │ │ └── | | ├── ... | | │ └── untrusted │ └── sign.root.o7s.crt.pem Trusted root CA certificates go in the /cacert directory, untrusted certificates for signature verification go in the /untrusted directory. The IRMd will load these certificates at boot. The IRMd will look for certificates in the /client and /server directories. For each name a subdirectory can be added and the credentials in that directory are used to sign the OAP header for flows at flow_alloc() on the client side and flow_accept() on the server side. These defaults can be changed at build time using the following variables (in alphabetical order): OUROBOROS_CA_CRT_DIR /etc/ouroboros/security/cacert OUROBOROS_CLI_CRT_DIR /etc/ouroboros/security/client OUROBOROS_SECURITY_DIR /etc/ouroboros/security OUROBOROS_SRV_CRT_DIR /etc/ouroboros/security/server OUROBOROS_UNTRUSTED_DIR /etc/ouroboros/security/untrusted The directories for the names can also be configured at IRMd boot using the configuraton file and at runtime when a name is created using the "irm name create" CLI tool. The user needs to have permissions to access the keyfile and certificate when specifying the paths with the "irm name create" CLI tool. Signed-off-by: Dimitri Staessens