WvdS Crypto Service overview

Preview: The service is published as a preview. Protocols, error codes, and build options can change before the first approved release. The limitations at the end of this page describe the current state.

graph LR
    subgraph L4Re["L4Re microkernel"]
        C1["Your task, for example a gateway"] -- "binary protocol over shared memory" --> S1["Crypto service (l4re)"]
    end
    subgraph WIN["Windows"]
        C2["Your program"] -- "JSON lines over a named pipe" --> S2["Crypto service (win)"]
    end
    S1 --> O1["OpenSSL"]
    S2 --> O2["OpenSSL"]

Figure: Two deployment forms of the same service. Both keep keys inside their own process and use OpenSSL for the math; they differ in transport and message format.

WvdS Crypto Service is a service process that performs cryptographic operations on behalf of other programs: AES-256-GCM, the post-quantum signature scheme ML-DSA (FIPS 204), the post-quantum key encapsulation mechanism ML-KEM (FIPS 203), and HKDF-SHA256 key derivation. It's built for teams that develop embedded or industrial systems on the L4Re microkernel or on Windows and don't want to wire cryptography into every component separately. Your application sends a request and gets the result back; private keys never leave the service process.

• Two deployment forms: l4re for the L4Re microkernel on x86_64 and aarch64, reached through shared memory with a fixed binary format; win for Windows x86_64, reached through named pipes with JSON. For what separates them, see Deployment forms compared.
• Post-quantum algorithms: ML-DSA-44, -65, and -87 for signing and verification; ML-KEM-512, -768, and -1024 for encapsulation and decapsulation. OpenSSL computes both.
• Keys stay in the service: The service generates key pairs itself and returns only a key ID and the public key. Any operation that needs the private key refers to it by that ID.
• Nonce reuse protection: For AES-GCM, the service remembers the most recent nonces per key and rejects a repeat.
• Load limits: Both forms accept at most 60,000 requests per 60 seconds. The L4Re form also limits a message to 64 KiB of payload.
• Verifiable commitments for integrators: For the L4Re form, the C header wvds_crypto.h is the binding description of the binary protocol, and the test vectors in crypto_test_vectors.json show complete requests and responses byte for byte.

One service instead of many integrations. Every component that links OpenSSL on its own brings its own key storage, its own error handling, and its own update cycle. The service consolidates all of that in one place. The calling component needs no crypto library, only the transport.

A key ID instead of a key. Key generation returns a random 32-bit ID. Later requests use that ID; the caller never sees the private key. For details, see Keys and key storage.

Fixed algorithms, open parameter sets. The service offers all three parameter sets of ML-DSA and ML-KEM and leaves the choice to the caller. For which ones the German Federal Office for Information Security recommends in BSI TR-02102-1, and what the service doesn't provide yet, see Algorithms and parameter sets.

• Keys live in memory only. The service doesn't persist keys. After a restart, all keys and key IDs are gone. That makes it unsuitable for long-lived signing keys, such as those of a certificate authority; such keys belong in a hardware security module.
• No AES key provisioning over L4Re. The binary protocol has no request that generates or imports an AES key, so AES requests can't be used through the L4Re form today. The Windows form generates AES keys with keygen.
• No hybrid scheme. The service doesn't combine ML-KEM with a classical algorithm. If you need a hybrid scheme, you combine the secrets yourself.
• The L4Re form builds as a Linux program. The configured build targets produce Linux programs for x86_64 and aarch64. When such a program doesn't run on L4Re, it runs a demonstration of the algorithms and accepts no requests. For how the build targets relate, see Deployment forms compared.
• Two different protocols. The two forms don't understand the same messages. A program that talks to both needs two integrations.
• No certification. The service isn't certified under FIPS 140-3 or any other evaluation scheme.

• Get started
• Concepts
• How-to guides
• Reference
• Troubleshooting