Pith. sign in

REVIEW 5 major objections 6 minor 2 cited by

Toward a Lightweight, Scalable, and Parallel Secure Encryption Engine

T0 review · 5 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read SPiME embeds AES-128 into FPGA memory-side units, scaling to 4,096 parallel encryptors.

desk verdict The paper's central scalability and throughput claims don't survive contact with its own equations or with the physical limits of the FPGAs it targets; the architecture idea is reasonable, but the evidence presented is not. read the letter →

arxiv 2506.15070 v1 pith:EYYWKNCF submitted 2025-06-18 cs.CR cs.ET

Rasha Karakchi , Rye Stahle-Smith , Nishant Chinnasami , Tiffany Yu This is my paper · ORCID
classification cs.CRcs.ET
keywords FPGAAES-128Processing-in-MemoryEncryptionEdgeComputingParallelArchitectureScalabilityVerilog
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 introduces SPiME, an FPGA-based architecture that places a full AES-128 encryption core and a small controller inside each processing-in-memory (PiM) unit, so data can be encrypted in place near memory instead of being moved to a CPU. The authors argue that this modular arrangement removes the throughput bottleneck of conventional CPU-centric encryption while keeping per-unit overhead low enough to scale. They report instantiating 256 to 4,096 parallel PiM units on AMD UltraScale and UltraScale+ FPGAs, with LUT utilization below 5% on large devices at the largest configuration and throughput above 25 Gbps in optimal settings. The design's fixed 11-cycle per-block latency gives predictable, low-latency encryption that would fit latency-sensitive edge and IoT workloads.

What carries the argument

The load-bearing mechanism is the PiM unit: a pipelined AES-128 datapath plus a small pim_controller state machine, replicated as an array under a parameterized NUM_PiMs. The controller handles start/done handshaking and routes plaintext, key, and round keys; the AES core sequences through IDLE, INIT, ROUND, and FINAL states, applying SubBytes, ShiftRows, MixColumns, and AddRoundKey with the Rijndael key schedule. This fixed 11-cycle FSM gives each unit constant latency, so array throughput is obtained by parallel replication rather than by deeper pipelining.

What would settle it

Synthesize the 4,096-PiM configuration on the U55C device with the full AES datapath (SubBytes S-boxes, ShiftRows, MixColumns) present in every unit and read the post-implementation LUT utilization; at under 5% of 1.3 million LUTs the budget is roughly 16 LUTs per AES core, which a complete S-box-based datapath cannot meet, so checking whether that report is produced would settle the scalability claim.

Watch

Extended reading notes

Core claim

The central claim is that a parameterized array of lightweight PiM units, each containing an AES-128 core (SubBytes, ShiftRows, MixColumns) and a minimal FSM controller, can provide scalable, in-place AES encryption on standard FPGAs without custom memory technology. Each unit runs a fixed 11-cycle encryption sequence, and the top-level NUM_PiMs parameter tiles these units across the FPGA; the paper reports that 4,096 units fit in under 5% of the logic on large UltraScale devices and that throughput scales nearly linearly with unit count and block size, exceeding 25 Gbps in batched configurations. The authors position SPiME as the first FPGA-compatible, parameterizable PiM-based AES core, in contrast to prior PiM-AES work that relied on custom DRAM or spintronic memory.

Load-bearing premise

The load-bearing premise is that the 4,096-unit synthesis reports include a complete AES-128 datapath in every PiM unit, since without that the sub-5% LUT utilization would not apply to a functional encryption core.

Editorial extensions

If this is right

  • Encryption throughput becomes a linear function of the number of units and the block size, so a designer can budget bandwidth by choosing NUM_PiMs.
  • The fixed 11-cycle latency makes SPiME's completion time deterministic, which suits real-time edge systems that need worst-case timing guarantees.
  • Because the design is plain Verilog with no custom memory technology, the same source can be retargeted across different FPGA families by changing the device part.
  • Batch and buffered workloads benefit most, since larger blocks amortize control and I/O overhead in the throughput model.
  • The architecture provides a foundation for secure PiM platforms where encryption happens close to the data it protects.

Reading between the lines

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

  • Beyond the paper, the controller/AES split suggests other ciphers could be dropped into the same PiM template, since the handshaking and data routing are cipher-agnostic.
  • Beyond the paper, the reported per-unit efficiency implies the array could also be used as a coarse-grained cryptographic accelerator for independent blocks, which would fit counter-mode encryption naturally; the authors do not discuss modes of operation.
  • Beyond the paper, the 11-cycle deterministic latency could be exploited by scheduling encryption in fixed time slots on a shared memory bus, turning latency variability into a compile-time constant.
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.

Referee Report

5 major / 6 minor

Summary. The paper presents SPiME, an FPGA-based architecture that arrays Processing-in-Memory (PiM) units, each comprising an AES-128 core and a lightweight controller. The design is parameterized by NUM_PIMs, and the paper claims it scales to 4,096 units while consuming less than 5% of key FPGA resources on high-end devices, with throughput exceeding 25 Gbps and deterministic latency. The paper describes the modules, provides latency and throughput formulas, and reports resource-utilization statistics for five FPGA platforms.

Significance. A scalable, configurable AES engine with a per-unit overhead of a few LUTs would be a valuable building block for secure processing-in-memory at the edge, and the claimed portability across FPGA families is appealing. The paper also has useful strengths: the modular Verilog organization, the parameterized instantiation, and the explicit goal of providing predictable, constant-time latency. However, the quantitative claims are not supported by the evidence in the manuscript: the reported utilization contradicts the standard resource cost of AES-128, the throughput and latency equations contain unit errors, and no hardware measurements are provided. Because the central scalability and performance assertions rest on these unsupported figures, the contribution cannot currently be assessed as valid.

major comments (5)
  1. [Section IV.B, Figure 3, Table I] For 4096 PIMs on the U55C (1,304K LUTs), the reported LUT utilization of 3.65% corresponds to about 47,600 LUTs, or roughly 11.6 LUTs per PIM. A full AES-128 core with SubBytes, ShiftRows, MixColumns, key expansion, and a controller cannot be implemented in that budget; even a single 8-bit S-box typically requires dozens of LUTs or a BRAM, and 16 S-boxes per core would need on the order of 32 Kbit per unit, totaling approximately 128 Mbit for 4096 units, which exceeds the U55C's ~72 Mbit of BRAM. The sub-5% utilization claim is therefore physically implausible for the described architecture and needs a detailed synthesis report to be credible.
  2. [Section IV.C, Eq. (1)] The latency formula Latency (µs) = 1000 × (Cycles/fmax) is dimensionally incorrect. If fmax is in Hz, the conversion to microseconds is a factor of 1e6, not 1000; if fmax is in MHz, the factor 1000 is extraneous. The reported example (0.11 µs at 100 MHz for 11 cycles) corresponds to Cycles/fmax without the factor, so the printed equation contradicts the numbers used in the text.
  3. [Section IV.D, Eq. (2)] The throughput equation Throughput (Gbps) = (Block size / Latency (µs)) ÷ 1e6 is off by a factor of 1000: bits per microsecond must be divided by 1000 to obtain Gbps (since 1 Gbps = 1000 bits/µs), not by 1e6. Using the values implied by the text (4096 PIMs, 128-bit blocks, 0.022 µs latency), the correct throughput is about 23,800 Gbps, not 23 Gbps; the reported 23 Gbps arises only from the erroneous factor. This reveals an internal inconsistency between the architecture description and the claimed results.
  4. [Section IV vs. Section V] Section IV states that designs were "synthesized and tested" on AMD UltraScale and UltraScale+ FPGAs, yet Section V lists "real hardware benchmarking" as future work. No tool versions, synthesis reports, timing constraints, or measurement methodology are provided. Given the implausible resource numbers, the absence of any reproducible synthesis or hardware data leaves the central scalability and throughput claims unverified.
  5. [Section III.D and Figure 6] The 'block size' used in the throughput evaluation is ambiguous. The AES core processes a single 128-bit block per operation, but Figure 6 is described as using a fixed block size of 1024 bits. If block size is per PIM, the total throughput should scale with NUM_PIMs in a way that is not reflected in the equation; if it is total across all PIMs, the text and the equation are inconsistent. The relationship between block size, NUM_PIMs, and latency needs to be defined unambiguously.
minor comments (6)
  1. [Throughout] SPiME is spelled inconsistently as 'SPiMe' in the Abstract, Section IV, and the Conclusion; use a single consistent spelling throughout.
  2. [Section III, Section IV.A] There are several typos, including 'followning' in Section III and 'Evaluational' in Section IV; the manuscript should be proofread.
  3. [Section IV.C] Equations (1) and (2) are referenced by number but not explicitly numbered in the displayed text; add equation numbers.
  4. [Figures 1 and 2] The figures are not included in the manuscript text, and their captions are too brief to convey the block-level structure; the architecture description would benefit from complete figures with labeled components.
  5. [Section III.C] The AES core is described as 'pipelined,' but the FSM-based round loop described in Algorithm 2 is a sequential datapath; clarify whether the intent is round-level pipelining, block-level pipelining, or neither.
  6. [Section V] The claim that SPiME is "the first FPGA-compatible, parameterizable PiM-based encryption core" is not substantiated by the related-work survey; a comparison table with prior AES/PiM implementations would be more appropriate.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity found; throughput figures are definitional arithmetic and resource claims are unverified but not circular.

full rationale

SPiME's derivation chain is not circular. The AES core is a standard FSM implementation of AES-128, latency is defined by the 11-cycle sequence divided by an assumed clock frequency (Eq. 1), and throughput is the standard ratio of block size to latency (Eq. 2). These are definitions used for projection, not fitted parameters or predictions derived from the same data. The reported 25 Gbps is an arithmetic consequence of assumed 500 MHz, a 1024-bit block, and an 11-cycle latency; this is a weak empirical anchor but not a circular reduction. The resource-utilization claims (e.g., 3.65% LUTs at 4096 PiMs) are said to come from synthesis, and while physically implausible, they are reported measurements rather than constructs derived from the architecture's definition. Self-citations [2]-[7] concern PiM and automata overlays and are not load-bearing for the AES or scalability claims. No uniqueness theorem or ansatz is imported from the authors' prior work. Thus no circular step meeting the evidence bar is present.

Assumptions & free parameters 3 free parameters · 3 assumptions · 0 invented entities

The claims rest on the unstated assumption that the synthesized netlist includes full AES cores and that the reported frequency and block size are the ones used to compute throughput. No code or raw data is provided to check either of these, and the internal arithmetic does not support the headline numbers.

free parameters (3)
  • NUM_PIMs = 4096 (max)
    Number of parallel encryption units; the claimed throughput scales linearly with it and is reported at 4096 units.
  • Block size = 1024 bits (Figure 6) and larger in Figure 7
    Chosen data block size used in the throughput calculation; larger block sizes are reported to increase throughput by amortizing control overhead.
  • Fmax = 500 MHz
    Operating frequency at which a latency of 0.022 microseconds and high throughput are reported; the paper does not provide critical-path details or routing data to justify this frequency for the full array.
assumptions (3)
  • domain assumption AES-128 (Rijndael) algorithm is correct and the Verilog implementation matches the standard.
    The paper relies on prior AES designs [14-27] without providing formal verification or test vectors.
  • domain assumption FPGA synthesis and implementation reports for resource utilization accurately reflect the full SPiME design including AES cores.
    The paper does not provide raw reports or scripts; the reported utilization numbers are taken at face value.
  • ad hoc to paper The latency and throughput equations (Eq. 1 and Eq. 2) are dimensionally correct and apply to the architecture.
    Equation 2 mixes bits, microseconds, and Gbps in a way that does not produce the stated 25 Gbps from the stated inputs, so the calculation is not a reliable predictive tool.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Toward a Lightweight, Scalable, and Parallel Secure Encryption Engine." pith.science (2026). https://pith.science/paper/EYYWKNCF

@misc{pith2026250615070,
  author       = {Pith},
  title        = {Pith review of: Toward a Lightweight, Scalable, and Parallel Secure Encryption Engine},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EYYWKNCF}},
  note         = {Machine review of arXiv:2506.15070}
}
read the original abstract

The exponential growth of Internet of Things (IoT) applications has intensified the demand for efficient, high-throughput, and energy-efficient data processing at the edge. Conventional CPU-centric encryption methods suffer from performance bottlenecks and excessive data movement, especially in latency-sensitive and resource-constrained environments. In this paper, we present SPiME, a lightweight, scalable, and FPGA-compatible Secure Processor-in-Memory Encryption architecture that integrates the Advanced Encryption Standard (AES-128) directly into a Processing-in-Memory (PiM) framework. SPiME is designed as a modular array of parallel PiM units, each combining an AES core with a minimal control unit to enable distributed in-place encryption with minimal overhead. The architecture is fully implemented in Verilog and tested on multiple AMD UltraScale and UltraScale+ FPGAs. Evaluation results show that SPiME can scale beyond 4,000 parallel units while maintaining less than 5\% utilization of key FPGA resources on high-end devices. It delivers over 25~Gbps in sustained encryption throughput with predictable, low-latency performance. The design's portability, configurability, and resource efficiency make it a compelling solution for secure edge computing, embedded cryptographic systems, and customizable hardware accelerators.

Figures

Figures reproduced from arXiv: 2506.15070 by the authors.

Figure 1
Figure 1. Proposed SPiME System. III. DESIGN AND ARCHITECTURES Our proposed architecture SPiME (Secure Processor in Memory Encryption) is designed as an array of parallel multiple processor-in-memory (PiM) units where each PiM comprises a PiM controller and an AES core. The design is fully described in Verilog and features a modular organization that promotes scalability, reusability, and clarity [PITH_FULL_IMAGE:figures/ful… view at source ↗
Figure 3
Figure 3. The LUTs utilization percentage versus number of [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. The register utilization percentage versus number of [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figures from the paper (3 more)
Figure 7
Figure 7. Figure 7: Throughput varies based on the block size while [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]
Figure 5
Figure 5. Figure 5: SPiME latency varies based on the Fmax while same [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Throughput of 1024 block size with the NUM [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. ML-Enhanced AES Anomaly Detection for Real-Time Embedded Security

    cs.CR 2025-07 reject novelty 4.0 of 10

    A Random Forest trained on timing and ciphertext features can detect self-injected timing and bit-flip anomalies in AES-128 better than a timing threshold, on CPU and PYNQ-Z1.

  2. Hybrid Cryptographic Monitoring System for Side-Channel Attack Detection on PYNQ SoCs

    cs.CR 2025-08 reject novelty 3.0 of 10

    A dual detection scheme combining a timing threshold and a Random Forest classifier is proposed to detect simulated AES anomalies, but the paper gives no quantitative results and its features leak the injected anomalies.

Reference graph

Works this paper leans on

34 extracted references · 31 canonical work pages · cited by 2 Pith papers

  1. [14]

    Very compact fpga implementation of the aes algorithm

    Paweł Chodowiec and Kris Gaj. Very compact fpga implementation of the aes algorithm. In International workshop on cryptographic hardware and embedded systems , pages 319–333. Springer, 2003

    work page 2003

  2. [27]

    Im- plementation of aes algorithm on fpga and on software

    Joseph Sunil, HS Suhas, BK Sumanth, and S Santhameena. Im- plementation of aes algorithm on fpga and on software. In 2020 IEEE International Conference for Innovation in Technology (INOCON), pages 1–4. IEEE, 2020

    work page 2020

  3. [1]

    A processing-in-memory architec- ture programming paradigm for wireless internet-of-things applications

    Xu Yang, Yumin Hou, and Hu He. A processing-in-memory architec- ture programming paradigm for wireless internet-of-things applications. Sensors, 19(1):140, 2019

    work page 2019

  4. [2]

    Rasha Karakchi and Jason D. Bakos. Napoly: A non-deterministic automata processor overlay. ACM Transactions on Reconfigurable Technology and Systems, 16:1–25, 2023

    2023

  5. [3]

    Richards, and Jason D

    Rasha Karakchi, Lothrop O. Richards, and Jason D. Bakos. A dynami- cally reconfigurable automata processor overlay. In 2017 International Conference on ReConFigurable Computing and FPGAs (ReConFig) , pages 1–8, 2017

    work page 2017

  6. [4]

    An overlay architec- ture for pattern matching

    Rasha Karakchi, Charles Daniels, and Jason Bakos. An overlay architec- ture for pattern matching. In 2019 IEEE 30th International Conference on Application-specific Systems, Architectures and Processors (ASAP) , volume 2160-052X, pages 165–172, 2019

    work page 2019

  7. [5]

    Optimizing sequence align- ment with scored nfas

    Ryan Karbowniczak and Rasha Karakchi. Optimizing sequence align- ment with scored nfas. arXiv preprint arXiv:2501.02162 , 2025

    arXiv 2025

  8. [6]

    Bradshaw, and Jason D

    Rasha Karakchi, Jordan A. Bradshaw, and Jason D. Bakos. High-level synthesis of a genomic database search engine. In 2016 International Conference on ReConFigurable Computing and FPGAs (ReConFig) , pages 1–6, 2016

    work page 2016

Show all 34 references
  1. [7]

    Developing a self-explanatory transformer

    Rasha Karakchi and Ryan Karbowniczak. Developing a self-explanatory transformer. In 2024 IEEE/ACM Symposium on Edge Computing (SEC), pages 523–525. IEEE, 2024

    2024

  2. [8]

    A fully pipelined memoryless 17.8 gbps aes-128 encryptor

    Kimmo J ¨arvinen, Matti Tommiska, and Jouni Skytt ¨a. A fully pipelined memoryless 17.8 gbps aes-128 encryptor. In Field Programmable Logic and Applications (FPL) , pages 147–152. IEEE, 2008

    2008

  3. [9]

    A processing-in-memory aes implementation in dram for secure and efficient data encryption

    Lei Xu, Hao Wang, and Yong Chen. A processing-in-memory aes implementation in dram for secure and efficient data encryption. IEEE Transactions on Computers, 2023. Early Access

    2023

  4. [10]

    An energy-efficient aes implementation using approximate logic synthesis

    Jun Zhang, Yu Liu, and Jie Han. An energy-efficient aes implementation using approximate logic synthesis. Integration, the VLSI Journal, 75:85– 94, 2021

    2021

  5. [11]

    A compact fpga-based architecture for aes encryption

    Robert McEvoy, Conor Murphy, M ´aire McLoone, and William Marnane. A compact fpga-based architecture for aes encryption. IEEE Transac- tions on Very Large Scale Integration (VLSI) Systems , 14(7):693–701, 2006

    2006

  6. [12]

    High-performance aes-gcm design for 5g security on fpga

    Qiang Wang, Li Zhang, and Yifan Zhao. High-performance aes-gcm design for 5g security on fpga. ACM Transactions on Embedded Computing Systems (TECS) , 20(5s):1–18, 2021

    2021

  7. [13]

    Securing encryption algorithms against dpa at the logic level: Next generation smart card technology

    Kris Tiri and Ingrid Verbauwhede. Securing encryption algorithms against dpa at the logic level: Next generation smart card technology. In Cryptographic Hardware and Embedded Systems (CHES) . Springer, 2003

    2003

  8. [15]

    Fpga implementation of aes encryption and decryption

    Ashwini M Deshpande, Mangesh S Deshpande, and Devendra N Kay- atanavar. Fpga implementation of aes encryption and decryption. In 2009 international conference on control, automation, communication and energy conservation , pages 1–6. IEEE, 2009

    2009

  9. [16]

    Fpga implementation of aes algorithm for high speed applications

    S Sridevi Sathya Priya, P Karthigaikumar, and Narayana Ravi Teja. Fpga implementation of aes algorithm for high speed applications. Analog integrated circuits and signal processing , pages 1–11, 2022

    2022

  10. [17]

    Exploring area/delay tradeoffs in an aes fpga implementation

    Joseph Zambreno, David Nguyen, and Alok Choudhary. Exploring area/delay tradeoffs in an aes fpga implementation. In International Conference on Field Programmable Logic and Applications, pages 575–

  11. [18]

    Asic implementation of the aes rijndael algorithm

    Piotr Chodowiec and Krzysztof Gaj. Asic implementation of the aes rijndael algorithm. In International Conference on Field Programmable Logic and Applications , pages 160–171. Springer, 2002

    2002

  12. [19]

    Aes on fpga from the fastest to the smallest

    Tim Good and Mohammed Benaissa. Aes on fpga from the fastest to the smallest. In Cryptographic Hardware and Embedded Systems– CHES 2005: 7th International Workshop, Edinburgh, UK, August 29– September 1, 2005. Proceedings 7 , pages 427–440. Springer, 2005

    2005

  13. [20]

    An efficient aes implementation using fpga with enhanced security features

    Harshali Zodpe and Ashok Sapkal. An efficient aes implementation using fpga with enhanced security features. Journal of King Saud University-Engineering Sciences, 32(2):115–122, 2020

    2020

  14. [21]

    A survey on performance analysis of different architectures of aes algorithm on fpga

    Taniya Hasija, Amanpreet Kaur, KR Ramkumar, Shagun Sharma, Sudesh Mittal, and Bhupendra Singh. A survey on performance analysis of different architectures of aes algorithm on fpga. Modern Electronics Devices and Communication Systems: Select Proceedings of MEDCOM 2021, pages 3...

    2021

  15. [22]

    Efficient implementation of aes algorithm on fpga

    Hrushikesh S Deshpande, Kailash J Karande, and Altaaf O Mulani. Efficient implementation of aes algorithm on fpga. In 2014 International Conference on Communication and Signal Processing , pages 1895–

    2014

  16. [23]

    Fpga imple- mentation of aes algorithm

    Atul M Borkar, RV Kshirsagar, and MV Vyawahare. Fpga imple- mentation of aes algorithm. In 2011 3rd International Conference on Electronics Computer Technology , volume 3, pages 401–405. IEEE, 2011

    2011

  17. [24]

    Comparative analysis of different aes implementation techniques for efficient resource usage and better performance of an fpga

    Umer Farooq and M Faisal Aslam. Comparative analysis of different aes implementation techniques for efficient resource usage and better performance of an fpga. Journal of King Saud University-Computer and Information Sciences , 29(3):295–302, 2017

    2017

  18. [25]

    Optimization and implementation of aes algorithm based on fpga

    Xiwei Zhang, Meng Li, and Jing Hu. Optimization and implementation of aes algorithm based on fpga. In 2018 IEEE 4th International Conference on Computer and Communications (ICCC) , pages 2704–

    2018

  19. [26]

    Area optimized implementation of aes algorithm on fpga

    Hrushikesh S Deshpande, Kailash J Karande, and Altaaf O Mulani. Area optimized implementation of aes algorithm on fpga. In 2015 International Conference on Communications and Signal Processing (ICCSP), pages 0010–0014. IEEE, 2015

    2015

  20. [28]

    A compact Rijndael hardware architecture with S-box optimization

    Atsushi Satoh, Shuji Morioka, Kohji Takano, and Sumio Munetoh. A compact Rijndael hardware architecture with S-box optimization. In Advances in Cryptology—ASIACRYPT 2001 , pages 239–254. Springer, 2001

    2001

  21. [29]

    A parallel aes architecture for high-speed network security

    Xiaohui He, Bin Li, and Yong Zhang. A parallel aes architecture for high-speed network security. IEEE Access, 8:21725–21735, 2020

    2020

  22. [30]

    Reconfigurable memory based aes co-processor

    Ricardo Chaves, Georgi Kuzmanov, Stamatis Vassiliadis, and Leonel Sousa. Reconfigurable memory based aes co-processor. In Proceedings 20th IEEE International Parallel & Distributed Processing Symposium , pages 8–pp. IEEE, 2006

    2006

  23. [31]

    Power attack-immune spintronic-based aes hardware accelerator for secure and high-performance pim architectures

    Pegah Iranfar, Abdolah Amirany, and Mohammad Hossein Moaiyeri. Power attack-immune spintronic-based aes hardware accelerator for secure and high-performance pim architectures. IEEE Transactions on Magnetics, 61(4):1–12, 2025

    2025

  24. [32]

    Enabling PIM-based AES encryption for online video streaming

    Yiding Liu, Guangyu Huang, Yuwei Zhang, Xuehai Wang, and Yu Wang. Enabling PIM-based AES encryption for online video streaming. Jour- nal of Systems Architecture , 132:102734, 2022

    2022

  25. [33]

    Processor accelerator for aes

    Ruby B Lee and Yu-Yuan Chen. Processor accelerator for aes. In 2010 IEEE 8th Symposium on Application Specific Processors (SASP) , pages 16–21. IEEE, 2010

    2010

  26. [34]

    The rijndael algorithm

    Tariq Jamil. The rijndael algorithm. IEEE potentials, 23(2):36–38, 2004

    2004

Pith tools

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