Hidden sheet — Security · Crypto & TLS
zsec
The mz security layer — a dependency-free crypto and TLS core, drawn once and run in three places.
| Layer | Security · Crypto & TLS |
|---|---|
| Language | C23 |
| Targets | freestanding · mzOS2 kernel (no libc) · userspace · host tooling |
| Depends on | — (foundation) |
| Organization | ZeunO8 |
| Source | Private alpha — opens with a change order on this site’s log |
General notes
zsec is the microZeus security layer: a crypto and TLS core in C23 that depends on nothing but the freestanding headers the C standard guarantees. It exists so one implementation runs in three places from one source — inside the mzOS2 kernel with no libc at all, in ordinary userspace, and in host tooling — because three separate ports of a security layer will drift, and the one that drifts is the one nobody is testing. It is the layer the rest of the stack will verify its updates against; drawn here in hidden line because it sits under everything and is not yet finished.
The constraints are load-bearing, not stylistic. No dependencies — only stdint, stddef, and stdbool, the headers guaranteed even with no hosted library. No allocation — every context is a caller-owned fixed-size struct, so the whole layer works with no heap. No hidden platform calls — no stdio, no time(), no filesystem; anything the platform must supply arrives through an explicitly injected hook. And constant time over secrets — secret-dependent branches and secret-dependent memory indexing are bugs here, not style, so comparisons go through a constant-time equal and dead key material is wiped through volatile so the scrub cannot be optimised away.
The primitives are in and pinned to published vectors: SHA-256/384/512, HMAC and HKDF, the TLS 1.3 key schedule, ChaCha20-Poly1305, a constant-time table-free AES with AES-GCM, and X25519 with low-order-point rejection. TLS 1.0 through 1.3 share one code path, shaped by 1.3 with the older versions expressed as restrictions of it. What is deliberately NOT here yet is exactly the part where trust would be at stake — no handshake, no certificate validation, no CSPRNG — and the status is nailed to the library so no one forgets: do not put this in front of anything real until those land.
Bill of materials — what’s in the box
- Dependency-free C23 — only <stdint.h>, <stddef.h>, <stdbool.h>, the freestanding headers guaranteed with no hosted library
- One source, three targets — the mzOS2 kernel (no libc), userspace, and host tooling — so a security layer cannot drift between ports
- No allocation: every context is a caller-owned fixed-size struct; the whole layer runs with no heap
- No hidden platform calls: no stdio, time(), or filesystem — the platform supplies entropy and the clock through an explicitly injected hook
- Constant time over secrets: no secret-dependent branch or memory index; constant-time compare; key material wiped through volatile so a dead-secret scrub cannot be optimised away
- SHA-256/384/512, HMAC, HKDF; ChaCha20-Poly1305; constant-time table-free AES-128/192/256 + AES-GCM (constant-time GHASH); X25519 with low-order-point rejection
- TLS 1.0–1.3 on one code path — shaped by 1.3, older versions expressed as restrictions; TLS 1.0/1.1 disabled by default (RFC 8996), enabling them an explicit per-context act the review can see
- The differential oracle: published vectors only (FIPS 180-4, RFC 4231/5869/8439/8446/8448), each reproduced against an independent implementation, plus randomised differential testing against OpenSSL demanding byte-for-byte agreement — skipped LOUDLY when OpenSSL is absent, never silently, because a differential suite that quietly stops running is worse than one never written
- Honest about the gap: no handshake, no certificate validation, no CSPRNG yet — "do not put this in front of anything real"; the parts not written are exactly the parts where trust would be at stake