CoChat
Sign Up
Cited by 26Cryptographic Implementations and SecurityParallel Computing and Optimization TechniquesCryptography and Residue Arithmetic

Highly Efficient Implementation of Block Ciphers on Graphic Processing Units for Massively Large Data

Open access
An, SangWoo, Seo, Seog Chung·2020·Applied Sciences
DOI 10.3390/app10113711
Open this paper in CoChat — free accountOpen PDF

Abstract

With the advent of IoT and Cloud computing service technology, the size of user data to be managed and file data to be transmitted has been significantly increased. To protect users’ personal information, it is necessary to encrypt it in secure and efficient way. Since servers handling a number of clients or IoT devices have to encrypt a large amount of data without compromising service capabilities in real-time, Graphic Processing Units (GPUs) have been considered as a proper candidate for a crypto accelerator for processing a huge amount of data in this situation. In this paper, we present highly efficient implementations of block ciphers on NVIDIA GPUs (especially, Maxwell, Pascal, and Turing architectures) for environments using massively large data in IoT and Cloud computing applications. As block cipher algorithms, we choose AES, a representative standard block cipher algorithm; LEA, which was recently added in ISO/IEC 29192-2:2019 standard; and CHAM, a recently developed lightweight block cipher algorithm. To maximize the parallelism in the encryption process, we utilize Counter (CTR) mode of operation and customize it by using GPU’s characteristics. We applied several optimization techniques with respect to the characteristics of GPU architecture such as kernel parallelism, memory optimization, and CUDA stream. Furthermore, we optimized each target cipher by considering the algorithmic characteristics of each cipher by implementing the core part of each cipher with handcrafted inline PTX (Parallel Thread eXecution) codes, which are virtual assembly codes in CUDA platforms. With the application of our optimization techniques, in our implementation on RTX 2070 GPU, AES and LEA show up to 310 Gbps and 2.47 Tbps of throughput, respectively, which are 10.7% and 67% improved compared with the 279.86 Gbps and 1.47 Tbps of the previous best result. In the case of CHAM, this is the first optimized implementation on GPUs and it achieves 3.03 Tbps of throughput on RTX 2070 GPU.

The claims and statistics of this paper haven’t been checked yet.

Run the check — free, no account needed. It reads the open-access text and checks the sources it cites.

A few free checks a day · papers already verified open instantly · results are public

Integrity signals

Registry

Crossref · 10.3390/app10113711

Cites

15 of 15 references verified0 citation errors · 0 not checkable

Statistics

Claims the paper makes

The claims and statistics of this paper haven’t been checked yet.

Run the check — free, no account needed. It reads the open-access text and checks the sources it cites.

A few free checks a day · papers already verified open instantly · results are public

Claims other papers make about this one

Each is checked against this paper’s own text: does it say what the citing paper says it does?

  • The AES-128 design by [69] on the Spartan-7 XC7S75FGG reached 47.488 Gbps with a critical delay of 2.69 ns and a TPS of 33.3.

    “In comparison, the AES-128 design by [69] on the Spartan-7 XC7S75FGG reached 47.488 Gbps with a critical delay of 2.69 ns and a higher TPS of 33.3.”

    From First Fully Pipelined High Throughput FPGA Implementation and GPU Optimization of Wider Variant of AES (2026) · cites this paper as [69]

    The Abstract and Table 8 (section 6, page unavailable) describe this paper’s AES implementation on NVIDIA GPUs, not the Spartan-7 FPGA. They report up to 310 Gbps on an RTX 2070, rather than 47.488 Gbps on a Spartan-7. The cited paper does not report the claimed critical delay or TPS. (LLM, conf=0.88)

    Checked by a reasoning model — may be wrong.

    Experimental — accuracy not yet measured

  • The design by [69] on the Artix-7 XC7A200TL reported 47.360 Gbps with a critical delay of 2.70 ns and a TPS of 39.3 Mbps/LUT.

    “In comparison, the design by [69] on the Artix-7 XC7A200TL reported 47.360 Gbps with a critical delay of 2.70 ns and a significantly higher TPS of 39.3 Mbps/-LUT.”

    From First Fully Pipelined High Throughput FPGA Implementation and GPU Optimization of Wider Variant of AES (2026) · cites this paper as [69]

    Table 8 (6. Conclusions; page unavailable) identifies the paper’s own implementations as running on GTX 970, GTX 1070, and RTX 2070 GPUs, not an Artix-7 FPGA. The paper reports GPU throughput figures instead of the attributed 47.360 Gbps, 2.70 ns delay, and 39.3 Mbps/LUT TPS. (LLM, conf=0.87)

    Checked by a reasoning model — may be wrong.

    Experimental — accuracy not yet measured

  • AES-GCM is widely recommended for high-bandwidth applications because it combines the parallelizability of Counter Mode with a built-in integrity check.

    “AES-GCM is widely recommended for such high-bandwidth applications because it combines the parallelizability of Counter Mode, essential for handling large payloads efficiently, with a built-in integrity check that detects data corruption without the overhead of a separate HMAC pass (McGrew and Viega, 2004; An and Seo, 2020).”

    From A high-throughput AES-GCM implementation on GPUs for secure, policy-based access to massive astronomical catalogs (2026) · cites this paper as An and Seo, 2020

    Section 3.2.4 (page unavailable) says CTR mode encrypts blocks in parallel and enables efficient GPU encryption; it also mentions Galois/Counter mode as a use of CTR. It does not say AES-GCM is widely recommended for high-bandwidth applications or describe a built-in integrity check that avoids a separate HMAC pass. (LLM, conf=0.86)

    Experimental — accuracy not yet measured

  • The design by [69] on the UltraScale+ XCKU025 reported 63.744 Gbps using 1047 slices and 80 BRAMs, with a TPS of 60.9 Mbps/LUT.

    “In contrast, the design by [69] on the UltraScale+ XCKU025 reported 63.744 Gbps using 1047 slices and 80 BRAMs, with a much higher TPS of 60.9 Mbps/LUT.”

    From First Fully Pipelined High Throughput FPGA Implementation and GPU Optimization of Wider Variant of AES (2026) · cites this paper as [69]

    Table 8 in §5.3 compares block-cipher throughput on GPUs and a CPU; it does not report an UltraScale+ XCKU025 design. Searches for XCKU025 and the claimed throughput, resource counts, and TPS found no passage addressing those figures in our copy. (LLM, conf=0.78)

    Experimental — accuracy not yet measured

Self-check

Percentages, sums and reported differences re-computed from the paper’s own numbers.

The self-check needs the paper’s full text.

Cites

Flagged first, then by citations

Research works printed but not linked: 1

  1. Gladman, B. A Specification for Rijndael, the AES Algorithm. Available online: https://pdfs. semanticscholar.org/9798/dbce96185ddc14f5da684c1cc4cb8642a276.pdf?_ga=2.98532575.191228374. 1589876278-2102828541.1587714240 (accessed on 30 April 2020).

Cited by

Sorted by citations

Related

Authors
An, S., & Seo, S. C.
Affiliations
Kookmin University (KR)
Corresponding author
Seo, Seog Chung
ORCID
Venue
Applied Sciences
Publisher
MDPI AG
Published
2020-05-27
Volume
10
Issue
11
Pages
3711
ISSN
2076-3417 (ISSN-L)
DOI
10.3390/app10113711
OpenAlex
W3031989380
Cited by
26
References
15
Citations by year
2026: 5 · 2025: 3 · 2024: 6 · 2023: 3 · 2022: 5 · 2021: 3 · 2020: 1
FWCI
1.18
Type
journal article
Language
en
Open access
Licence
Locations
  • Applied Sciences (publishedVersion, cc-by)
  • DOAJ (DOAJ: Directory of Open Access Journals) (submittedVersion, cc-by-sa)
Funders
National Research Foundation of Korea (2019R1F1A1058494)
Topics
  • Physical Sciences › Computer Science › Artificial Intelligence › Cryptographic Implementations and Security
  • Physical Sciences › Computer Science › Hardware and Architecture › Parallel Computing and Optimization Techniques
  • Physical Sciences › Computer Science › Information Systems › Cryptography and Residue Arithmetic
Keywords
AES, LEA, Cham, counter mode, CUDA, memory optimization, throughput, Internet of Things security, cloud security

About these checks

Registry, retraction, Cites and statistics results are computed, not judged, with one exception: a printed reference that no index lists is read once by a model before it counts as a citation error. Claims are extracted by a model and kept only when their quote appears verbatim in the text; each cited source is then checked, with a model’s help, for whether it says what the claim relies on. Those verdicts can be wrong — read the claim’s quote and the cited source before relying on one.

Statistics and arithmetic are recomputed, not judged.

Confidence bands are shown only for fields calibrated on our annotated test set. None is calibrated yet, so no band is shown.

What counts as a claim ›How we measure confidence ›How we check this ›

Are you an author, or do you see a problem with this page? Request a review