Real. Where a supported library (rustls) has no config knob for the historical misconfiguration being taught — finite-field DHE, RSA_EXPORT, explicit-curve ECDHE, static-key KEMTLS — the platform hand-rolls a genuine TLS 1.2/1.3 engine instead: real record layer, real key schedule, real Finished messages. There is no vendored X.509/ASN.1 crate anywhere in the project either. And the cryptography is the genuine article: every algorithm in the lab passes its official Known-Answer Tests, not just the post-quantum ones. A single audit (audit_kat.sh) validates each primitive bit-for-bit against the standard's own vectors — ML-KEM-768 (FIPS 203), ML-DSA-65 (FIPS 204), HQC and SLH-DSA-SHAKE-128f (FIPS 205) against the NIST ACVP / KAT vectors, and the classical primitives (SHA-2/SHA-3, SHAKE, HMAC, HKDF, AES-GCM, PBKDF2, RSA PKCS#1 v1.5 & PSS, DSA, ECDSA P-256) against their FIPS / RFC test vectors. Keys and signatures therefore interoperate with any standard library — the weakness is always in how a primitive is used, never a toy look-alike.

You should be comfortable with TLS fundamentals, a terminal, and modular arithmetic. Levels 1-2 explain enough as you go; Levels 3-4 assume you can follow a lattice-reduction or index-calculus argument.

A 32-byte secret, as 64 hex characters, that the TLS client sent the server inside the (broken) TLS session. It's checked against an independent validator process, not against a static answer file.

No — deliberately. The student archive ships pre-built Docker images and a launcher script only, so nothing on disk hands you the answer by accident. That's separate from the challenge solutions themselves, which are included in full.

Yes. Every one of the 125 challenges ships with a complete, working exploit script and a written explanation of the technique. Try first — the solution is there the moment you want it.

The core attack model needs a genuinely rootful Linux Docker daemon with direct host access to the lab's bridge network for ARP spoofing — something a rootless daemon (and most non-Linux Docker setups) cannot provide. The optional attacker-toolbox container works around this for challenges that don't strictly need a host-level MITM position, but a native Linux host is what this was built and tested against.

Small either way. The three core containers (server, client, validator) are FROM scratch, UPX-packed Rust binaries. The free 12-challenge sample measures about 2.2 MB combined on disk; the full 125-challenge build compiles in more challenge code per binary, so it's larger — roughly 5 MB combined, based on this project's own measured light-vs-full size delta (~50-65% smaller per binary when only 12 of 125 challenges are compiled in). RAM stays around 10 MB total either way — only one challenge runs at a time regardless of how many are compiled in, so RAM tracks the active challenge, not the build size. CPU usage is negligible outside brief bursts during key generation at startup. Docker Compose caps each container at 2 GB RAM / 2 CPU cores as a safety ceiling, not a requirement — real usage is a small fraction of that. One documented exception: server_rsa_hundreds_servers_tls12 spawns 501 parallel RSA-2048 key generations at startup and needs --cpus=8 to finish in reasonable time. The optional attacker toolbox (nmap, hydra, etc. — only built if you ask for it) adds roughly 70 MB and isn't required for most challenges.

Every challenge's write-up in the manual explains the vulnerability class and the technique that solves it, and the included solution script is there if you'd rather see it worked end to end. For anything beyond that, reach out — contact details will be provided with the release materials.