Preprint
Article

This version is not peer-reviewed.

Development of an Optimized Cross-Platform PQC Library

Submitted:

14 July 2026

Posted:

14 July 2026

You are already at the latest version

Abstract
This article presents the development of an optimized cross-platform post-quantum cryptographic (PQC) library that enhances the cryptographic security of data, networks and IT infrastructures in real-world organizational environments. Classical cryptographic standards such as RSA and ECC face existential threats from the advent of quantum computing, necessitating an urgent transition to quantum-resistant cryptographic algorithms. By optimizing execution speed through AVX2 vectorization via compiler intrinsics and ensuring portability across different operating environments, this work demonstrates the feasibility of deploying high-performance PQC in today's operational systems. The approach bridges PQC research to practical systems by integrating ML-DSA and ML-KEM implementations into a single compiled library, while adapting PQC implementations for cross-platform portability. Benchmarking results demonstrate up to a fourfold improvement in execution speed over reference implementations. This work strengthens an organization's security posture in the face of quantum computing threats and enables long-term cryptographic resiliency across diverse platform environments.
Keywords: 
;  ;  ;  ;  ;  

1. Introduction

Classical cryptography standards such as RSA and Elliptic Curve Cryptography (ECC), form the backbone of secure communications in government, defence, and commercial systems. However, they are becoming increasingly susceptible to quantum computing threats, as quantum algorithms, most notably Shor's algorithm, are theoretically capable of solving these problems in polynomial time, rendering these widely deployed standards fundamentally insecure in a post-quantum world.
Transitioning to the era of utilizing Post-Quantum Cryptography (PQC) standards is inevitable. However, the existence of such standards does not automatically translate to production-ready deployment. It presents its own set of challenges when it comes to ensuring that PQC implementations achieve high performance, are cross-platform and serve as production level DevOps-pipelined cryptographic libraries to support organizational cryptographic needs.
While PQC open-source implementations exist, none of the publicly available implementations provide an optimized compiler intrinsics-based library implementation that can be used across different platform environments. Most existing optimized variants remain tied to Linux assembly, while portable C versions lack optimization, highlighting the gap in achieving both performance and portability at the same time.
Therefore, this article addresses that gap directly. We present the development of a cross-platform, AVX2-optimized PQC library that packages ML-DSA and ML-KEM into a unified Dynamic Link Library (DLL), suitable for integration into organizational cryptographic pipelines on both Windows and Linux. Performance optimization is achieved through the systematic translation of platform-specific AVX2 assembly routines into C compiler intrinsics, preserving hardware-level execution speed while eliminating platform dependency. Benchmarking results demonstrate speedups of up to fourfold over reference implementations across major cryptographic operations.
The remainder of this paper is organized as follows. In Section 2, we review the importance of PQC and the need for optimized and cross-platform implementations. In Section 3, we present our problem statement in detail, followed by our proposed solution and its result and insight in Section 4 and Section 5 respectively. Section 6 highlights the technical innovations of the proposed solution and section 7 presents the future work. Finally, we draw a conclusion in Section 8.

2. Literature Review

This section presents the growing need for PQC, benefits of AVX2 vectorization and cross-platform portability implementation.

2.1. Growing Need for PQC in Modern Systems

This section covers the rationale behind the growing need for PQC in modern systems and IT infrastructures.

2.1.1. Emerging Quantum Threat Landscape and the Critical Need for Proactive Defense

The emergence of quantum computing poses a danger to the security of traditional widely used public-key cryptographic systems like RSA and ECC. Quantum algorithms like Shor’s algorithm have the theoretical ability to efficiently crack these conventional cryptographic systems. Although current quantum computers do not yet possess a sufficient number of stable qubits to practically execute Shor’s algorithm at the scale required to break real-world cryptographic keys, rapid advancements in quantum hardware indicate steady progress towards this capability. As shown in a research paper [1], PQC serves as a proactive defense approach for present and future communications to remain secure even in the presence of quantum computing capabilities.
In addition, the “harvest now, decrypt later” (HNDL) threat model [2] further emphasizes the importance and urgency of adopting quantum-resistant cryptography. Under the HNDL model, adversaries may collect and store encrypted data today with the intention of decrypting it in the future once quantum computing becomes sufficiently powerful. Relating to Mosca’s Theorem [3], because migrating large-scale cryptographic infrastructures requires significant time and planning, organizations must take immediate action to begin preparing early for the adoption of quantum-safe cryptographic mechanisms to safeguard long-term data confidentiality.

2.1.2. Limitations of Current Cryptography Standards

Current cryptography standards mainly depend on how difficult it is to solve specific mathematical problems, such as the large prime factorization and discrete logarithm problem, which quantum computing can solve efficiently, undermining the long-term security of these algorithms. Research [4] highlights that even robust algorithms like RSA and ECC are vulnerable to quantum attacks.

2.1.3. PQC and QKD as Responses to Quantum Computing Threats

There are two broad defensive strategies against quantum computing threats: post-quantum cryptography (PQC) which are algorithms based on new mathematically hard problems and resistant against quantum computing threats, as well as quantum key distribution (QKD) which uses quantum-mechanical properties to distribute keys securely.
PQC is a more deployable and scalable option because it can be integrated into existing digital infrastructures, standardized software, and current communication protocols without requiring entirely new systems, allowing the preservation of current system architectures. QKD on the other hand is often seen as a useful option because its security goal is rooted in quantum physics rather than only the hardness of mathematical problems.
However, the National Security Agency (NSA) does not recommend QKD for protecting systems unless major limitations are overcome. The NSA states that QKD is only a partial solution, requires special-purpose equipment, raises infrastructure cost, is difficult to validate securely, and introduces insider threat and denial-of-service risks, while PQC is considered more cost-effective and easier to maintain [5].

2.1.4. Global PQC Adoption Efforts

Governments and standardization bodies, led by NIST and the Department of Defense (DoD), have been pushing for the transition towards PQC through structured frameworks and standardization processes. NIST first initiated the PQC standardization effort [6] in 2016 by launching a global competition aimed at the development of quantum-resistant cryptographic algorithms under two primary tracks, key encapsulation mechanisms and digital signature algorithms. After rounds of evaluation, cryptanalysis, and performance testing, NIST selected multiple algorithms including CRYSTALS-Kyber for key establishment and CRYSTALS-Dilithium for digital signatures. Both schemes rely on the hardness of module-lattice problems and were later standardized as ML-KEM (FIPS 203) and ML-DSA (FIPS 204) respectively. This global effort highlights the urgency of PQC adoption in critical infrastructures [7].

2.2. High-Performance Acceleration of Cryptographic Algorithms Using AVX2 Vectorisation

This section provides literature review of utilizing AVX2 vectorization for efficient performance of cryptographic algorithms.

2.2.1. Performance Improvements with AVX2 Vectorization

By leveraging parallel processing through AVX2 instruction sets, it can greatly increase the throughput of PQC algorithms. According to a study [8], optimizations make it possible to implement lattice-based schemes in real-world settings without compromising security, increasing the feasibility of PQC. This balances the increase in security needs without compromising on speed efficiencies.

2.2.2. SIMD Vectorization in PQC Workloads

Polynomial multiplication, Number Theoretic Transform (NTT), and hashing are among the computationally demanding PQC operations that are greatly accelerated by Single Instruction Multiple Data (SIMD) extensions like AVX2 and AVX-512. SIMD enables the processing of multiple data elements simultaneously, which is particularly useful for the modular arithmetic and ring-based computations that form a large part of lattice-based cryptography. According to [9], AVX2-optimized implementations of polynomial ring multiplication can reduce clock cycles by up to 85%, enhancing throughput without compromising algorithmic integrity. Thus, SIMD addresses common PQC bottlenecks like coefficient-wise modular reduction and transform operations, improving overall cryptographic performance.

2.3. Cross-Platform Cryptographic Implementations

This section highlights the importance of cross-platform cryptographic implementations by looking at the disadvantages of platform-specific implementations and advantages of portable intrinsics-based implementations.

2.3.1. Drawbacks of Platform-Specific Implementations

Scalability and cross-architecture adoption in post-quantum systems face significant challenges when utilizing platform-specific cryptography implementations. As shown in [10], PQC algorithm deployment varied considerably across x86, ARM, and embedded platforms due to differences in memory structures, instruction sets, and processing capacity. As a result, ensuring platform interoperability becomes increasingly difficult. Furthermore, it complicates the integration of PQC in multi-device ecosystems like consumer electronics and IoT networks, signifying the need for consistent, portable implementations that ensure cryptographic security across diverse platforms.

2.3.2. Importance of Portability in Production Environments

Portable cryptographic implementations are essential for consistent performance, maintainability and interoperability across different hardware architectures. As demonstrated in a research study [11], the portability of efficient cryptographic algorithms, such as SM4, depends on their capacity to operate seamlessly on both x86 and ARM platforms, and resource-constrained embedded systems. Furthermore, their AVX2-based software optimization approach demonstrated that it supports adaption to future instruction sets like AVX-512 and NEON with enhanced processing efficiency. This flexibility ensures that PQC solutions remain relevant across evolving processor ecosystems, improving integration in diverse environments.

2.3.3. Advantages of Intrinsics-Based Cryptographic Implementations

Compiler intrinsics maintain portability across architectures enabling efficient execution. Intrinsic-based implementations result in less code duplication, simpler maintenance, and reliable performance across hardware platforms as compared to pure assembly. [12] demonstrated that compiler intrinsics may greatly reduce code complexity and the need for numerous hardware-specific versions while achieving performance comparable to or better than platform-specific SIMD libraries. This approach makes it ideal for PQC systems that need scalable, cross-platform cryptographic acceleration as it improves long-term maintainability.

3. Problem Statement

This section highlights specific challenges of current implementations.

3.1. Platform-Specific Optimized Implementation

Many systems used by organizations tap on Windows OS. However, existing PQC optimized implementations from official sources are written for and limited to its use in Linux environments. This is because performance optimizations are mostly implemented using AVX2 assembly instructions written in AT&T syntax for Linux, which are incompatible with Windows assemblers that use Intel syntax. As a result, organizations operating on Windows infrastructure cannot directly leverage these optimized implementations.

3.2. Lack of Cross-Platform Codebase

The need to support multiple environments such as Windows and Linux calls for an implementation approach that works consistently across platforms. While it is technically possible to maintain separate codebases for each environment, this approach introduces practical problems. Separate code paths for different architectures significantly complicate development workflows and raise the risk of subtle implementation inconsistencies between platforms, which in a cryptographic context can have serious security implications.

4. Solution

This section describes in detail the implementation of the proposed solution, to achieve the cross-platform AVX2-optimized ML-DSA algorithm. While the integrated library combines both ML-DSA and ML-KEM, the translation work presented in this paper focuses primarily on ML-DSA, as an AVX2 compiler intrinsics implementation of ML-KEM was already available and is incorporated into the unified library.

4.1. Translation to Compiler Intrinsics

Compiler intrinsics are low-level functions provided by compilers that map closely to specific CPU instructions while remaining accessible through high-level languages such as C. Figure 1. illustrates the workflow of translating existing AVX2 implementation currently written in Linux .S assembly files into C compiler intrinsics. Arithmetic operations, polynomial transformations, and other AVX2 assembly routines were all translated into their appropriate compiler intrinsic equivalents (for example, vpaddd in assembly is equivalent to _mm256_add_epi32 in compiler intrinsics).
Instead of direct translation from Linux assembly implementation into compiler intrinsics, the Linux .S assembly files written using AT&T syntax were first translated to the Windows .asm assembly files written using Intel syntax. This intermediate step helps to ensure consistent instruction representation and verifiable instruction behaviour of major algorithm functions within assembly language. As both Windows assembly and C compiler intrinsics follow Intel syntax conventions, this alignment ensures a natural and unambiguous mapping between the two representations, reducing the risk of instruction misinterpretation during translation. The Windows assembly files are then used as a structured reference to map assembly instructions to compiler intrinsics, allowing for the final ML-DSA implementation to be in C compiler intrinsics.
During the entire translation process, maintaining the structural behavior of the original instructions is the most important. This involves making sure that the data is aligned correctly for 256-bit vector loading, preserving register usage patterns and making sure that the operands are in the right sequence, especially for non-commutative arithmetic operations like subtraction and division. Since most of the assembly instructions had a close 1-to-1 mapping to its corresponding compiler intrinsics, maintaining this mapping was key to ensuring the correctness of the code and overall implementation.

4.2. Integration of Intrinsics Implementation

Once all assembly routines were successfully translated, the intrinsics implementation was added to the ML-DSA code structure as a whole. This was done by making sure that its function interfaces are the same as those used in the reference implementation. This ensured that the new AVX2 routines may be called by higher-level algorithm functions like key generation, signature generation, and signature verification, without needing to make major modifications to the main code flow or higher-level functions.

4.3. Ensuring Compliance with NIST PQC Standards

After developing a portable and optimized implementation of ML-DSA, the next step was to ensure that the parameters used in the code implementation and the function execution aligned with the NIST standard specifications accordingly, as seen in the FIPS 204 publication [13] for ML-DSA. Compliance was established by referencing to sections of the publication that described the differences and changes implemented between the original CRYSTALS-Dilithium submission and the final standardized ML-DSA algorithm. These were used to guide the necessary adjustments to ensure that the implementation accurately reflects the NIST-standardized version of the algorithm. Figure 2. illustrates one of the differences mentioned in the publication, which describes increasing the number of bytes used for two of the parameters in ML-DSA.

5. Result and Insight

This section describes in detail the results of the solution implementation and the insights observed from the results achieved.

5.1. Assembly-to-Intrinsics Translation of Cryptographic Operations

All five assembly routines (ntt.S, invntt.S, pointwise.S, shuffle.S and f1600x4.S) of ML-DSA were successfully translated from Linux .S assembly to Windows .asm assembly and finally C compiler intrinsics. Figure 3, Figure 4 and Figure 5 illustrate the translation of one of the assembly routines, ntt.S. The process begins with the original implementation in AT&T syntax (Figure 3), followed by its conversion into Intel syntax as ntt.asm (Figure 4), and concludes with its final translation into C using compiler intrinsics as ntt.c (Figure 5).

5.1.1. Number Theoretic Transform (NTT) Routine (ntt.S)

The ntt.S routine implements the Number Theoretic Transform (NTT), which is used to perform efficient polynomial multiplication. During translation, a key aspect to focus on is the translation of the butterfly computation and ensuring correct alignment for 256-bit AVX2 vector operations.

5.1.2. Inverse NTT Routine (invntt.S)

The invntt.S routine performs the inverse NTT, mapping polynomials from the NTT domain back to the standard domain. The implementation preserves the inverse butterfly structure and ensures precise coefficient scaling, maintaining mathematical correctness while optimizing for SIMD throughput.

5.1.3. Pointwise Polynomial Multiplication (pointwise.S)

The pointwise.S routine performs element-wise modular multiplication of polynomial coefficients in the NTT domain. During translation, particular attention was given to preserving the structure of the operation and optimizing the interleaving of multiplication with Montgomery reduction to maximize SIMD lane utilization.

5.1.4. Vector Shuffle Operation (shuffle.S)

The shuffle.S routine reorders coefficients to satisfy the lane-crossing requirements of the NTT’s butterfly computations. The translation focuses on using in-lane shuffles for early stages and cross-lane permute intrinsics for later stages, ensuring coefficients are correctly paired across the full 256-bit register for parallel arithmetic.

5.1.5. Keccak-f[1600] Permutation (f1600x4.S)

The f1600x4.S routine implements the Keccak-f[1600] permutation in a four-way parallel configuration using AVX2 vectorization. This permutation forms the core of the SHAKE-based hash functions used in ML-DSA. The translation preserved the structure of the 24 permutation rounds and the parallel processing of four Keccak states, ensuring that the vectorized state transformations remained consistent with the original implementation.

5.2. Functional Algorithm Validation

A simple test program was written to validate the ML-DSA algorithm and ensure correct functional behavior with expected results obtained for each of the major algorithm functions. Negative test conditions like tampered signatures were also executed to put the algorithm to the test under undesirable input conditions. Bytes at different positions of the signature (ML-DSA signatures are a concatenation of 3 components – challenge polynomial, response vector and hint vector) were randomly tampered to ensure that the signature verification function can reject tampered signatures regardless of which signature component has been tampered. Edge cases like wrong message lengths or mismatched messages were also executed to validate the robustness of the algorithm. Figure 6. illustrates the negative test conditions and edge cases.
Validating the functional behavior of the ML-DSA algorithm ensured that the functional correctness of the algorithm was maintained during the translation from assembly language to C compiler intrinsics.

5.3. Cross-Platform Algorithm Validation

Testing was done to ensure the compiler intrinsics version of ML-DSA could also be correctly executed in the Linux environment, with the same test program written and outputs compared to ensure both the Windows and Linux environments achieved the same outputs. Validating the algorithm’s ability to function across platforms ensured that it achieved the intended outcome, to execute in different environments regardless of architecture. This fulfilled the criteria where both portability and optimization were achieved through the development of the AVX2-optimized compiler intrinsics variant of ML-DSA.

5.4. Dynamic Link Library (DLL) Cryptographic Implementation

To produce a compiled PQC library, the final output was to compile both the compiler intrinsics versions of ML-DSA and ML-KEM algorithms into a single Dynamic Link Library (DLL), serving as a production level cryptographic library to support organizational cryptographic needs. This was achieved by configuring the project to build a Dynamic Link Library (.dll) and exporting the required functions using the “__declspec(dllexport)” attribute prior to compilation. As a result, the core functions for the PQC algorithms were exported as shown in Figure 7.
A simple test program was used to validate that the ML-DSA key generation, signature generation and signature verification functions, as well as the ML-KEM key generation, key encapsulation and key decapsulation functions were functioning as expected when being utilized as an external function. This DLL ensures that the cryptographic algorithms can be easily implemented by various teams and programs without needing to dabble in the detailed code and its complexities.

5.5. Performance Benchmarking of Algorithm Execution Speed

Performance benchmarking of algorithm execution speed was conducted on both ML-DSA and ML-KEM algorithms, to assess and quantify speed improvements achieved by the optimized AVX2 implementations in comparison to their reference implementations. This ensures the provision of a comprehensive performance evaluation of the unified library.
Each algorithm function was executed with 20 runs of 300 iterations each, and the average execution time for each major algorithm function and the whole algorithm was recorded. The average results were used for performance benchmarking to minimize the impact of external factors such as system latency and any computational background processes.
The AVX2 optimized implementations demonstrated significant improvements in speed performance across all cryptographic operations (Figure 8 (a)). These improvements are due to the use of 256-bit SIMD registers, which allow multiple data elements to be processed in parallel. Computationally intensive operations such as the Number Theoretic Transform (NTT) and pointwise polynomial multiplications, among other operations, benefited from the AVX2 vectorization, resulting in faster execution compared to the standard 64-bit register operations used in the reference implementation (Figure 8 (b)).
As shown in Figure 8, different functions of the ML-DSA algorithm had different speed improvements. Key generation achieved slightly over a twofold speed increase, while signature generation and verification showed larger improvements, with signature generation achieving a more than fourfold increase in execution speed. Overall, AVX2 achieved slightly over a threefold increase in execution speed when executing the ML-DSA algorithm across all major functions.
Similarly, the benchmarking results for ML-KEM, shown in Figure 9, indicate performance improvements across all major functions. Key generation and encapsulation demonstrated slightly over twofold speed increase, while decapsulation achieved improvements exceeding fourfold. Overall, the AVX2 implementation achieved more than twice the execution speed of the reference implementation for the ML-KEM algorithm across all major functions.
The varying levels of speed improvement observed are primarily due to differences in the number of computationally intensive operations amongst the different major functions, which ultimately affects the extent to which each function benefits from vectorized operations. Functions that have a larger number of complex computations tend to achieve greater performance speed improvements from AVX2 optimizations. The performance benchmarking results demonstrate the effectiveness of AVX2 vectorization in improving the computational efficiency of PQC algorithms, enhancing its feasibility in practical applications while maintaining correctness and compatibility with the reference implementations.

6. Contributions and Technical Innovations

The solution introduces several technical innovations achieved beyond existing implementations as detailed in this section.

6.1. Bridging Research PQC Implementations to Practical Systems

This solution bridges the gap between research-level PQC implementations and practical system deployment by adapting the ML-DSA and ML-KEM implementations for reliable execution in a controlled development environment. As research implementations tend to be experimental, additional steps will be required to further develop them before they can be used in organizational settings. Therefore, the solution focused efforts on the implementation, testing, and integration of PQC algorithms, demonstrating the transition from research implementations to practical production-level deployment in real-world operating environments.

6.2. Integrated PQC Cryptographic Library

An integrated PQC cryptographic library was developed by combining ML-DSA and ML-KEM into a unified DLL. The library allows applications to access multiple PQC algorithms through a consistent, simplified and well-defined interface, by calling the specific major functions of ML-DSA and ML-KEM, without requiring direct interaction with low-level cryptographic implementations. As the DLL only exposes the intended public functions while restricting access to internal functions, it ensures controlled and secured usage of the cryptographic operations. Overall, it improves usability and provides a practical approach to utilizing PQC algorithms to protect operational systems and defend against quantum computing threats.

6.3. Cross-Platform PQC Implementation and Adaptation

Implementing cross-platform PQC algorithms will allow the algorithms to execute consistently across multiple environments, including both Linux and Windows platforms. Translations between code syntaxes were implemented and validated, where the algorithm could perform consistently in various operating environments utilizing different compiler configurations, assembly syntax conventions, and instruction-set architectures. By providing for compatibility across platforms, it improves the portability and flexibility of the PQC implementations, allowing them to be more easily integrated into various system environments. This establishes a stronger technical foundation for future development and supports broader adoption of PQC algorithms in organization-wide practical applications.

7. Future Work

This article delved into the research and development of the ML-DSA and ML-KEM algorithm implementation, as well as the compilation of both PQC algorithms into an integrated DLL. Building on the outcomes of this research, future work may involve further research and development of additional PQC algorithms, such as Hamming Quasi-Cyclic (HQC), which is another algorithm for key encapsulation.
Expanding the current research and implementation to incorporate additional PQC algorithms would allow for more flexibility in the adoption of PQC in different environments, due to the availability of a wider range of cryptographic standards. This would strengthen long-term cryptographic resilience and support the continued adaptation to the evolving PQC standardization landscape.

8. Conclusions

This article presented the development of an optimized, cross-platform PQC library addressing a critical gap in the practical deployment of quantum-resistant cryptography in organizational IT infrastructures. By translating AVX2 assembly routines into C compiler intrinsics, the work demonstrates that hardware-level performance and cross-platform portability are not mutually exclusive goals, a combination that existing open-source implementations have not achieved.
The compilation of both ML-DSA and ML-KEM algorithms into a unified DLL further lowers the barrier to wider organizational adoption, providing development teams with a consistent, standards-compliant cryptographic interface without requiring direct engagement with low-level implementation details. Compliance with NIST FIPS 203 and FIPS 204 specifications was verified through functional validation and testing against expected algorithm outputs, ensuring that performance gains were achieved without compromise to cryptographic correctness.
As quantum computing capabilities continue to advance with increasing PQC adoption, the importance of bridging the gap between research-level implementations and production-ready deployment will only increase. This work establishes a practical and extensible foundation for that transition, demonstrating that with the right implementation approach, organizations need not choose between performance, portability, and standards compliance in securing their infrastructures against quantum computing threats.

Author Contributions

Original draft preparation: Charisee Zhi Ling Yip; Supervision and paper revision: Huaqun Guo; Supervision: Zhi Qian Seah. All authors have read and agreed to the published version of the manuscript.

Acknowledgments

The authors deeply acknowledge the supervisor and the organization for their help and support for this project. The authors would also like to thank the professor from the Singapore Institute of Technology (SIT) for their continued support and guidance.

Conflicts of Interest

The authors declare no conflicts of interest.

Abbreviations

The following abbreviations are used in this manuscript:
ARM Advanced RISC Machine
ASM Assembly Language
AT&T American Telephone and Telegraph
AVX2 Advanced Vector Extensions 2
AVX-512 Advanced Vector Extensions 512
CRYSTALS Cryptographic Suite for Algebraic Lattices
CPU Central Processing Unit
DEVOPS Development and Operations
DLL Dynamic Link Library
DOD Department of Defense
ECC Elliptic Curve Cryptography
FIPS Federal Information Processing Standards
HNDL Harvest Now, Decrypt Later
HQC Hamming Quasi-Cyclic
IoT Internet of Things
ML-DSA Module-Lattice-Based Digital Signature Algorithm
ML-KEM Module-Lattice-Based Key-Encapsulation Mechanism
NIST National Institute of Standards and Technology
NSA National Security Agency
NTT Number Theoretic Transform
OS Operating System
PQC Post-Quantum Cryptography
QKD Quantum Key Distribution
RSA Rivest-Shamir-Adleman
SHAKE Secure Hash Algorithm and KECCAK
SIMD Single Instruction Multiple Data
SM4 ShangMi 4

References

  1. Jenefa; Josh, F. T.; Taurshia, A.; Kumar, K. R.; Kowsega, S.; Naveen, E. “PQC Secure: Strategies for Defending Against Quantum Threats,” 2023 2nd International Conference on Automation, Computing and Renewable Systems (ICACRS); IEEE, 11 Dec 2023; pp. 1799–1804. [Google Scholar] [CrossRef]
  2. Mascelli, J.; Rodden, M. ‘Harvest Now Decrypt Later’: Examining Post-Quantum Cryptography and the Data Privacy Risks for Distributed Ledger Networks. FEDS 2025, no. 2025–093. [Google Scholar] [CrossRef]
  3. Mosca, M. Cybersecurity in an Era with Quantum Computers: Will We Be Ready? IEEE Secur. Priv. 2018, vol. 16(no. 5), 38–41. [Google Scholar] [CrossRef]
  4. Azhari, R.; Salsabila, A. N. Analyzing the Impact of Quantum Computing on Current Encryption Techniques. itsdi 2024, vol. 5(no. 2), 148–157. [Google Scholar] [CrossRef]
  5. NSA; National Security Agency/Central Security Service. www.nsa.gov. 08 February 2026. Available online: https://www.nsa.gov/Cybersecurity/Quantum-Key-Distribution-QKD-and-Quantum-Cryptography-QC/.
  6. Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology, U.S. Department of Commerce, “Post-Quantum Cryptography | CSRC | CSRC.”. 11 February 2026. Available online: https://csrc.nist.gov/projects/post-quantum-cryptography.
  7. Rawal, S.; Curry, P. J. Challenges and opportunities on the horizon of post-quantum cryptography. APL Quantum 2024, vol. 1(no. 2). [Google Scholar] [CrossRef]
  8. Gitonga, K. The Impact of Quantum Computing on Cryptographic Systems: Urgency of Quantum-Resistant Algorithms and Practical Applications in Cryptography. COMPUTE 2025, vol. 5(no. 1), 1–10. [Google Scholar] [CrossRef]
  9. Wang, B.; Gao, H.; Yang, F. Fast Implementation of Multiplication on Polynomial Rings. Secur. Commun. Netw. 2022, vol. 2022, 1–9. [Google Scholar] [CrossRef]
  10. Nejatollahi, H.; Dutt, N.; Ray, S.; Regazzoni, F.; Banerjee, I.; Cammarota, R. Post-Quantum Lattice-Based Cryptography Implementations. ACM Comput. Surv. 2019, vol. 51(no. 6), 1–41. [Google Scholar] [CrossRef]
  11. Li, X.; Xie, M.; Huang, C. Fast Software Implementation of the SM4 Algorithm. In Proceedings of the 2024 8th International Conference on High Performance Compilation, Computing and Communications. ACM, June 07, 2024; pp. 127–132. [Google Scholar] [CrossRef]
  12. Benson, L.; Ebeling, R.; Rabl, T.; Plattner Institute, Hasso. “Evaluating SIMD Compiler-Intrinsics for database Systems,” journal-article. 2023. Available online: https://ceur-ws.org/Vol-3462/ADMS5.pdf.
  13. Module-lattice-based digital signature standard; National Institute of Standards and Technology (U.S.), Aug 2024. [CrossRef]
Figure 1. Translation workflow from Linux assembly to C intrinsics implementation.
Figure 1. Translation workflow from Linux assembly to C intrinsics implementation.
Preprints 223163 g001
Figure 2. Snippet of differences between original submission and standardized ML-DSA.
Figure 2. Snippet of differences between original submission and standardized ML-DSA.
Preprints 223163 g002
Figure 3. Original ntt.S source code in AT&T syntax.
Figure 3. Original ntt.S source code in AT&T syntax.
Preprints 223163 g003
Figure 4. Intermediate ntt.asm translation in Intel syntax.
Figure 4. Intermediate ntt.asm translation in Intel syntax.
Preprints 223163 g004
Figure 5. Final ntt.c translation using C compiler intrinsics.
Figure 5. Final ntt.c translation using C compiler intrinsics.
Preprints 223163 g005
Figure 6. Negative test scenarios.
Figure 6. Negative test scenarios.
Preprints 223163 g006
Figure 7. PQC algorithm functions exposed via DLL.
Figure 7. PQC algorithm functions exposed via DLL.
Preprints 223163 g007
Figure 8. ML-DSA performance benchmarking.
Figure 8. ML-DSA performance benchmarking.
Preprints 223163 g008
Figure 9. ML-KEM performance benchmarking.
Figure 9. ML-KEM performance benchmarking.
Preprints 223163 g009
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.
Copyright: This open access article is published under a Creative Commons CC BY 4.0 license, which permit the free download, distribution, and reuse, provided that the author and preprint are cited in any reuse.
Prerpints.org logo

Preprints.org is a free preprint server supported by MDPI in Basel, Switzerland.

Subscribe

© 2026 MDPI (Basel, Switzerland) unless otherwise stated

Accessibility

Disclaimer

Terms of Use

Privacy Policy

Privacy Settings