Standard Library: Crypto & Protocol Primitives

A library of cryptographic, TLS 1.3, and HTTP/2 primitives written in pure MIND — no C bindings, no vendored crypto library. Every primitive is verified against the published RFC or NIST known-answer test (KAT) vectors, in keeping with the compiler’s evidence-gated approach: a primitive ships only with its reference vectors passing.

Warning

Honest scope: this is a verified primitive library, not a working TLS client or server. There is no socket-driven handshake state machine yet, no certificate-chain path validation (single-certificate parse + signature verify only), and HPACK is decode-only. A usable TLS client built on these primitives is on the roadmap. The primitives are correctness-first — they are not speed-optimized.

Cryptographic primitives

AES-128-GCM

Authenticated encryption (NIST KAT-verified).

ChaCha20-Poly1305

AEAD (RFC 8439), the TLS 1.3 mandatory TLS_CHACHA20_POLY1305_SHA256 suite.

SHA-256 and HKDF

Hashing and key derivation (RFC test vectors).

SHA-512 / SHA-384

FIPS 180-4, full 64-bit word.

Keccak / SHA-3 + SHAKE

FIPS 202 sponge family.

X25519

Elliptic-curve Diffie-Hellman key agreement (RFC 7748).

RSA-PSS (SHA-256)

Signature verification.

ECDSA-P256 (SHA-256)

Signature verification.

ML-KEM-768

Post-quantum key encapsulation (FIPS 203).

X25519MLKEM768

Post-quantum hybrid key exchange, composing the X25519 and ML-KEM-768 entry points above (no primitive is reimplemented) and concatenating the two shared secrets in the order the hybrid combiner fixes.

X.509

DER certificate parsing + signature verification (single certificate; no chain-path validation yet).

TLS 1.3 primitives

Key schedule

HKDF-Expand-Label / Derive-Secret.

Record layer

AEAD record seal/open.

Finished MAC + transcript hash

Handshake crypto orchestration

Verified by replaying the RFC 8448 trace end-to-end.

HTTP primitives

HPACK

Header decompression (RFC 7541; decode-only today).

HTTP/2 framing

Binary frame layer (RFC 9113).

Verification approach

Each module carries its reference vectors as executable checks — AES-GCM against the NIST KATs, the TLS 1.3 handshake against the RFC 8448 keying-material trace, ML-KEM against the FIPS 203 vectors, and so on. The point is the same one the compiler makes elsewhere: a claim ships with the evidence that checks it.

// Shape of the verification harness (illustrative)
// Every primitive module ships a kat_* entry point that
// returns 0 on success and a nonzero vector index on the
// first failing known-answer test.
fn kat_aes128_gcm() -> i64;   // NIST GCM vectors
fn kat_tls13_rfc8448() -> i64; // RFC 8448 handshake replay
fn kat_mlkem768() -> i64;      // FIPS 203 vectors

Roadmap

Planned

Socket-driven TLS 1.3 client (handshake state machine + I/O)

Planned

Certificate-chain path validation

Planned

HPACK encoding (decoding ships today)

Planned

Broader cipher and signature coverage: AES-256-GCM, Ed25519, ML-DSA

See also std.io for the syscall surface these modules would pair with, and Determinism for the execution guarantees that apply to this integer-only code.