Module memory_and_security 

Memory, traffic, and security

Memory hierarchy

The architecture distinguishes four kinds of storage:

Storage	Intended implementation	Contains
registers	FFs/local state	active limbs, points, counters, command context
local tables/schedules	BRAM or ROM logic	SHA constants, circular schedule, point candidates
message cache	BRAM	first 4096 message bytes
external memory	HBM/DDR through AXI mover	commands, source messages, results, counters

Arithmetic engines must not use HBM or DDR as scratch space. External traffic is observable at the kernel shell and should be counted independently from logical bytes consumed by SHA-512.

Compatibility scalar table

The generic scalar multiplier generates eight point multiples on demand. Each candidate is stored in a separate BRAM bank as forty 32-bit words. A lookup uses the same public word address on every bank and reads every candidate.

The recorded scalar-multiplication simulation performs 320 table writes and 20,480 logical candidate-word reads. Those counts are invariant across scalar values. They are local BRAM operations, not external DRAM/HBM transactions.

Fixed-base table

The current radix-16 fast-path assets contain:

32 windows * 8 magnitudes * 3 field elements * 255 bits
= 195,840 logical bits
= 24,480 bytes

The table is transposed into eight magnitude banks. Every lookup reads all eight banks at the same public window address. The signed digit controls a mux after the reads; it must never select a BRAM bank or read address.

Logical size and physical BRAM allocation are different. A 765-bit point word is much wider than a RAMB36 port, so banking/width fragmentation can consume many physical blocks. The measured radix-16 lookup OOC report uses 88 block-RAM tiles for 24,480 logical bytes.

Message traffic

For signing a message of N bytes with the 4 KiB cache:

logical external message reads = N + max(N - 4096, 0)

For verification:

logical external message reads = N

At the AXI boundary, additionally count:

• command records read;
• 512-bit message beats, including partial-line padding;
• result and counter records written;
• PCIe host/device transfers;
• mover retries or duplicated passes, if any.

Benchmark comparisons with AMD are fair only when both kernels use equivalent record layouts, bank mappings, movers, batch sizes, and timing boundaries.

Constant-pattern rules

Secret-dependent values include expanded scalar a, nonce scalar r, and any table digit derived from them. For those values:

• loop trip counts must be fixed;
• table addresses and enabled banks must be fixed;
• pipeline stalls must not depend on digit magnitude or sign;
• zero digits still execute the same point-operation schedule;
• errors must not expose partial secret state.

Functional constant time in Rust is insufficient. Verify emitted RTL address, enable, and valid traces for boundary and randomized scalars.

Key lifetime

Cold derivation/signing holds the seed and expanded key in registers while the operation runs. Cached-key mode intentionally retains only the expanded state needed for later signing. ClearKey must explicitly clear it. Operation completion should clear transient nonce/challenge state even if result backpressure delays result retirement.

Host buffers, driver logs, VCD files, and debug counters must never contain real production seeds. Tests use deterministic non-secret vectors.

Threat-model boundary

The design aims for fixed control and memory-access patterns for secret scalar work. It does not, by itself, prove resistance to power, EM, clock/voltage faults, placement leakage, or physical probing. Such claims require dedicated evaluation beyond functional RTL and timing closure.