Module chain_lane

Expand description

The chain hash: Haraka-512, BLAKE3 or SHA-512, chosen at compile time.

§Why there is a choice

The chain hash decides most of the signer’s area (see the table below), so the crate can be built with any of three DSig-compatible chain hashes and each build measured on its own. Haraka-512 is made of AES rounds, which map well to FPGA tables. This module is the single switch: it names the lane type (ChainLane), its latency (LANE_LATENCY), the software reference (software_chain) and the profile name (PROFILE) for the hash picked by the DSIG_CHAIN build variable (build.rs). Nothing else in the crate needs to know which hash was chosen.

A W-OTS+ chain step hashes one 64-byte chain block (dsig_chain_block: a salted 16-byte nonce, the 18-byte node, zeros) and keeps 18 bytes. That is 204 of the ~251 hash calls in a signature, so the chain hash decides most of the area. The three DSig-compatible choices:

Build variable	Profile	Chain step	Lane hardware	Latency
`DSIG_CHAIN=haraka` (default)	`DSIG_FPGA_W4_HARAKA_BLAKE3_V1`	`Haraka-512(block)` truncated, mid bytes	`TableChainStepLane`, 494 S-boxes	20
`DSIG_CHAIN=blake3`	`DSIG_FPGA_W4_BLAKE3CHAIN_BLAKE3_V1`	`BLAKE3(block)[..18]` (one compression)	`Blake3ChainLane`	28
`DSIG_CHAIN=sha512`	`DSIG_FPGA_W4_SHA512CHAIN_BLAKE3_V1`	`SHA-512(block)[..18]` (one padded block)	`Sha512ChainLane`	82

Everything else (seeds, XOF, commitment, Merkle, message digest) stays BLAKE3 in every profile. Each profile is a different signature scheme: signatures from one never verify under another, and PROFILE names the one compiled in.

Every lane has the same ports as the Haraka lane (ChainStepInput → ChainStepOutput) and publishes its latency as LANE_LATENCY, which the chain engine and the factory’s timetable use.

§How the choice spreads through the slice

  chain-* feature ─▶ ChainLane, LANE_LATENCY
       │                 │
       │                 ▼
       │     slice_chain: SLICE_CHAIN_LATENCY = 3 × LANE_LATENCY
       │                 │
       │                 ▼
       │     slice_factory: END_DELAY = SLICE_CHAIN_LATENCY + 2
       │                 ├─▶ SCHEDULE (where commitment ops can go)
       │                 ├─▶ PACK_HISTORY (older pk_nonces kept)
       └───────────────▶ └─▶ CTX_BITS (5 with DSIG_CHAIN=sha512, else 4)

With SHA-512 the chain ends of a key emerge about three key periods after its chains start. By then newer keys are feeding the engine, which is why the factory keeps older pk_nonces and needs 32 key contexts instead of 16 (see crate::slice_factory::PACK_HISTORY and crate::slice_factory::CTX_BITS).

Structs§

Blake3ChainLane: A chain step as one BLAKE3 compression: the standard single-block hash of the 64-byte chain block (CHUNK_START | CHUNK_END | ROOT, counter 0), truncated to 18 bytes. One step per clock, PIPELINE_STAGES cycles.
Sha512ChainLane: A chain step as one SHA-512 block on the shared pipelined core ([rhdl_sha512_pipelined]), truncated to 18 bytes. One step per clock, [SHA_LATENCY] cycles. The 32-bit chain tag rides a parallel delay line because the core’s tag is 16 bits.

Constants§

LANE_LATENCY: Cycles from a lane’s input to its output.
PROFILE: The compiled-in DSig profile.

Functions§

blake3_chain_lane_kernel: Build the block, compress, keep the first 18 output bytes.
le_words_kernel: Little-endian words of a 64-byte block.
sha512_block_kernel: The single padded SHA-512 block of a 64-byte message, big-endian words: the message, 0x80, zeros, and the 128-bit length 512.
sha512_chain_lane_kernel: Build and pad the block, hash, keep the first 18 digest bytes.
software_chain: Software chain step for the compiled-in profile (the reference).

Type Aliases§

ChainLane: The lane type the chain engine instantiates three times per slice.