Why write it from scratch
Most stacks import a crypto library as an opaque dependency. MAX implements TLS 1.3's record layer, key schedule, and certificate pinning, Ed25519 signatures, ChaCha20-Poly1305 AEAD, Argon2id key derivation, and BLAKE2b hashing directly from their RFCs — the same discipline the lab applies to its compiler and its OS: own the primitive end-to-end, verify it against the standard's own test vectors, and keep every build reproducible by hash.
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, used for disk-key and identity-seed derivation.
- A full TLS 1.3 handshake demo exercises the stack end-to-end, not just its individual primitives in isolation.
Also in hardware — an FPGA crypto engine
The same per-frame crypto hot path — SHA-256 and Poly1305 — also runs as a hand-written hardware circuit in a Xilinx Zynq-7020's programmable-logic fabric, alongside a bare-metal MAX OS port on its ARM processing system. The RTL is verified in simulation against a golden-vector testbench to be byte-identical to the MAX/C software core before it is trusted as a drop-in hardware replacement — the same discipline applied one layer lower, in silicon instead of in a compiled binary.
Where it is used
This stack is the cryptographic foundation the lab's own network-facing projects build on — inter-component message signing, the overlay-network data plane, KeiAuth's challenge/commit exchange, and the lab's own transport work.