Why own the implementation
Most stacks import a crypto library as an opaque dependency. The MAX runtime carries its own C implementations instead — Ed25519 ported from TweetNaCl, Argon2id and BLAKE2b ported from the Argon2 reference code, and TLS 1.3's record layer, key schedule and handshake — exposed to MAX programs as builtins. The discipline is the one the lab applies to its compiler and its OS: own the primitive end to end and verify it against the standard's own test vectors.
How it is verified
- TLS 1.3 record layer — nonce sequencing, additional-authenticated-data framing, round-trip, and tamper-rejection all checked against known-answer tests.
- Ed25519 — verified against the RFC 8032 §7.1 official test vector, hardened against the S<L malleability, all-zero-public-key, and non-canonical-y classes of signature-forgery bugs.
- Argon2id — RFC 9106 memory-hard key derivation.
- A TLS 1.3 handshake gate replays the RFC 8448 example handshake offline, exercising the stack end to end, not just its individual primitives in isolation.
Also as FPGA RTL — in simulation
The same per-frame crypto hot path — SHA-256 and Poly1305 — also exists as a hand-written hardware circuit (Verilog) for the programmable-logic fabric of a Xilinx Zynq-7020. It is verified in Verilator simulation against a golden-vector testbench to be byte-identical to the MAX/C software core — the same discipline applied one layer lower.
Where it is used
These builtins serve MAX programs that need cryptography. The lab's Rust projects, such as KeiAuth and kgl-overlay, use standard open-source crypto libraries instead.
