CubeHash: a simple hash function

CubeHash hardware

Important questions to keep in mind when reading a CubeHash hardware implementation report:

• Does the report say that it takes advantage of the November 2010 CubeHash algorithms?
• Does the report show the flexibility of CubeHash in being implementable with not just 1 cycle per round but also 2 cycles per round, 4 cycles per round, 8 cycles per round, 16 cycles per round, and 32 cycles per round, with the area dropping accordingly? (Reports using 0.5 cycles per round should be disregarded; 0.5 cycles per round is an academic latency-minimization exercise, not a sensible choice for real-world applications.)
• Does the report say that it takes advantage of SRAM cells to save area? This is particularly important for CubeHash as the number of cycles per round increases.
• Does the report say exactly which ASIC library it is using? This is important because areas reported in "gate equivalents" (GE) are relative to the library size. An ASIC using a high-performance 130nm library will be faster than an ASIC using a standard-performance 130nm library, and will have about the same "GE" count, but will actually use considerably more area.
• Does the report include post-place-and-route figures? The following example illustrates the importance of place and route. A 2009.11.11 comparison report by Tillich et al. included only post-synthesis figures, such as 21229Mbps for Keccak in 56316 GE (UMC 180nm FSA0A_C), and stated "Place & route is expected to have only little impact on the performance figures estimated after synthesis." An updated 2010.08.04 comparison report by the same authors included post-place-and-route figures, such as only 11624Mbps for Keccak in 56713 GE (UMC 180nm FSA0A_C), and quietly removed the erroneous "little impact" statement.
• Did the authors provide all information necessary to verify the report? Would measurement errors and copy-and-paste errors be caught by third parties? Is the VHDL/Verilog code available online?

Even before the November 2010 algorithms, CubeHash was ranked very highly in SHA-3 hardware comparison reports. For example:

• CubeHash was ranked #1 among second-round SHA-3-256 candidates in a comparison by Guo, Huang, Nazhandali, and Schaumont of the FPGA area (Xilinx Virtex-5 XC5VLX330-2FF1760) required to hash at 200Mbps: 622 slices for CubeHash (at 84.36 mW), 740 slices for SHA-256 (at 73.47 mW), 788 slices for Skein-256 (at 88.65 mW), 930 slices for Hamsi-256 (at 86.53 mW), ..., 4790 slices for SIMD-256 (at 362.12 mW), 5935 slices for BMW-256 (at 321.89 mW).
• CubeHash was ranked #3 among second-round SHA-3-256 candidates in a comparison by the same authors of the ASIC area (130nm FSC0G_D_SC_TP_2006Q1v2.0) required to hash at 200Mbps: 23484 GEs for Hamsi-256 (at 2.77 mW), 26167 GEs for SHA-256 (at 2.20 mW), 29931 GEs for Skein-256 (at 4.41 mW), 34443 GEs for CubeHash (at 3.31 mW), ..., 113202 GEs for SIMD-256 (at 4.56 mW), 149858 GEs for BMW-256 (at 1.11 mW). This was a 1-cycle-per-round CubeHash implementation; a 16-cycle-per-round CubeHash implementation will achieve the same throughput in much smaller area, bringing CubeHash to #1.
• CubeHash was ranked #3 among second-round SHA-3-256 candidates in a multiple-FPGA comparison of throughput-to-area ratio by Homsirikamol, Rogawski, and Gaj. According to the report, Keccak, Luffa, and CubeHash are the only SHA-3-256 candidates that have been shown to provide consistently better throughput-to-area ratio than SHA-256 on Spartan 3, Virtex 4, Virtex 5, Cyclone II, Cyclone III, Stratix II, and Stratix III.
• CubeHash was ranked #2 among second-round SHA-3-512 candidates in the same comparison. The only SHA-3-512 candidates providing better overall throughput-to-area ratio than SHA-512 are Keccak (20% better on average) and CubeHash (10% better on average).

Version