Hardware Wrapper
We present a hardware wrapper interface which attempts to encompass all the competition entries (and indeed, hash algorithms in general) across any number of both FPGA and ASIC hardware platforms. This interface comprises communications and padding, and attempts to standardise the hashing algorithms to allow accurate and fair area, timing and power measurement between the different designs.
Our wrapper design is currently on version 2.
DIG = Digest length
CTW = Counter width
MBL = Maximum block length
SR = Shift register
Counter Unit
- Needed for all except: Keccak, Luffa, Cubehash, Shabal
- Groestl counts blocks, not message length
Padder
- Slight variations between each hash function
Core Components
- Multiplexer to select the type of padding (100....., 000...., CTR, etc) for the current 32-bit block
- 32, 32-bit shift registers (1 for each shift value)
- A multiplexer with the outputs of the 32 SRs as input. Choice is made based on the message lenth "mod 32"
Controller
Varies significantly based on the hash function
Typical FSM:
- Read data in
- Padding state
- Load to HF
- Read next block
- Wait for message digest
Padding Unit
Cubehash, Luffa, Shabal and Skein use this padder almost exactly
Keccak requires a more specialized design (not shown here)
Fugue uses this padder but also uses the "optional" mux input for a counter and there is no shift registers required.
All the others use this padder BUT also use the "optional" mux input for the counter value.
A paper presenting the details and communications for our first wrapper can be found here.
Source Code
The Wrapper is made up of four individual subsections:
- The Hash function Top level.
- The padding scheme required.
- The controller.
- The output.
The wrapper also includes a package file (Sub-Wrapper) which holds the bus width size, currently set to 32-bits.
We further subdivided the wrapper into individual files for each hash design (and digest size where necessary), as opposed to originally using an all encompassing wrapper and using generics to select the files required. We do this for a number of reasons.
- To alleviate the requirement for a user to have all designs completed in VHDL/Verilog prior to synthesis.
- To reduce long synthesis time.
