Microarchitecture Design and Benchmarking of Custom SHA-3 Instruction for RISC-V

Alperen Bolat; Henry Hui; Kieran McLaughlin; Sakir Sezer

REVIEW 3 major objections 5 minor 23 references

Microarchitecture Design and Benchmarking of Custom SHA-3 Instruction for RISC-V

T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A custom RISC-V instruction performing one Keccak-f round in hardware claims SHA-3 speedups of 8x to 46x with modest area overhead.

desk verdict A genuinely new SHA-3 round-instruction design with credible area cost, but the speedup numbers rest on a GEM5 timing model that is never disclosed. read the letter →

arxiv 2508.20653 v1 pith:IV62IFJV submitted 2025-08-28 cs.AR cs.CRcs.NI

Alperen Bolat , Sakir Sezer , Kieran McLaughlin , Henry Hui This is my paper · ORCID

classification cs.ARcs.CRcs.NI

keywords SHA-3Keccak-fRISC-VcustominstructionmicroarchitectureGEM5simulationFPGAprototypingcryptographicacceleration

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper proposes adding one custom instruction, named shatr, to the RISC-V ISA. Each execution of shatr performs a full Keccak-f permutation round in hardware using combinational logic and a dedicated 200-byte internal state buffer. In cycle-accurate GEM5 simulation, replacing the software Keccak round loop with 24 shatr executions cuts execution cycles by up to 8.02x for a RISC-V-optimized SHA-3 and 46.31x for the Keccak team's reference software. An FPGA prototype of the modified CV A6 core reports a 15.09% increase in flip-flops and an 11.51% increase in LUTs with no change to the 50 MHz clock rate. The paper's central claim is that SHA-3 acceleration belongs inside the CPU pipeline as an instruction, not only in coprocessors.

What carries the argument

The shatr instruction together with the Keccak-f Execution Unit: a custom RISC-V instruction whose execution-stage unit contains the combinational logic for one full Keccak-f round (theta, rho/pi, chi, iota) plus a 200-byte internal flip-flop buffer. Executing shatr 24 times completes a full permutation, and the internal buffer avoids repeatedly spilling the 1600-bit state to memory or general-purpose registers.

What would settle it

Instrument the GEM5 model to count cycles spent in shatr versus cycles spent moving state into and out of the 200-byte buffer, and rerun the two SHA-3 benchmarks with shatr priced at a realistic multicycle latency plus explicit state-transfer instructions. If the resulting speedups drop well below 8.02x and 46.31x, the headline gains are an artifact of free internal-buffer access.

Watch

Extended reading notes

Core claim

The central discovery is that the Keccak-f permutation, usually treated as a coprocessor or software workload, fits into an ordinary RISC-V pipeline as a custom instruction. The authors implement shatr so that one instruction completes one of the 24 Keccak-f rounds; the round's theta, rho-pi, chi, and iota logic is a combinational block, and a 200-byte register file inside the execution unit holds the state across rounds. Standard CPU instructions move data into and out of this internal buffer, so no new memory model is needed. Benchmarking two SHA-3 software distributions with NIST test vectors shows large cycle reductions, and the FPGA prototype shows the added logic costs less than a 16%

Load-bearing premise

The speedups rest on the simulator's assumed cost of the new instruction: the paper never states how many cycles a single shatr takes or how many cycles are spent moving the 200-byte state into and out of the internal buffer, and the authors wrote the GEM5 model themselves. If that transfer is expensive in a real pipeline, the measured speedups shrink.

Editorial extensions

If this is right

Software changes stay small: only the Keccak round loop is replaced by 24 shatr calls, so existing SHA-3 code ports with assembly-level edits rather than a rewrite.
The same instruction serves all SHA-3 output sizes (SHA-224/256/384/512), since they share the Keccak-f permutation; the paper's table shows gains across all eight configurations.
A processor with shatr keeps its clock rate unchanged in the FPGA prototype (50 MHz), so the added logic does not push the critical path on this implementation.
The design is portable beyond this prototype: the required toolchain changes span assembler, linker, compiler, and simulator, and the authors state the approach can be tailored to any CPU architecture.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The reported speedups are sensitive to baseline quality: the 46.31x figure comes from the Keccak reference implementation, which the paper describes as memory-heavy on RISC-V, so a real deployment should expect gains closer to the 8.02x of the RISC-V-optimized baseline.
The internal 200-byte buffer is not part of the architectural register file, so an operating system context switch would have to save and restore it; the paper's stability tests do not measure this cost.
The paper reports no per-instruction latency or pipeline occupancy for shatr, so if a real high-frequency core needs multiple cycles or extra state-transfer instructions, the headline speedups would shrink.
Because any sponge construction built on Keccak-f (for example cSHAKE or KangarooTwelve) invokes the same permutation, the instruction could accelerate those hashes at no extra hardware cost, though the paper benchmarks only the NIST SHA-3 variants.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Here's the short version. The paper is the first I know to put an entire Keccak-f round into a RISC-V datapath as a single instruction, with a dedicated 200-byte state buffer, and the CV A6 FPGA numbers make the area story credible: 15% more flip-flops, 11.5% more LUTs, same 50 MHz. That alone is worth a read for anyone thinking about crypto instruction sets.

What the paper does well: it modifies the RISC-V toolchain to accept shatr, validates hash outputs against NIST vectors, runs a RISC-V-optimized SHA-3 implementation and the Keccak reference implementation, and reports instruction-count breakdowns per round. The design goal — accelerate the permutation round, leave padding/squeezing alone — is sensible and honestly stated. The authors also acknowledge that the RISC-V-optimized baseline is the fairer comparison.

The soft spot is the one your note flagged, and it is load-bearing. The GEM5 speedups are computed from total cycle counts, but the paper never reports the shatr instruction's latency, whether it blocks the pipeline, or how the 200-byte state gets in and out. Section III says dedicated internal registers are managed by standard instructions, Section IV.B says no additional registers were applied into ISA or CPU. Those two sentences do not reconcile, and the transfer cost is exactly where the reported speedups could hide. If shatr is modeled as one cycle with zero-cost moves, the 46x number would be inflated. The FPGA result proves feasibility and area, not performance.

Two more minor points: the 46.31x is against the Keccak reference implementation that is not RISC-V-optimized; 8.02x against the RISC-V-optimized code is the representative headline. And the paper includes figures with no content in the version I read — instruction breakdown figures are referenced but not visible, so I could not check the details. Also, no artifacts are released; the whole timing model is a black box.

Bottom line: the microarchitecture idea is solid and the hardware cost data is real. The performance numbers need to be re-derived with a disclosed timing model. This is a paper for CPU architect readers, and it deserves a serious referee, but only after a major revision that reports the shatr timing and resolves the register ambiguity.

Referee Report

3 major / 5 minor

Summary. The paper proposes a custom RISC-V instruction named shatr that executes one round of the Keccak-f permutation as combinational logic in a dedicated execution unit, with a 200-byte internal state buffer. The authors evaluate the design in a custom cycle-accurate GEM5 RISC-V model against two SHA-3 software distributions and report speedups of up to 8.02x and 46.31x, plus an FPGA prototype on CV A6 showing a 15.09% flip-flop and 11.51% LUT increase. The central performance claim rests on the cycle count of shatr and the cost of moving state between the CPU datapath and the internal state buffer, neither of which is reported.

Significance. If the performance numbers are accurate, the paper addresses a relevant and under-explored topic: direct microarchitectural integration of SHA-3 as an ISA extension rather than as a coprocessor. The FPGA synthesis results (Table II) are concrete and give independent evidence that the hardware overhead is modest and the 50 MHz timing target is met. However, the paper does not provide enough information to reproduce or verify the simulation-based speedups. The missing timing model for the custom instruction is load-bearing, and the speedup values in Section V.A are not consistent with the cycle counts in Table I. As a result, the central contribution is currently not substantiated, although the issues are addressable with additional experimental detail.

major comments (3)

[Section III and IV.B] The GEM5 timing model for shatr is never described. The paper reports total execution cycles in Table I but does not state the instruction latency, pipeline occupancy (whether shatr is pipelined, multi-cycle, or blocking), or the cycle cost of transferring the 1600-bit state between the 200-byte internal registers and the standard RISC-V datapath. Section III says the internal registers are 'managed exclusively through standard CPU instructions', but standard RISC-V instructions cannot address a 200-byte internal file unless new addressing modes or memory-mapped access are defined. Since every cycle count in Table I depends on these undisclosed parameters, the headline 8.02x and 46.31x speedups are not reproducible and could be materially inflated if shatr is modeled as a single-cycle instruction with zero-cost state transfer.
[Section V.A, Table I] The claimed maximum speedups do not match the paper's own cycle data. From Table I, the RISC-V distribution speedup is about 8.62x for SHA-384 long input (1562.557e7/181.221e7), not 8.02x. For the Keccak distribution, the SHA-256 long input speedup is about 64.79x (31313.550e7/483.317e7), while the claimed maximum is 46.31x. Also, the phrase 'average improvements of up to' is ambiguous: it does not state whether the values are arithmetic means, geometric means, or maxima across configurations. The text and Table I must be reconciled, and the exact definition of the reported speedup must be given.
[Section III vs Section IV.B] There is an internal contradiction about additional registers. Section III introduces 200 bytes of dedicated internal flip-flops inside the execution unit to buffer the Keccak state. Section IV.B then states 'No additional registers, features or optimizations were applied into ISA or CPU' and says 'Customized vector-based registers are exclusively employed to connect the proposed shatr instruction with the combinational logic of the Keccak-f Execution Unit on GEM5.' If the internal registers are part of the execution unit and are not ISA-visible, the mechanism by which standard CPU instructions load and store the 200-byte state must be explained. If they are visible or accessed via some new mechanism, that contradicts the claim that no registers were added to the ISA. This ambiguity directly affects the measured cycle counts and must be resolved.

minor comments (5)

[Section I] The claim of being the 'first microarchitectural study of SHA-3 instruction integration directly into CPU datapath' is too strong given the cited prior work on ASIPs (Ref. [8]) and vector ISA extensions for Keccak (Ref. [13]). Please temper the novelty claim or provide a clearer comparison.
[Section III] The phrase 'this unit recursively operates on a 200-byte data chunk' is misleading; the unit implements one combinational Keccak round, not a recursive operation. Also, 'with vectorisation, parallel read/write capabilities are achieved' is unclear because the baseline RISC-V core has no vector ISA extension.
[Section II.A] The sentence 'it partially supports implementation as pure combinational logic' is vague. One round is combinational, and 24 rounds can be unrolled or iterated; please state precisely what is meant by 'partially'.
[Section IV.B] The GEM5 memory configuration is given as '8GB DDR3 with 1600 MT/s and 8 banks', but the CPU core model (in-order vs out-of-order, pipeline width, issue rate) is not described. This is needed to assess whether the baseline cycles are representative.
[Section V.A] The statement 'the integration of the custom instruction results in approximately 60% ALU instructions' is hard to interpret without the absolute instruction counts for the custom configuration. Also, Figures 4-6 are not referenced precisely in the text; please add explicit references.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the speedup claims are simulation/FPGA benchmark comparisons, not derivations that reduce to their inputs.

full rationale

The paper's central claims are empirical: cycle counts from GEM5 simulations of a RISC-V model with and without the custom shatr instruction, and FPGA area/timing measurements from a synthesized prototype. No fitted constant, benchmark-derived parameter, or target speedup is used as an input to the model in a way that forces the reported 8.02x/46.31x results. The custom GEM5 model is an implementation of the proposed instruction, not a parameter fit to the baseline data. The only author self-citation ([11]) appears in related-work context and is not load-bearing for the derivation. The FPGA prototype provides independent evidence of area feasibility and 50 MHz timing. The undisclosed latency/pipeline behavior of shatr in the GEM5 model is a reproducibility and modeling-concern, but that is a correctness/validation risk, not circularity: the paper does not define the speedup as a consequence of an assumed cycle count, nor does it rename a fitted quantity as a prediction. Under the review rules, the analysis is self-contained against external benchmarks and no circular step can be exhibited by quotation.

Assumptions & free parameters 1 free parameters · 4 assumptions · 3 invented entities

The evaluation rests on unstated modeling choices (shatr latency, state transfer) and on the assertion that only the permutation rounds were modified. The FPGA prototype supports feasibility, but the GEM5 speedup numbers depend on an undocumented internal model parameter.

free parameters (1)

shatr instruction latency (GEM5 model) = unreported (implicitly 1 cycle or a few cycles)
All cycle-count speedups in Table I and Figure 6 depend on this latency. The paper does not report the number of cycles the custom instruction occupies in the pipeline, nor the read/write cost of the 200-byte state.

assumptions (4)

domain assumption Keccak-f can be executed as one combinational round per instruction within one 50 MHz cycle on the target FPGA.
Section III and IV.C assert this and claim no critical path increase, but the GEM5 model applies similar timing without demonstrating it in the simulation.
domain assumption The GEM5 model faithfully reproduces the modified CPU including custom vector registers.
Section IV.B states the custom instruction is modeled in GEM5, but no validation of the model's timing accuracy is given beyond ISA compliance tests.
domain assumption Only the permutation rounds in the software were altered; the rest of the SHA-3 code is unchanged and identical in both runs.
Section IV.B states this, which is important for attributing speedups, but the exact assembly changes are not shown.
ad hoc to paper The internal 200-byte registers can be managed by standard CPU instructions with no extra custom instructions.
Section III says the internal registers are managed exclusively through standard CPU instructions, but standard RISC-V instructions cannot address an internal 200-byte register file; the transfer mechanism and its cycle cost are undefined.

invented entities (3)

shatr instruction
purpose: Executes one full Keccak-f round as a single custom instruction
Defined and modeled only within the paper; no opcode encoding or toolchain patch is released.
Keccak-f Execution Unit
purpose: Combinational logic block in the CPU execution stage that computes a Keccak round
Synthesized on FPGA in the paper, but no netlist or RTL is provided for independent verification.
200-byte internal state register file
purpose: Holds the 1600-bit Keccak state inside the execution unit between rounds
Its access mechanism is not specified; the paper claims it is managed via standard instructions without giving a concrete path.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Microarchitecture Design and Benchmarking of Custom SHA-3 Instruction for RISC-V." pith.science (2026). https://pith.science/paper/IV62IFJV

@misc{pith2026250820653,
  author       = {Pith},
  title        = {Pith review of: Microarchitecture Design and Benchmarking of Custom SHA-3 Instruction for RISC-V},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IV62IFJV}},
  note         = {Machine review of arXiv:2508.20653}
}

read the original abstract

Integrating cryptographic accelerators into modern CPU architectures presents unique microarchitectural challenges, particularly when extending instruction sets with complex and multistage operations. Hardware-assisted cryptographic instructions, such as Intel's AES-NI and ARM's custom instructions for encryption workloads, have demonstrated substantial performance improvements. However, efficient SHA-3 acceleration remains an open problem due to its distinct permutation-based structure and memory access patterns. Existing solutions primarily rely on standalone coprocessors or software optimizations, often avoiding the complexities of direct microarchitectural integration. This study investigates the architectural challenges of embedding a SHA-3 permutation operation as a custom instruction within a general-purpose processor, focusing on pipelined simultaneous execution, storage utilization, and hardware cost. In this paper, we investigated and prototyped a SHA-3 custom instruction for the RISC-V CPU architecture. Using cycle-accurate GEM5 simulations and FPGA prototyping, our results demonstrate performance improvements of up to 8.02x for RISC-V optimized SHA-3 software workloads and up to 46.31x for Keccak-specific software workloads, with only a 15.09% increase in registers and a 11.51% increase in LUT utilization. These findings provide critical insights into the feasibility and impact of SHA-3 acceleration at the microarchitectural level, highlighting practical design considerations for future cryptographic instruction set extensions.

Figures

Figures reproduced from arXiv: 2508.20653 by the authors.

**Figure 2.** Micro-Architectural Model By embedding this dedicated Keccak-f Execution Unit into the CPU execution stage, the processor can efficiently perform calculations required by Keccak-f rounds without resorting to multiple standard arithmetic and logical instructions. Consequently, this integration significantly reduces the total number of executed instructions necessary for SHA-3 computations, thereby enhancing overall … view at source ↗

**Figure 3.** Execution Flow of SHA-3 to principles of modularity and backward compatibility. Existing RISC-V applications remain unaffected, while a highperformance path is provided for cryptographic workloads. By embedding this custom instruction into the standard toolchain, the proposed architecture achieves scalability, maintainability, and ease of adoption for both legacy and new software ecosystems. This approach allows d… view at source ↗

Figures from the paper (2 more)

**Figure 4.** Figure 4: Comparison of Total Executed Instruction Counts [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]

**Figure 5.** Figure 5: Instruction Type Breakdown by Percentage: Custom [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

23 extracted references · 23 canonical work pages

[1]

Breakthrough aes performance with intel aes new instructions,

K. Akdemir, M. Dixon, W. Feghali, P. Fay, V . Gopal, J. Guilford, E. Ozturk, G. Wolrich, and R. Zohar, “Breakthrough aes performance with intel aes new instructions,” White paper, June, vol. 12, p. 217, 2010

work page 2010
[2]

Armv8-a cryptographic extension,

ARM, “Armv8-a cryptographic extension,” devel- oper.arm.com/documentation/100801/0401

work page
[3]

Lessons learned from designing a 65nm asic for evaluating third round sha-3 candidates,

F. K. G ¨urkaynak, K. Gaj, B. Muheim, E. Homsirikamol, C. Keller, M. Rogawski, H. Kaeslin, and J.-P. Kaps, “Lessons learned from designing a 65nm asic for evaluating third round sha-3 candidates,” in Third SHA-3 Candidate Conference , 2012, pp. 1–22

work page 2012
[4]

Sha2 and sha-3 accelerator design in a 7 nm technology within the european processor initiative,

P. Nannipieri, M. Bertolucci, L. Baldanzi, L. Crocetti, S. Di Matteo, F. Falaschi, L. Fanucci, and S. Saponara, “Sha2 and sha-3 accelerator design in a 7 nm technology within the european processor initiative,” Microprocessors and Microsystems, vol. 87, p. 103444, 2021

work page 2021
[5]

Prototyping platform for performance evaluation of sha-3 candidates,

K. Kobayashi, J. Ikegami, M. Kne ˇzevi´c, E. X. Guo, S. Matsuo, S. Huang, L. Nazhandali, ¨U. Kocabas ¸, J. Fan, A. Satohet al., “Prototyping platform for performance evaluation of sha-3 candidates,” in 2010 IEEE Interna- tional Symposium on Hardware-Oriented Security and Trust (HOST) . IEEE, 2010, pp. 60–63

work page 2010
[6]

Comparing hardware performance of round 3 sha-3 candidates using multiple hardware architectures in xilinx and altera fpgas,

E. Homsirikamol, M. Rogawski, and K. Gaj, “Comparing hardware performance of round 3 sha-3 candidates using multiple hardware architectures in xilinx and altera fpgas,” in Ecrypt II Hash Workshop , vol. 2011, 2011, pp. 1–15

work page 2011
[7]

A sha-3 co-processor for iot applications,

I. L. Azevedo, A. S. Nery, and A. d. C. Sena, “A sha-3 co-processor for iot applications,” in 2020 Workshop on Communication Networks and Power Systems (WCNPS). IEEE, 2020, pp. 1–5

work page 2020
[8]

Design exploration of sha-3 asip for iot on a 32-bit risc-v processor,

J. Rao, T. Ao, S. Xu, K. Dai, and X. Zou, “Design exploration of sha-3 asip for iot on a 32-bit risc-v processor,” IEICE TRANSACTIONS on Information and Systems , vol. 101, no. 11, pp. 2698–2705, 2018

work page 2018

Show all 23 references

[9]

Maximizing the potential of custom risc-v vector extensions for speeding up sha-3 hash functions,

H. Li, N. Mentens, and S. Picek, “Maximizing the potential of custom risc-v vector extensions for speeding up sha-3 hash functions,” in 2023 Design, Automation & Test in Europe Conference & Exhibition (DATE). IEEE, 2023, pp. 1–6

2023
[10]

Enhancing the hardware pipelining optimization technique of the sha-3 via fpga,

A. Sideris and M. Dasygenis, “Enhancing the hardware pipelining optimization technique of the sha-3 via fpga,” Computation, vol. 11, no. 8, p. 152, 2023

2023
[11]

Investigation of communication overhead of soc lookaside accelerators,

A. Bolat, F. Siddiqui, S. Sezer, K. Tasdemir, and R. Khan, “Investigation of communication overhead of soc lookaside accelerators,” in2023 IEEE 36th International System-on-Chip Conference (SOCC) . IEEE, 2023, pp. 1–6

2023
[12]

Implementation of the sha-3 family us- ing avx512 instructions,

R. Cabral and J. L ´opez, “Implementation of the sha-3 family us- ing avx512 instructions,” in Simp´osio Brasileiro de Seguranc ¸a da Informac ¸˜ao e de Sistemas Computacionais (SBSeg) . SBC, 2018, pp. 361–368

2018
[13]

Vector instruction set extensions for efficient computation of keccak,

H. Rawat and P. Schaumont, “Vector instruction set extensions for efficient computation of keccak,” IEEE Transactions on Computers , vol. 66, no. 10, pp. 1778–1789, 2017

2017
[14]

Fair and com- prehensive performance evaluation of 14 second round sha-3 asic im- plementations,

X. Guo, S. Huang, L. Nazhandali, and P. Schaumont, “Fair and com- prehensive performance evaluation of 14 second round sha-3 asic im- plementations,” in The Second SHA-3 Candidate Conference . Citeseer, 2010

2010
[15]

Fpga implementations of the round two sha-3 candidates,

B. Baldwin, A. Byrne, L. Lu, M. Hamilton, N. Hanley, M. O’Neill, and W. P. Marnane, “Fpga implementations of the round two sha-3 candidates,” in 2010 International Conference on Field Programmable Logic and Applications . IEEE, 2010, pp. 400–407

2010
[16]

High performance pipelined fpga implementation of the sha-3 hash algorithm,

L. Ioannou, H. E. Michail, and A. G. V oyiatzis, “High performance pipelined fpga implementation of the sha-3 hash algorithm,” in 2015 4th Mediterranean Conference on Embedded Computing (MECO) . IEEE, 2015, pp. 68–71

2015
[17]

Risc-v cryptography extensions standardisation work,

RISC-V Foundation, “Risc-v cryptography extensions standardisation work,” https://github.com/riscv/riscv-crypto
[18]

Keccakcodepackage,

Keccak Team, “Keccakcodepackage,” https://keccak.team/software.html
[19]

Cryptographic algorithm validation program: Secure hashing,

NIST, “Cryptographic algorithm validation program: Secure hashing,” csrc.nist.gov/projects/cryptographic-algorithm-validation-program
[20]

The cost of application-class processing: Energy and performance analysis of a linux-ready 1.7-ghz 64-bit risc- v core in 22-nm fdsoi technology,

F. Zaruba and L. Benini, “The cost of application-class processing: Energy and performance analysis of a linux-ready 1.7-ghz 64-bit risc- v core in 22-nm fdsoi technology,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 27, no. 11, pp. 2629–2640, 2019

2019
[21]

Risc-v tests,

RISC-V, “Risc-v tests,” github.com/riscv-software-src/riscv-tests
[22]

Mibench: A free, commercially represen- tative embedded benchmark suite,

M. R. Guthaus and R. et al., “Mibench: A free, commercially represen- tative embedded benchmark suite,” in Proc. of the fourth annual IEEE international workshop on workload characterization . IEEE, 2001

2001
[23]

Cva6 v5.3.0,

Openhwgroup, “Cva6 v5.3.0,” github.com/openhwgroup/cva6

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.

[1] [1]

Breakthrough aes performance with intel aes new instructions,

K. Akdemir, M. Dixon, W. Feghali, P. Fay, V . Gopal, J. Guilford, E. Ozturk, G. Wolrich, and R. Zohar, “Breakthrough aes performance with intel aes new instructions,” White paper, June, vol. 12, p. 217, 2010

work page 2010

[2] [2]

Armv8-a cryptographic extension,

ARM, “Armv8-a cryptographic extension,” devel- oper.arm.com/documentation/100801/0401

work page

[3] [3]

Lessons learned from designing a 65nm asic for evaluating third round sha-3 candidates,

F. K. G ¨urkaynak, K. Gaj, B. Muheim, E. Homsirikamol, C. Keller, M. Rogawski, H. Kaeslin, and J.-P. Kaps, “Lessons learned from designing a 65nm asic for evaluating third round sha-3 candidates,” in Third SHA-3 Candidate Conference , 2012, pp. 1–22

work page 2012

[4] [4]

Sha2 and sha-3 accelerator design in a 7 nm technology within the european processor initiative,

P. Nannipieri, M. Bertolucci, L. Baldanzi, L. Crocetti, S. Di Matteo, F. Falaschi, L. Fanucci, and S. Saponara, “Sha2 and sha-3 accelerator design in a 7 nm technology within the european processor initiative,” Microprocessors and Microsystems, vol. 87, p. 103444, 2021

work page 2021

[5] [5]

Prototyping platform for performance evaluation of sha-3 candidates,

K. Kobayashi, J. Ikegami, M. Kne ˇzevi´c, E. X. Guo, S. Matsuo, S. Huang, L. Nazhandali, ¨U. Kocabas ¸, J. Fan, A. Satohet al., “Prototyping platform for performance evaluation of sha-3 candidates,” in 2010 IEEE Interna- tional Symposium on Hardware-Oriented Security and Trust (HOST) . IEEE, 2010, pp. 60–63

work page 2010

[6] [6]

Comparing hardware performance of round 3 sha-3 candidates using multiple hardware architectures in xilinx and altera fpgas,

E. Homsirikamol, M. Rogawski, and K. Gaj, “Comparing hardware performance of round 3 sha-3 candidates using multiple hardware architectures in xilinx and altera fpgas,” in Ecrypt II Hash Workshop , vol. 2011, 2011, pp. 1–15

work page 2011

[7] [7]

A sha-3 co-processor for iot applications,

I. L. Azevedo, A. S. Nery, and A. d. C. Sena, “A sha-3 co-processor for iot applications,” in 2020 Workshop on Communication Networks and Power Systems (WCNPS). IEEE, 2020, pp. 1–5

work page 2020

[8] [8]

Design exploration of sha-3 asip for iot on a 32-bit risc-v processor,

J. Rao, T. Ao, S. Xu, K. Dai, and X. Zou, “Design exploration of sha-3 asip for iot on a 32-bit risc-v processor,” IEICE TRANSACTIONS on Information and Systems , vol. 101, no. 11, pp. 2698–2705, 2018

work page 2018