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.

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

  • Socket-driven TLS 1.3 client (handshake state machine + I/O).
  • Certificate-chain path validation.
  • HPACK encoding (decoding ships today).
  • 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.