Skip to main content

core.security

Verum's security stdlib is a consolidated subtree covering:

  • Cryptographic primitives — hashes (SHA-2 family + BLAKE3 + non-crypto CRC-32/32C/XXH64/MurmurHash3), MACs, KDFs (HKDF + PBKDF2), symmetric ciphers, AEADs, elliptic-curve crypto (Ed25519, X25519, P-256, ECVRF, BLS12-381 pairing), post-quantum (ML-KEM, ML-DSA, SPHINCS+), HPKE (RFC 9180), zero-knowledge proof systems (Halo2 + KZG10, STARK + FRI).
  • High-level auth primitives — JWT (RFC 7519/7515), COSE (RFC 9052), TOTP/HOTP (RFC 4226/6238), password hashing with PHC modular format, CSPRNG session/CSRF/OTP tokens.
  • Integrity + provenance — Merkle trees (RFC 6962 CT-style), X.509 + RFC 6125 server-identity verifier.
  • Runtime classification tags and explicit flow comparisons.
  • Workload identity (SPIFFE / SPIRE).
  • Secret stores (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager).
  • Region-based isolation — zero-overhead &'r T references.

For the full map and architectural context, start at the security overview.

Cryptographic primitives​

  • hash — SHA-256/384/512, BLAKE3, CRC-32/32C, XXH64, MurmurHash3 (32 + 128-bit)
  • mac — HMAC-SHA-family + Poly1305
  • kdf — HKDF + PBKDF2 (HMAC-SHA256/384/512)
  • cipher — AES + ChaCha20
  • aead — AES-GCM + ChaCha20-Poly1305
  • ecc — Ed25519, X25519 ECDH, P-256, ECVRF (RFC 9381), BLS12-381 pairing + threshold sigs
  • pq — ML-KEM + ML-DSA + SPHINCS+ post-quantum
  • zk — Halo2 + KZG10 (BLS12-381) + STARK + FRI (PQ-secure)
  • hpke — RFC 9180 Hybrid Public Key Encryption (Mode Base: DHKEM-X25519 + HKDF-SHA256 + ChaCha20-Poly1305) — the primitive behind ECH, MLS, Privacy Pass
  • util — constant-time ops, zeroise, RNG

Token / credential primitives​

  • jwt — JSON Web Tokens (RFC 7519 + 7515) with HS256/384/512 and EdDSA; alg:none rejected, algorithm-confusion blocked by typed JwtKey, constant-time signature compare
  • cose — CBOR Object Signing and Encryption (RFC 9052); Sign1 (EdDSA) + Mac0 (HS256/384/512) — the form behind WebAuthn passkeys, CWT, mDoc
  • otp — HOTP (RFC 4226) + TOTP (RFC 6238); rejection-sampled uniform, ±window anti-drift verify, otpauth:// provisioning URI
  • password_hash — PHC modular format with PBKDF2-HMAC-SHA256 backend; 100k-iteration floor, constant-time verify
  • token — CSPRNG-backed session/CSRF/OTP tokens (URL-safe base64, hex, numeric) with 128-bit entropy floor
  • merkle — RFC 6962 CT-style Merkle tree; inclusion proofs with odd-leaf promotion (CVE-2012-2459-safe)
Everything that needs fresh randomness stops at Tier 0

Checked. Three of the modules above cannot produce a value under the interpreter, and they fail at the point where they ask for random bytes:

Pbkdf2Sha256Hasher.with_defaults().hash(pw) → [xmod-unresolved]
otp.generate_secret(20) → [xmod-unresolved]
token.generate_bytes(16) → [xmod-unresolved]

Panic: [xmod-unresolved] cross-module call to '...fill_secure...'
never resolved: the callee's body is absent from the assembled module

random.secure.fill_secure itself is fine — called directly from your own programme it fills a buffer correctly, 4 of 4 bytes non-zero. What does not resolve is the call from one standard-library module to another, so a salt, an OTP secret and a session token all fail to be generated rather than being generated badly. The same panic stops QUIC address tokens and stateless-reset keys.

Read this as "cannot run", not "runs weakly". Nothing here produces a low-entropy value; the call aborts. rsa_oaep.mgf1_sha1, which needs no fresh randomness, works — so the failure tracks the randomness dependency exactly.

Identity, secrets, policy​

  • spiffe — workload identity
  • secrets — Vault / AWS / GCP
  • labels — runtime tags and flow comparisons
  • regions — region-based isolation
  • capabilities — capability restrictions and annotation limitations

Where to start​

  • New to crypto? Read the overview first for architectural context and threat model, then follow the quick-start in whichever primitive you need.
  • Building TLS / QUIC? You'll use aead, kdf, ecc, and pq. Most TLS work happens inside core.net.tls, which consumes these as its underlying primitives.
  • Handling PII / regulated data? labels describes runtime tags and their limits. Your application must enforce its own policy at logs, responses, and other output boundaries.
  • Running in Kubernetes? spiffe gives you workload identity via SPIRE; secrets hands you Vault / cloud secrets.