Random Number Generator PCG Period Collapse

2026-09-29T00:00:00+00:00

Keeping an ESP32 with Embassy Responsive While Doing Cryptography

2026-09-20T00:00:00+00:00

Recently, I built a randomness oracle for an ESP32 board using Embassy. I already knew about the cryptography that makes a randomness oracle tick, but I wanted to experiment with embedded Rust.

Embassy is an async runtime for the embedded Rust world. It provides the environment in which tasks execute, synchronization primitives, collaboration with hardware drivers, and more. Think of it as Tokio, but for embedded no_std environments.

Computing cryptography on an HTTP server can prove to be problematic because of how many CPU cycles it takes. In an async context, tasks are most often waiting on new IO or other hardware interrupts to be handled quickly. Introducing blocking synchronous code comes with its own challenges, especially in embedded. My fix was to give the cryptography its own Embassy executor on the ESP32's second core.

The Problem

As soon as the first request comes in, everything grinds to a halt. If you don't do anything special, the ESP32+Embassy template starts exactly one single-core executor. When the request reaches its handler, the cryptographic computation blocks cooperative execution.

There are other IO-heavy tasks that need to do some time-sensitive work and then go back to sleep. For instance, keeping the Wi-Fi alive, accepting network packets, handling peripheral interrupts, and so on. For these tasks, we use the await keyword and Embassy knows what each task is waiting on and can wake them up as things go along.

We'd usually hand this CPU-heavy part of the task to tokio::spawn_blocking to be executed in a thread where it can't block cooperative code. Here, though, there's no concept of threads because there's no OS.

Task Management in Static Memory with Worker Tasks

The solution I picked is to create a second instance of an Embassy thread-mode Executor on a separate core and offload CPU-heavy code to it. This second core will only run worker tasks with the job of doing cryptographic computation. Blocking code will run from start to finish, preventing other blocking code from running, but that's fine because it only blocks other cryptographic workers.

// Start Core 1 Executor
esp_rtos::start_second_core(
    cpu_ctrl,
    software_interrupt1,
    app_core_stack,
    move || {
        let executor = EXECUTOR_CORE1.init(esp_rtos::embassy::Executor::new());
        executor.run(|spawner| {
            for task_id in 0..WEB_TASK_POOL_SIZE {
                spawner.spawn(crypto_worker_task(task_id, &app_states[task_id]).unwrap());
            }
        });
    },
);

(src/web.rs, lines 202–215)

esp_rtos is the package that contains both the RTOS and an integration with Embassy. Here, we only use the Embassy integration.

Another wrinkle is that Embassy works without a memory allocator. The runtime memory for running a task needs to be static and defined at compile time. We can't run these workers in a dynamically sized pool; we need to define how many workers (at least an upper bound) will be instantiated.

This lets us map request handler workers to cryptographic workers 1:1. Each request worker is assigned an ID, and uses it to offload blocking work to its related cryptographic worker.

const WEB_TASK_POOL_SIZE: usize = 4;

static CRYPTO_REQUESTS: [Signal<CriticalSectionRawMutex, RandomnessQuery>; WEB_TASK_POOL_SIZE] = [
    Signal::new(),
    Signal::new(),
    Signal::new(),
    Signal::new(),
];

static CRYPTO_RESPONSES: [Signal<CriticalSectionRawMutex, RandomnessResponse>; WEB_TASK_POOL_SIZE] = [
    Signal::new(),
    Signal::new(),
    Signal::new(),
    Signal::new(),
];

(src/web.rs, lines 43–57)

async fn serve_randomness(
    State(state): State<&'static AppState>,
    Query(query): Query<RandomnessQuery>,
) -> Json<RandomnessResponse> {
    CRYPTO_REQUESTS[state.task_id].signal(query);
    let res = CRYPTO_RESPONSES[state.task_id].wait().await;
    Json(res)
}

(src/web.rs, lines 94–101)

A system with a queue could have been designed, but it would still have to be bounded because of the static memory constraint. Also, it would make matching cryptographic requests with responses harder since everything goes through a single queue.

Here's the code that computes the CPU-heavy part of the response:

#[embassy_executor::task(pool_size = WEB_TASK_POOL_SIZE)]
async fn crypto_worker_task(task_id: usize, state: &'static AppState) {
    loop {
        let req = CRYPTO_REQUESTS[task_id].wait().await;

        let ctx = signing_context(b"coin-toss-vrf");
        let transcript = ctx.bytes(req.input.as_bytes());
        let (inout, proof, _) = state.keypair.vrf_sign(transcript);

        let output = inout.to_preout().to_bytes();
        let proof = proof.to_bytes();

        CRYPTO_RESPONSES[task_id].signal(RandomnessResponse { output, proof });
    }
}

(src/web.rs, lines 135–149)

Alternative Solutions

There are a few other solutions to this very general problem. I'll list the ones I didn't pick:

ESP32 Real-Time Operating System (RTOS) preempts blocking computation the usual way and also provides utilities for time-sensitive work.
InterruptExecutor in Embassy is a task executor that uses hardware interrupts to preempt lower-priority executors.
Offloading computation to a dedicated peripheral while we .await.

Conclusion

I tested the fix by sending concurrent requests to the ESP32. Before, with everything on a single core, the network stack froze as soon as the cryptography started, and the board couldn't even accept incoming packets. Now it accepts exactly 4 requests concurrently, one per worker. The client receives the ACK for its request immediately, while the response takes as long as the cryptography needs. There's still latency whenever all the workers are busy, but the Wi-Fi no longer drops, so new requests can still come in and be served or rejected.

Each platform handles concurrency and parallelism differently. We're usually taught concurrency through OS threads, processes, preemptive scheduling, and synchronization primitives. However, it's important to understand the architecture running the code because the ideas carry over, but the tools don't.