Forem: Nenad Mićić

URTB: An Encrypted PTY Tunnel Over ESP-NOW and LoRa

Nenad Mićić — Fri, 17 Apr 2026 00:32:30 +0000

I have two personal laptops: a MacBook Air I carry around the house, and an old Lenovo that mostly stays in the garage. They sit on different VPNs. When WireGuard testing cuts me off I still need a shell on the other machine, and carrying a 5 kg laptop around the house is not practical.

A pair of Heltec WiFi LoRa 32 V3 boards, plugged into USB on each laptop, solve that problem. URTB is the host binary and matching firmware that give me an encrypted interactive shell over ESP-NOW, with LoRa as automatic fallback.

What it is

Two urtb processes, each holding the same passphrase-protected capsule file, establish an XChaCha20-Poly1305 session and carry a PTY shell between them. The primary transport is ESP-NOW. In my indoor tests on a clear 2.4 GHz channel, that meant roughly 1-2 Mbps and sub-5 ms latency. When ESP-NOW fails, the session continues automatically over LoRa: slower, but longer-range and sub-GHz. No session renegotiation. The same binary also works over a UNIX socket or through an SSH jump host, so you can try it without any radio hardware.

./urtb keygen --out pairing.capsule

# machine A
./urtb listen --transport heltec --device /dev/cu.usbserial-0001 --capsule pairing.capsule

# machine B
./urtb connect --transport heltec --device /dev/cu.usbserial-0002 --capsule pairing.capsule

Two scenarios worth explaining

ESP-NOW primary, LoRa fallback.
LoRa is useful as an emergency channel. I tested Reticulum's rnsh on real hardware. It works, but in my LoRa tests it was doing roughly 200-400 bytes/second and 200-500 ms per keystroke, which makes interactive use painful. top takes 10-15 seconds to redraw. The bottleneck is LoRa's physical layer, not rnsh. ESP-NOW fixes the throughput problem for short range. URTB uses both: ESP-NOW when it is available, LoRa when it is not, with the session staying alive across the switch.

Encrypted terminal through a restricted SSH jump host.
Say you need to reach a server in a DMZ through a jump host you do not fully trust. Only port 22 is open. AllowTcpForwarding is disabled. VPN and Mosh need additional ports. The jump host may be compromised.

URTB has two useful patterns here. The simple one uses --exec: the URTB AEAD-encrypted tunnel rides inside an SSH byte stream and does not need port forwarding, ProxyJump, or any extra listener on the jump host.

For the stricter case, pre-start a listener on the target with --loop and bridge through the jump host with ssh ... socat STDIO UNIX:/tmp/urtb.sock. That keeps the capsule passphrase local to the endpoints.

# target
URTB_PASSPHRASE=example-passphrase ./urtb listen --transport unix \
    --socket /tmp/urtb.sock --capsule cap.cap --loop

# client
URTB_PASSPHRASE=example-passphrase ./urtb connect \
    --exec "ssh jump ssh target socat STDIO UNIX:/tmp/urtb.sock" \
    --capsule cap.cap

The capsule is transferred out-of-band to the target; the jump host is not trusted with it and does not need to persist it. The jump host still relays bytes, but it is not trusted with session plaintext.

Once the capsule is loaded, --burn does a best-effort local wipe and unlink of the key files. After that, key material stays in process memory for the lifetime of the process, with mlock and MADV_DONTDUMP where the platform supports it. Add --otp and the attacker also needs a valid HOTP/TOTP code to open the PTY, even if they obtain the capsule file from another channel.

How I built it

This is an AI-assisted project. The implementation was generated with AI against a frozen specification that I wrote first and then reviewed in multiple rounds with different models before any code was generated.

The process, briefly:

Specification first. About 2,000 lines of markdown across SPEC.md, PROTOCOL.md, SECURITY.md, ACCEPTANCE_CRITERIA.md, and DECISIONS.md before any code was generated.
Adversarial multi-agent review. The spec went through seven review rounds using multiple AI agents with different remits: protocol correctness, crypto audit, numerical consistency, and state-machine verification. The 7th round caught a fragmentation logic contradiction that would have forced a rewrite of the channel multiplexer if it had survived into implementation.
Freeze, then generate. Once the spec was clean, I froze it and pointed the code-generation agents at it.
Implementation review, same method. Multiple blind agents reviewed the code, then a synthesis pass pulled the findings together. The OTP bypass in burn mode (if (s->otp_path) instead of || s->otp_key_mem) was caught this way.
Hardware in the loop. Two Heltec V3 boards stayed connected over USB during development. The models could run end-to-end tests on real hardware. I also had them write failure-injection code: the firmware has a test-inject build that can drop ESP-NOW TX, drop LoRa TX, and simulate link failure on command from the host.
Disposable VM for jump-host testing. Jump-host scenarios were tested against a KVM virtual machine that could be rebuilt on demand via a signed wrapper script. All eight HOWTO_JUMPHOST scenarios were validated end-to-end that way.

What came out

The host binary is about 8,000 lines of C with no dependencies beyond libc and Monocypher. The firmware is about 1,050 lines of C++ (Arduino/PlatformIO). Notable properties:

XChaCha20-Poly1305 AEAD, BLAKE2b key derivation, Argon2id-protected key storage
256-entry additive-fencepost replay window
PTY multiplexing with fragmentation for LoRa's 72-byte plaintext MTU
Automatic ESP-NOW-to-LoRa failover and recovery without session renegotiation
LoRa duty-cycle-aware batching for the EU 868 MHz 1% limit
Optional HOTP/TOTP second factor
--burn: best-effort local wipe and unlink of capsule and OTP key files after load
Signal handlers that wipe PSK from memory on SIGTERM, SIGHUP, SIGQUIT, and best-effort on SIGSEGV/SIGBUS/SIGFPE
MADV_DONTDUMP to exclude key material from core dumps on Linux
Landlock + seccomp sandbox profiles for both connect and listen modes
42 acceptance criteria passing, 8 failure-injection tests passing, CI on GitHub Actions

I ran cat /dev/urandom through the full stack — radio, USB framing, AEAD, reassembly — for 20 minutes without a crash. That was the test that satisfied me the code was not just correct on the happy path.

Limitations

Worth being explicit about what this is not:

Not audited. This is a personal project. The security surface was designed carefully, but it has not been reviewed by an independent security firm.
LoRa is very slow. In my tests it was around 200-400 bytes/second. Short commands work; anything that generates significant output needs the throttling mode or the session becomes sluggish.
Not a VPN. No IP routing, no general port forwarding. One encrypted PTY session between two named processes.
No general file transfer yet. This is terminal-first.
--burn is best-effort. On SSDs and modern filesystems, overwrite-before-unlink is not a guarantee of non-recoverability. It reduces exposure from filesystem access after the process exits; it is not cryptographic erasure.
Compartment sandbox is optional. The Landlock + seccomp profiles in compartment/ are not enabled by default. They require a separate tool ( compartment , also mine) and manual profile activation.

Repository

The project is public at github.com/nmicic/URTB. You can try it without hardware using --transport unix; the quick start in the README takes about 30 seconds once dependencies are installed. The name stands for USB-Radio Terminal Bridge.

The code is AI-assisted and I am not hiding that. The specification, the review process, the acceptance criteria, the testing methodology, and the decision to ship or not ship — those are mine.

I Built compartment to Sandbox AI Agents on Linux

Nenad Mićić — Thu, 02 Apr 2026 12:06:30 +0000

AI coding agents are useful, but in a corporate environment they are often too privileged by default.

They can read files, edit code, run commands, inherit environment variables, and talk to the network. I wanted a smaller trust boundary for tools like Claude Code and Codex CLI.

So I built compartment, a small Linux process isolation toolkit with:

compartment-user — rootless confinement using Landlock, seccomp, and no_new_privs
compartment-root — stronger namespace-based isolation when needed
one shared profile format
zero external dependencies

This is also a rebuild of an old idea. Back in 2003, I wrote shell-guard, a wrapper that intercepted shell execution and applied policy early. Modern Linux finally has the kernel primitives to do that idea properly.

I built compartment primarily for AI-agent sandboxing, but the same logic also applies to other semi-trusted local tools, including SSH.

Small tool. Explicit policy. Lower blast radius.

GitHub: github.com/nmicic/compartment
README: github.com/nmicic/compartment#readme

From 2-Adic Geometry to Cunningham Chains: Visualization-Driven GPU Search

Nenad Mićić — Wed, 11 Mar 2026 09:42:27 +0000

**Update (March 17, 2026): Since publishing this post, the campaign found two first-kind CC18s with roots 106103983461039119546815109 (87 bits) and 214325014495971624590189129 (88 bits). A later prior-art review showed that first-kind CC18 had already been documented in John Armitage’s 2021 Oxford thesis via the smallest known example, so these are not the first known CC18s. They do, however, remain the largest listed first-kind CC18 entries on the current public Cunningham tables. The campaign has now finished because my available GPU compute time ran out. The original post below is left mostly unchanged as the March 11 baseline.

From 2-Adic Geometry to Cunningham Chains: Visualization-Driven GPU Search

Nenad Mićić · LinkedIn · March 2026

What This Is

A visualization hobby project that turned into a high-throughput Cunningham chain search engine. More about HPC optimization and AI-assisted iteration than the math itself.

It started with mapping integers in a 2-adic geometry, noticing structured prime paths, recognizing Cunningham-chain recurrences, and then building a GPU/CPU pipeline to search for long chains.

Results

This project ultimately did reach its CC18 target, but not the more ambitious CC19 goal. It remained a compute-limited campaign.

As of March 2026, the public Cunningham chain tables at pzktupel.de list results under my name, Nenad Mićić, including:

new CC16 and CC17 entries
the largest listed first-kind CC16, CC17, and CC18 on the current public tables

The published data snapshot contains 929,574 roots in total, including 44 CC16 roots and 1 CC17. The main campaign was centered on the 89–91 bit range, and the release includes both the search code and derived analysis:

gap statistics and spacing distributions
immunization / residue summaries and immune-fingerprint distributions
p+1 breaker analysis
ghost chains — roots where prime links continue beyond the official chain break, tested to depth 20
closest CC-twins and CC-clusters (triplets, quadruplets, quintuplets)

I think this dataset is useful in its own right and deserves deeper study.

How It Works

Visual learning led to search design.

The 2-adic coordinate system made chain structure visible. The p+1 factorization view showed which small-factor patterns kill candidates early. That became the sieve.

For a first-kind chain, a root p generates: p, 2p+1, 4p+3, 8p+7, ...

The key optimization is depth filtering:

generate candidates on the CRT-and-wheel search lattice
test cheap modular conditions across the first d projected chain positions
reject any root whose chain is already doomed modulo a tracked small prime
send only the tiny survivor set to the CPU for probable-prime testing and full chain confirmation

Pipeline:

GPU (CUDA): 57–65 billion candidates/sec modular filtering (RTX 4090 / RTX 5090)
CPU (GMP): probable-prime testing, true-root recovery for non-roots, and chain-length confirmation

The GPU sieve rejects about 99.9988% of candidates before expensive primality work is needed. Only about 0.0012% survive to the CPU path.

Interactive Visualizations

Each tool shaped the search design.

Cunningham Chain Mesh: 2-adic square-perimeter map with CC1/CC2 edges and chain paths
2-Adic Tree Explorer: inspectable tree with local chain structure
3D Fold: shell structure across levels; top view becomes the p+1 analysis grid
p+1 Analysis: factor coloring for primes, mod-p view for composites
Chain Analyzer: single-chain analysis, breaker autopsy, residue immunity
Campaign Dashboard: live campaign tracking across bit ranges and chain lengths
Immunization Dashboard: residue immunity analysis

Project Stack

Search: CUDA filtering, GMP proving, prefix sharding, checkpointing
Visualization: standalone HTML/JS tools
Analysis: Python plus HTML tools for autopsy and fingerprinting
AI-assisted: LLMs used for coding iteration; math direction and search decisions are human-driven
Extra: a PARI/GP library and a small MCP server wrapper for interactive Cunningham-chain analysis

Part of the project was also an experiment in AI-assisted iteration: not one-shot prompting, but many rounds of visual exploration, code generation, rejection, correction, and performance tuning. The transferable lesson for me was not number theory itself, but the workflow: isolate the hot path, turn it into something benchmarkable, iterate quickly with AI assistance, and only bring back changes that survive measurement.

Compass, Steering Wheel, Destination — Framework for Working with AI on Code

Nenad Mićić — Mon, 15 Sep 2025 08:42:38 +0000

I'm sharing this with the team as a summary of my personal workflow when working with AI on code. It's not an official framework, but rather a set of learnings from experience (polished with a little help from AI, of course). My main goal is to start a conversation. If you have a better or similar workflow, I'd genuinely love to hear about it.

Compass, Steering Wheel, Destination — Framework for Working with AI on Code

AI can accelerate coding, but it can also drift, hallucinate requirements, or produce complex solutions without a clear rationale.
This framework provides the guardrails to keep AI-assisted development focused, deliberate, and well-documented.

Sailing Analogy (High-Level Intro)

Working with AI on code is like sailing:

Compass → Keeps you oriented to true north (goals, requirements, assumptions).
Steering Wheel → Lets you pivot, tack, or hold steady (decide continue vs. change).
Destination Map → Ensures the journey is recorded (reusable, reproducible outcomes).

This framework grew out of real-world experience. It’s not brand new theory, but a way to formalize a shared language for teams working with AI.

Step 1: Compass (Revalidation)

Purpose: keep alignment with goals and assumptions.

Template (copy/paste):

What’s the primary goal?
What’s the secondary/nice-to-have goal?
Which requirements are mandatory vs optional?
What are the current assumptions? Which may be invalid?
Has anything in the context changed (constraints, environment, stakeholders)?
Are human and AI/system understanding still in sync?
Any signs of drift (scope creep, contradictions, wrong optimization target)?

Step 2: Steering Wheel (Course Correction)

Purpose: evaluate if we should continue, pivot, or stop.

Template (copy/paste):

For each assumption: what if it’s false?
Does an existing tool/library cover ≥80%?
Does this map to an existing framework/pattern (ADR, RFC, design template)?

Alternatives:

Different algorithm/data structure?
Different architecture (batch vs streaming, CPU vs GPU, local vs distributed)?
Different representation (sketches, ML, summaries)?
Different layer (infra vs app, control vs data plane)?

Trade-offs:

Fit with requirements.
Complexity (build & maintain).
Time-to-value.
Risks & failure modes.

Other checks:

Overhead vs value: is the process slowing iteration?
Niche & opportunity: is this idea niche or broadly useful? Where does it fit in the landscape?

Kill/Go criteria:

Kill if effort > value, assumptions broken.
Go if results justify effort or uniqueness adds value.

Next step options:

Continue current path.
Pivot to alternative.
Stop and adopt existing solution.
Run a 1-day spike to test a risky assumption.

Step 3: Destination (Reverse Prompt)

Purpose: capture the outcome in reusable, reproducible form.

Template (copy/paste):

Instructions

Restate my request so it can be reused to regenerate the exact same code and documentation.
Include a clear summary of the key idea(s), algorithm(s), and reasoning that shaped the solution.
Preserve wording, structure, and order exactly — no “helpful rewrites” or “improvements.”

Reverse Prompt (regeneration anchor)

Problem restatement (1–2 sentences).
Key algorithm(s) in plain language.
Invariants & assumptions (what must always hold true).
Interfaces & I/O contract (inputs, outputs, error cases).
Config surface (flags, environment variables, options).
Acceptance tests / minimal examples (clear input → output pairs).

High-Level Design (HLD)

Purpose: what the system solves and why.
Key algorithm(s): step-by-step flow, core logic, choice of data structures.
Trade-offs: why this approach was chosen, why others were rejected.
Evolution path: how the design changed from earlier attempts.
Complexity and bottlenecks: where it might fail or slow down.

Low-Level Design (LLD)

Structure: files, functions, modules, data layouts.
Control flow: inputs → processing → outputs.
Error handling and edge cases.
Configuration and options, with examples.
Security and reliability notes.
Performance considerations and optimizations.

Functional Spec / How-To

Practical usage with examples (input/output).
Config examples (simple and advanced).
Troubleshooting (common errors, fixes).
Benchmarks (baseline numbers, reproducible).
Limits and gotchas.
Roadmap / extensions.

Critical Requirements

Always present HLD first, then LLD.
Emphasize algorithms and reasoning over just the raw code.
Clearly mark discarded alternatives with reasons.
Keep the response self-contained — it should stand alone as documentation even without the code.
Preserve the code exactly as it was produced originally. No silent changes, no creative rewrites.

When & Why to Use Each

Compass (Revalidation):
- Use at the start or whenever misalignment is suspected (context drift, new requirements).
Steering Wheel (Course Correction):
- Use at milestones or retrospectives to decide continue, pivot, or stop.
Destination (Reverse Prompt):
- Use at the end of a cycle/project to capture reproducible documentation & handover artifacts.

References & Correlations

This framework is simple, but it builds on proven practices:

Systems Engineering: Verification & Validation (build the right thing).
Agile: Sprint reviews (revalidation), retrospectives (course correction).
Lean Startup: Pivot vs. persevere decisions.
Architecture Practices: ADRs (decision rationale, alternatives).
AI Prompt Engineering: Reusable prompt templates & libraries.
Human-in-the-Loop Design: Oversight to prevent drift in AI systems.

By combining them under a sailing metaphor, the framework becomes:

Easy to remember.
Easy to communicate inside teams.
Easy to apply in AI-assisted coding where drift, misalignment, and reusability are everyday challenges.

Closing Note

Think of this as a playbook, not theory. Next time in a session, just say:

“Compass check” → Revalidate assumptions/goals.
“Steering wheel” → Consider pivot/alternatives.
“Destination” → Capture reproducible docs.

Forem: Nenad Mićić

URTB: An Encrypted PTY Tunnel Over ESP-NOW and LoRa

What it is

Two scenarios worth explaining

How I built it

What came out

Limitations

Repository

I Built compartment to Sandbox AI Agents on Linux

From 2-Adic Geometry to Cunningham Chains: Visualization-Driven GPU Search

From 2-Adic Geometry to Cunningham Chains: Visualization-Driven GPU Search

What This Is

Results

How It Works

Interactive Visualizations

Project Stack

Links

Compass, Steering Wheel, Destination — Framework for Working with AI on Code

Compass, Steering Wheel, Destination — Framework for Working with AI on Code

Sailing Analogy (High-Level Intro)

Step 1: Compass (Revalidation)

Step 2: Steering Wheel (Course Correction)

Step 3: Destination (Reverse Prompt)

When & Why to Use Each

References & Correlations

Closing Note