## What it is
nxtls is cryptography and a TLS 1.3 client written entirely in Nexium, my own language — no C libraries, no @cImport, and not one unsafe block, so a reviewer can read it end to end. It exists so Nexium programs can verify signatures and speak HTTPS without handing their security to a C library. Its first real user is a Discord helper I wrote for an amateur-radio club, which checks the Ed25519 signature on every request with it and talks to Discord through its TLS client.
## What's in it
- Primitives — SHA-256, SHA-384 and SHA-512, HMAC with a constant-time
verify, HKDF with TLS 1.3'sexpand_label, and X25519 and ChaCha20-Poly1305 in constant time. - Signature verification — Ed25519 (strict in the ways libsodium is), ECDSA on P-256 and P-384, and RSA PKCS #1 v1.5 and PSS, on top of a strict DER reader and a small Montgomery bignum.
- X.509 — path building across cross-signed CAs, validity periods, CA constraints and path lengths, key usage, and host names with wildcards.
- TLS 1.3 — a client with ChaCha20-Poly1305 and X25519 that handles HelloRetryRequest, KeyUpdate, and servers that ask for a client certificate. The protocol core is bytes in, bytes out; a separate type runs it over TCP.
## How it's tested
Every module is checked against its published vectors — FIPS 180-4 and RFCs 4231, 5869, 7748, 8032, 8439 and 8448 — and against Python's cryptography package, which a generator script uses as an oracle while it re-derives every constant table from its definition. The X.509 code is judged on 68 chains and 13 malformed certificates by cryptography's own path validation. The TLS client replays 35 recorded exchanges byte for byte, runs against OpenSSL 3's s_server in twelve configurations — including the ones it must refuse: the wrong host, an expired certificate, TLS 1.2 — and connects live to Discord, GitHub, Google and Cloudflare. CI runs all of it on Linux, Windows and macOS, and fails any module that grows an unsafe block, a mutable global, or a foreign call.
## The honest part
It's new, and nobody who knows TLS has reviewed it yet — the README says so up front, and that review is the next item on the plan. It also won't fall back to a weaker source of randomness: on Windows, where it has no /dev/urandom, tls.connect says so and stops. Until that review happens, treat it as a careful reading of the RFCs, not something to trust with anything that matters.