Main CI

Code Quality

SAST uses git diff against upstream lwIP to filter out untouched upstream code and scans only targets unique to this repository. For upstream issues, file an issue with nonGNU.

DAST uses a locally-run hardware-in-the-loop workflow because the current emulator does not support Ethernet devices. A helper program runs on the calculator and exposes the DAST target while a local script attaches to it, performs network probes, advances the calculator-side test state, and writes results to JSON. This workflow then parses the JSON report and updates the test state accordingly.

Cryptography Quality Checks

Timing analysis checks for secret-dependent timing leaks: it samples repeated runs of a primitive across input classes designed to exercise different internal code paths (e.g. a bad MAC vs. a good one), then looks for variance in runtime that tracks the input class rather than noise. Some allowance is given for CPU jitter, computed via MAD-based sigma over the baseline class. This test does not prove the absence of secret-dependent timing leaks, but it provides statistical evidence that runtime stays consistent across all classes of input.

CAVP selects 16 random samples from the NIST RSP datasets that match the primitives we provide (with the exception of SHA-256 Monte Carlo, which selects one) (totaling 185 samples covering AES-CBC, GCM, CCM, SHA-256, HMAC-SHA-256, PBKDF2, HKDF, RSA-PSS-RSAE-SHA256, RSA-PKCS1-SHA256, and X25519). Where NIST publishes no RSP for a primitive (or in the case of RSA with e=65537), the output of python3-cryptography is used instead. Our workflow caches the expected values and then serializes the inputs into an AppVar for transfer to the TI-84+ CE. The CAVP profiler runs on the calculator, dumping the on-device primitive output to an AppVar that gets fed back to the test environment. The AppVar is then parsed and graded against the expectations cached. This test does not constitute a formal NIST CAVP certification; it validates our implementations against samples drawn from NIST’s published CAVP validation-vector datasets.

lwIP is a small networking stack built for low-resource embedded systems, maintained by nonGNU. lwIP-CE is a fork of it targeting the Texas Instruments TI-84+ CE graphing calculator, shipped as a dynamic library (libload) with a TLS 1.3 client stack, a USB CDC-ECM/NCM Ethernet driver, and an app-facing socket API. The original upstream readme is here.

Full documentation, API reference, and getting-started guide: https://cagscalclabs.github.io/lwip-ce/index.html

Whitepaper (architecture, threat model, validation methodology): https://github.com/cagscalclabs/lwip-ce/releases/tag/whitepaper-latest It's long so prepare yourself. But I wanted a descriptive, forward facing document for technical auditing.

• Programs link against lwIP-CE as a libload dynamic library, not by compiling src/ in. See Getting Started for installation and the required init sequence (lwip_start() → lwip_network_up() → socket API).
• The app-facing API is lwip_socket_* (create/connect/read/write/close) — a small, fixed verb set over TCP/UDP/TLS. Lower-level lwIP primitives (raw tcp_*/udp_* PCB callbacks) are still available for advanced use; see lwip.h and the doc site for both layers.
• TLS, the custom allocator, the USB Ethernet driver, and the truststore/CI validation pipeline are all covered in depth in the whitepaper and the doc site — this README intentionally stays short.

• First Beta Test: https://www.youtube.com/watch?v=fD2n7CzFeZU
• TCP and TLS Chat test: https://youtu.be/rX79owIVM-o
• Curated DAST test suite: https://www.youtube.com/shorts/APBYBo0O6sg
• IRC demo: https://www.youtube.com/watch?v=40q8J8R70nE