Operation Aegis

The Aegis Gateway guards a single number: the master secret $S$ . Every second, thousands of users knock on its door, and for each one the gateway must prove "I know $S$ " without ever saying what $S$ is.

Last week we learned that the gateway's chip was tampered with at the fab. Somewhere in the silicon, a listener is recording wires, every clock cycle, for every request. We can't recall the chip. We can only redesign the circuit that runs on it.

That's your job. Build a prover that stays correct, leaks nothing, and keeps up with the queue on a tight silicon budget.

The mission

For every incoming request $\mathrm{ID}_i$ , your circuit must output a Schnorr proof $(C_i,\ e_i,\ z_i)$ :

C_i = G^{\,r_i}, \qquad e_i = H(C_i, \mathrm{ID}_i), \qquad z_i = r_i + e_i\, S \pmod q

where $r_i$ is a fresh random nonce. Anyone holding the public key $Y = G^{S}$ can check the proof with $G^{z_i} = C_i \cdot Y^{e_i}$ , without learning $S$ .

The catch: $S$ lives inside a VAULT that never reveals it directly. You hand the vault a random mask $m$ , and it gives you back $V = S + m$ . Using $V$ , $m$ , $r$ and $e$ , you have to produce $z$ in a way that never exposes $S$ to the listener.

You build the circuit in the Playground by dragging hardware blocks onto a canvas and wiring them up. The server then simulates it cycle by cycle on hidden data. A design is judged on three things:

Correct: every proof verifies, and each one belongs to the request that asked for it.
Secure: nothing the listener records lets them solve for $S$ .
Efficient: small area, low latency and, in Part B, high throughput.

Conventions

Assume the standard Schnorr setting:

Scalars are integers mod a large prime $q$ .
$G^{x}$ is exponentiation in a prime-order group with public generator $G$ .
$H$ is a hash mapped into $\mathbb{Z}_q$ .

The exact constants are fixed by the evaluator and listed at the end of this page, but you never need them: the blocks handle the arithmetic for you. Time is measured in clock cycles, area in gate units G.

Your toolbox

Block	Does	Latency	Area
`TRNG`	fresh uniform random scalar	5	250 G
`VAULT`	$m \mapsto S + m$	1	100 G
`HASH_256`	$(C, \mathrm{ID}) \mapsto e$	3	150 G
`MOD_EXP`	$x \mapsto G^{x}$	10	400 G
`MUL` · `ADD` · `SUB`	$a\cdot b$ , $a + b$ , $a - b$ (mod $q$ )	2 · 1 · 1	100 · 20 · 20 G
`DELAY(d)`	the same value, $d$ cycles later	$d$	$5d$ G
`MUX` / `DEMUX` (Part B)	merge / split a stream across $n$ copies	1	$10n$ G
`PIPE` (Part B)	split `MOD_EXP`, `HASH`, `MUL` into $k$ stages	see block	+ per stage

The Playground shows each block's exact numbers when you select it.

How the hardware behaves

Values last one cycle. A block fires when all of its inputs arrive on the same cycle, and its result appears exactly latency cycles later. DELAY is the only memory.
Blocks are busy. A block can't accept new work until it has finished, so it must not see requests more often than its latency allows. Pipelining or multiple copies get around this.
Requests stay separate. Inputs from two different requests must never meet in one block.
Requests arrive at a fixed rate. A new $\mathrm{ID}$ arrives every $\mathrm{II}$ cycles (the initiation interval). A TRNG can fire before its request arrives (set its offset $\varphi$ ); MOD_EXP cannot start before the request.

What the listener sees

The listener records the outputs of MOD_EXP, HASH_256 and VAULT, the request IDs, your outputs $C, e, z$ , and anything computed purely from those. Everything that depends on a TRNG output is hidden from them, but hidden is not the same as safe. The audit fails your design if:

any wire, hidden or not, carries $S$ , or a multiple of $S$ , with no randomness left in it;
$S$ can be solved for from what the listener records, across many requests;
a random value is used for more than one request, or two random values are multiplied together.

The listener is good at algebra and patient. Think about what each shortcut gives them.

The two parts

	Part A	Part B
Blocks	the base set	base set + `MUX`, `DEMUX`, `PIPE`
Request rate	one every 10 cycles	you choose: one every 1–9 cycles
Must be secure?	no, but secure designs score far more	yes
You minimise	$A \cdot \Lambda$	$A^{1.5}\cdot \mathrm{II} \cdot \Lambda$

$A$ is total area, $\Lambda$ is the latency from a request's arrival to its last output, and $\mathrm{II}$ is the cycles between requests.

Scoring. Each result lands in a band. Your position inside the band depends on how close your cost is to the best known design:

Result	Points
Part A, correct but insecure	5 – 15
Part A, correct and secure	20 – 50
Part B, correct and secure	70 – 100

Your total is your better part. Only your best submission per part counts, and the leaderboard updates live as better designs appear.

Before you start

Get Part A working first, then make it secure, then make it small.
When something breaks, Run preview shows the cycle each input arrived at every block. Mismatched arrivals are the usual culprit.
Every shortcut that saves a block has a price. Make sure the price isn't the secret.

Reference constants

You don't need these to play. They're here for the curious.

$q = 2^{256} - 29237$ , $p = 2q + 1$ , and $G = 4$ generates the order- $q$ subgroup of $\mathbb{Z}_p^{*}$ .
$H(C, \mathrm{ID}) = \mathrm{SHA\text{-}256}(\texttt{"AEGIS-v2"} \Vert G \Vert Y \Vert C \Vert \mathrm{ID}) \bmod q$ , with $G, Y, C$ as 33-byte and $\mathrm{ID}$ as 8-byte big-endian integers.
The server simulates 200 requests with a fresh secret for every run; the browser preview simulates 40.