Computer Standards & Interfaces 97 (2026) 104114 Contents lists available at ScienceDirect Computer Standards & Interfaces journal homepage: www.elsevier.com/locate/csi Assessing the quantum readiness of cryptographic standards: Recommendations toward quantum-era compliance Vikas Chouhan a ,∗, Mohammed Aldarwbi a , Somayeh Sadeghi a , Ali Ghorbani a , Aaron Chow b , Robby Burko b a Canadian Institute for Cybersecurity (CIC), University of New Brunswick, Canada b Scotiabank, Toronto, Canada ARTICLE INFO ABSTRACT Keywords: Cryptography is fundamental to securing digital data and communications, yet established algorithms face Cryptography increasing risk from emerging quantum capabilities. With the progression of quantum computing, the urgency Quantum computing for cryptographic standards that remain secure in both classical and quantum settings has intensified, governed Post-quantum computing not only by cryptanalytic risk but also by compliance, interoperability, and country-specific regulatory Quantum-readiness frameworks. This paper presents a structured evaluation framework that depicts the hierarchy of crypto- Standardization Security graphic standards, encompassing block ciphers, stream ciphers, hash and MAC functions, key establishment mechanisms, digital signatures, lightweight cryptography, entity authentication, public key infrastructure, and authentication and communication protocols. We define a standards-to-protocol recommendation flow that propagates compliant guidance across layers, from foundational primitives to PKI/authentication and hybridization, and extends to country-specific recommendations and protocols. Our contributions include explicit decision criteria for assessing cryptographic primitives under classical and quantum threat models, yielding both immediate and alternative deployment recommendations aligned with NIST-compliant guidelines. We further analyze hybrid schemes to ensure backward compatibility and secure integration, quantifying storage and network overheads for signatures, encryption, and key exchange to identify practical engineering trade-offs. Consolidated results are presented in reference tables detailing standardization year, purpose, notes, and migration recommendations for both classical and post-quantum contexts. Additionally, we examine the security strength of cryptographic primitives that are currently classically secure or quantum-resistant. This framework offers a reproducible, extensible path toward quantum-ready cryptographic systems. 1. Introduction such as ensuring backward compatibility and balancing security with performance requirements [3,7]. These gaps highlight the critical need The rapid evolution of quantum computing poses an imminent for systematic recommendations and hybrid approaches that facilitate threat to the foundational security of cryptographic systems [1–3]. a seamless transition while maintaining robust security for current Traditional cryptographic algorithms, while robust against classical existing systems. This work is motivated by the pressing need to adversaries, are rendered vulnerable in the presence of quantum adver- assess the ‘‘quantum readiness’’ of existing cryptographic standards. By saries due to their reliance on computational problems that quantum analyzing the efforts of standardization organizations and evaluating computers can solve efficiently [1,3]. This emerging reality under- cryptographic primitives in both symmetric and asymmetric algo- scores the urgent need for the development and adoption of quantum- rithms, this research provides actionable insights and recommendations resistant cryptography to safeguard sensitive information and digital communications in a post-quantum era. Despite notable progress in for achieving compliance in the quantum era. These insights are crucial standardizing post-quantum cryptographic algorithms [4–6], a compre- for guiding researchers, policymakers, and practitioners in adopting hensive analysis of existing cryptographic standards that cover both cryptographic systems that are resilient against classical and quantum classical and post-quantum approaches is still lacking. Moreover, the adversaries. Furthermore, this work seeks to emphasize the importance transition to quantum-resilient systems is fraught with challenges, ∗ Corresponding author. E-mail addresses: vikas.chouhan@unb.ca (V. Chouhan), m.aldarwbi@unb.ca (M. Aldarwbi), s.sadeghi@unb.ca (S. Sadeghi), ghorbani@unb.ca (A. Ghorbani), aaron.chow@scotiabank.com (A. Chow), robby.burko@scotiabank.com (R. Burko). https://doi.org/10.1016/j.csi.2025.104114 Received 25 April 2025; Received in revised form 6 November 2025; Accepted 8 December 2025 Available online 17 December 2025 0920-5489/© 2025 Elsevier B.V. All rights are reserved, including those for text and data mining, AI training, and similar technologies. V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 of continued innovation in quantum-resistant cryptography to ensure a collaboratively across government, academia, and industry to address secure digital future. evolving security demands, with a growing emphasis on post-quantum Standards serve as universal benchmarks for cryptographic algo- cryptography and secure interoperability. rithms and protocols, offer recommendations for secure computer sys- For a detailed overview, a summary of the relevant information is tem design, and provide guidance on managing cryptographic infor- provided in Table 1, with further elaboration available in Appendix A. mation and services. Numerous organizations exist to develop and establish standards, each with distinct origins and purposes. The British 1.2. Quantum-resistant cryptography Standards Institution (BSI1 ) identifies eight advantages that companies can obtain by adhering to standards. These benefits encompass a vari- The impact of quantum computing on cryptography is a major con- ety of areas, such as meeting customer expectations, being cost-effective cern for the security community. The potential of quantum computers and efficient in terms of time, conforming to legal requirements, en- to quickly solve problems that classical computers cannot solve effi- hancing management practices, exhibiting integrity and building trust, ciently, such as factoring large numbers, threatens to compromise many establishing a stronger brand image, and facilitating exportation while of the currently employed cryptographic algorithms. To address this maintaining credibility in the global arena. Trust, cost-effectiveness, challenge, significant efforts are underway to develop Post-Quantum and time-effectiveness are the main benefits obtained through the use Cryptography (PQC) [8] that can resist attacks from quantum comput- of cryptographic standards. ers. NIST has emphasized the importance of developing post-quantum Standardization involves the establishment and definition of tech- cryptography to ensure the long-term security of digital communication nical standards through the agreement and collaboration of different and data. It has issued draft standards for the use of PQC algorithms entities, which can include industry groups, interest groups, standards in various applications, including key establishment, digital signatures, organizations, and governmental bodies. In the following subsection, and encryption. However, these standards are still under development we will present an introduction to notable organizations engaged in and subject to change. Since 2016, NIST has been conducting a project standardization. This will be followed by an overview of quantum- to evaluate and standardize PQC algorithms. The project aims to iden- resistant cryptography, an analysis of standardization recommenda- tify quantum-resistant cryptographic algorithms that can replace the tions, and a delineation of the contributions and organization of this currently used algorithms that will become vulnerable to quantum paper. computer attacks. NIST has published several rounds of evaluations and results. The 1.1. Standardization organizations first round of submissions included 69 algorithms, which were nar- rowed down to 26 candidates in the second round. In the third round, Standardization organizations are pivotal in shaping secure and they chose 15 candidate algorithms, seven of which were designated interoperable cryptographic systems by developing consistent global as finalists and the remaining eight as alternatives. In 2022, NIST or national standards. At the international level, major bodies like announced that four candidates for standardization had been selected, ISO,2 IEC,3 and ITU4 focus on cryptographic standards for information including one KEM algorithm (CRYSTALS-KYBER) and three Signature security, telecommunications, and electrical technologies. ISO and IEC algorithms (CRYSTALS-Dilithium, FALCON, and SPHINCS+), with four jointly manage cryptographic standards through JTC1, with subcom- alternative KEM algorithms (Classic McEliece, HQC, BIKE, and SIKE) mittees such as SC27 and SC17 covering IT security and personal continuing into the fourth round [6]. It is important to note that the identification. The IETF5 and IANA6 play critical roles in Internet- evaluation process is ongoing, and new algorithms may still be added, related protocols and resource coordination, with the IETF producing or existing algorithms may be modified based on further analysis and widely respected RFCs. National organizations, including NIST7 (USA), feedback from the research community. ANSI,8 and BSI9 (UK), contribute by tailoring standards to their domes- Beyond algorithm development, NIST has also addressed the broader tic needs while aligning with international efforts, NIST notably leads challenges of migration. Its recent white paper, Mappings of Migration the standardization of post-quantum cryptography. to PQC Project Capabilities to Risk Framework Documents [9], outlines In the industrial sector, entities such as IEEE,10 ETSI,11 3GPP,12 and how organizations can align post-quantum transition activities, such as consortia like PKCS (RSA Laboratories), SECG,13 and the CA/Browser cryptographic discovery, inventory, and interoperability testing, with Forum14 contribute to specialized cryptographic standards in wireless established risk management frameworks (e.g., CSF 2.0 and SP 800- networks, ECC, SSL/TLS, and public-key systems. Emerging coalitions 53). In parallel, Executive Order (EO) 14144 (January 16, 2025) directs like the PQC Alliance15 and PQC Coalition16 have formed to promote federal agencies to prepare for PQC adoption, including maintaining a and standardize quantum-resistant cryptographic primitives, ensuring CISA-maintained list of product categories where PQC-capable prod- preparedness for future quantum threats. These organizations work ucts are widely available and incorporating PQC support into federal procurements [10]. As of 2023, NIST had published three draft Federal Information 1 https://www.bsigroup.com Processing Standards (FIPS) related to post-quantum cryptography al- 2 https://www.iso.org gorithms. On August 13, 2024, NIST released the final versions of the 3 https://www.iec.ch first three post-quantum cryptography standards: FIPS 203, FIPS 204, 4 https://www.itu.int and FIPS 205. These standards mark a transition from their original 5 https://www.ietf.org 6 algorithm names to new official designations: https://www.ietf.org/process/iana 7 https://www.nist.gov 8 (i) CRYSTALS-KYBER is now known as Module-Lattice-Based Key- http://www.ansi.org 9 Encapsulation Mechanism Standard (ML-KEM), covered under https://www.bsigroup.com 10 https://standards.ieee.org FIPS 203.17 11 http://www.etsi.org (ii) CRYSTALS-DILITHIUM has been renamed to Module-Lattice- 12 http://www.3gpp.org Based Digital Signature Standard (ML-DSA), governed by FIPS 13 http://www.secg.org 204.18 14 https://cabforum.org 15 https://pqca.org 16 17 www.mitre.org/news-insights/news-release/post-quantum-cryptography- https://csrc.nist.gov/pubs/fips/203/final 18 coalition-launches https://csrc.nist.gov/pubs/fips/204/final 2 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 1 Overview of standardization organizations and their contributions. Organization Type Organization Focus area(s) and contributions ISO/IEC JTC1 IT security, cryptography, biometrics. ISO 27001, ISO/IEC 8730, ISO/IEC TR 14516 ITU (ITU-T) Telecommunications, cryptographic network services. X series recommendations (PKI, cryptography) International IETF/IRTF Internet protocols and cryptographic RFCs. RFCs (TLS, IPsec, etc.) IANA Internet resource management. DNS root zone, IP address space, protocol registries NIST (USA) Federal standards, post-quantum cryptography. AES, FIPS series, PQC standardization National ANSI/X9 (USA) Financial cryptography. ANSI X9 standards, cooperation with ISO TC68 BSI (UK) Information security management systems. BS 7799-2 (basis of ISO 27001) IEEE Wireless and asymmetric cryptography. IEEE 802.11 (Wi-Fi), IEEE 1363 (asymmetric cryptography) 3GPP Mobile communication security. Cryptographic standards for cellular networks ETSI Telecom interoperability. 3GPP collaboration, European telecom standards SECG Elliptic Curve Cryptography (ECC). SEC 1, SEC 2 (ECC standards) Industrial PKCS (RSA Labs) Public key cryptography. PKCS #1 - #15: RSA, CMS, key management CA/Browser Forum SSL/TLS certificate policies and PKI trust. Baseline Requirements, EV Guidelines OASIS Security standards, XML, cloud. SAML, ODF, open cybersecurity standards PQC Alliance, PQC Coalition Post-quantum cryptography standardization and awareness. Migration tools, open-source PQC libraries, collaboration across academia and industry Details of standardization organizations and their contributions are presented in Appendix A. strategies is provided in Section 7. We also examine global crypto- graphic standards, considering how different nations are adapting their policies in response to the growing capabilities of quantum computing. We introduce a structured framework that illustrates the hierarchy of cryptographic standards to define the order of recommendation flow. This framework outlines a systematic migration approach, apply- ing recommendations from the foundational primitives at the bottom to the top-level protocols. The recommendation process begins with foundational cryptographic primitives, such as symmetric encryption, asymmetric encryption, hash functions, and digital signatures. These primitives serve as the core building blocks for more complex security systems. Once these basic primitives are standardized, the process moves to the next layer, which addresses country-specific regulations Fig. 1. A structured framework depicting the hierarchy of cryptographic and the implementation of hybrid public key infrastructure (PKI) and standards for defining the order of recommendation flow. authentication mechanisms. This layer builds on the foundation laid by the primitives, ensuring that cryptographic systems comply with regional and regulatory requirements. (iii) SPHINCS is now referred to as Stateless Hash-Based Digital The third layer of our analysis focuses on established protocols Signature Standard (SLH-DSA), defined under FIPS 205.19 for secure communication, including well-known protocols such as These updates mark a significant milestone in adapting cryptographic TLS/SSL, SSH, and Kerberos. These protocols are essential to ensure standards to mitigate the risks posed by quantum computing, ensuring secure data exchange over networks and rely on the cryptographic robust security for digital communications and transactions. In addi- primitives and authentication mechanisms defined in the lower layers. tion, NIST has announced that the code-based algorithm HQC will be As we move to the top layer, we consider specialized protocols such standardized as a backup key-encapsulation mechanism.20 as SAML (Security Assertion Markup Language) and OAuth, which are commonly used for identity federation and authorization. These 1.3. Standardization and analysis of recommendations higher-level protocols depend on the security established in the lower layers and are critical for ensuring secure access control and identity In this subsection, we conduct a detailed analysis of cryptographic management in distributed systems. standards and recommendations, focusing on various cryptographic Through this layered approach, we demonstrate how cryptographic primitives and protocols that impact both classical and post-quantum primitives influence the design and security of more complex systems. security. We examine a wide range of cryptographic functions, such To support the transition to quantum-resilient systems, we provide de- as symmetric encryption (including block ciphers and stream ciphers), tailed recommendations for classical and post-quantum cryptographic asymmetric encryption, hash functions, message authentication codes systems. These recommendations are intended to guide organizations (MACs), digital signatures, key establishment mechanisms, lightweight and researchers in securing their cryptographic infrastructures against cryptography, entity authentication, and public key infrastructure (PKI). both classical and quantum threats. Furthermore, we evaluate widely used cryptographic protocols for In this work, our analysis and recommendations are summarized secure communication, including HTTPS, SSH, and others, to assess in tables that provide guidance for quantum-resistant cryptography. their robustness in both classical and quantum threat environments. The tables include detailed columns for clarity: the ‘‘Algorithms/Pro- Beyond evaluating existing cryptographic standards, we briefly tocols’’ column lists each cryptographic algorithm or protocol, the highlight the emerging role of hybrid solutions as a transitional ap- ‘‘Standards/RFC’’ column specifies the corresponding standard, the proach toward quantum security. A detailed analysis of hybridization ‘‘Year’’ column indicates when each standard was established, and the ‘‘Purpose’’ column outlines its intended applications. The ‘‘Note’’ 19 https://csrc.nist.gov/pubs/fips/205/final column provides additional details, while the final columns present 20 https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth- quantum-safe (classical and post-quantum) recommendations for each algorithm-post-quantum-encryption algorithm or protocol, based on the criteria defined in Section 1.4. 3 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 To further illustrate the relationships and flow of cryptographic standards, Fig. 1 presents a structured framework illustrating the hi- erarchy of cryptographic standards for defining the order of the recom- mendation flow. This figure visualizes a layered approach to analyzing security standards. The base layer (layer 1) establishes standardized recommendations for the fundamental building blocks of cryptography. These primitives serve as the foundation for the higher layers of the hierarchy, ensuring that cryptographic systems are secure and resilient to both classical and quantum threats. Regarding recommendation flow, in our structured framework, we refer to the foundational or lower-level recommendations of primitives in the higher layers without redefining them. Fig. 2. Mosca’s theorem illustrating the relationship between migration time, 1.4. Quantum readiness and evaluation criteria data lifetime, and the estimated arrival of quantum computing capabili- ties [16]. Quantum readiness refers to the preparedness of cryptographic systems to withstand adversarial capability from quantum computers. ommendations. Our methodology unifies established standards into a Quantum computers, due to their ability to solve certain mathematical migration-oriented evaluation framework. While NIST SP 800-57 Part problems exponentially faster than classical computers, pose a threat 1 Rev. 5 addresses classical key management and strength, and the to widely used cryptographic algorithms such as RSA and ECC (Elliptic PQC security categories cover quantum-resistant algorithms, neither Curve Cryptography). A quantum-ready cryptographic system is one provides a combined workflow spanning both threat models with mi- that is secure against quantum computational threats, either through gration guidance. Our criteria fill that gap by enabling reorganizations the use of post-quantum cryptographic algorithms, strong symmetric to assess primitives side-by-side, map systems from current classical cryptography, or hybrid cryptographic solutions. compliance through transition to full PQ-readiness, and prioritize al- To evaluate cryptographic systems based on their readiness for gorithm selection, risk mitigation, and transition steps in a structured the quantum era, our analysis considers both classical and quantum way. adversarial models. 1. Classical Recommendations: we assume adversaries are lim- 1.5. Motivations ited to classical computing capabilities. Under this assumption, we align with NIST Special Publication NIST SP 800-57 Part The motivation for this work stems from two converging pressures 1 Rev. 5, which provides general key-management guidance on the cryptographic ecosystem: and classical key-strength recommendations [11]. Based on this guidance, we adopt a target of at least 128-bit classical security 1. The Quantum Threat: Mosca’s Theorem (Fig. 2) provides a (or equivalent as defined in Section 2, Table 3). This target is simple but powerful framework to reason about urgency. It sufficient to meet the baseline security levels recommended by states that if the time required to migrate to new cryptographic NIST for pre-quantum threat models. standards (𝑥) plus the required confidentiality period of sensitive 2. Post-Quantum (PQ) Recommendations: we assume adver- data (𝑦) exceeds the estimated time to a cryptographically rele- saries may access or exploit quantum computing capabilities. In vant quantum computer (𝑧), i.e., 𝑥+𝑦 ≥ 𝑧, then today’s encrypted this context, we adopt evaluation criteria aligned with NIST’s information is already at risk. In other words, data protected PQC ‘‘Security Evaluation Criteria’’ guidance, which defines with classical algorithms can be collected now and retroactively five broad security-strength categories (Levels 1–5) (see Sec- broken once quantum capabilities arrive. x tion 2) [12]. Based on both key-strength recommendations [11] According to the Quantum Threat Timeline Report 2024 [16], and NIST’s higher security-strength levels [12], we adopt a experts largely agree that while the next five years pose little target of 128-bit quantum-equivalent security (roughly 256- immediate risk, the likelihood of a cryptographically relevant bit classical equivalent) as our migration benchmark and map quantum computer (CRQC) increases significantly within 10 to that target to one of the appropriate NIST PQC levels. These 15 years. Within 30 years, nearly 90% of experts expect such recommendations are categorized into: machines to exist, with most assigning probabilities above 70%. • Available Recommendations: PQC algorithms, protocols, Although the short-term danger is limited, the long-term threat and symmetric primitives whose security-strength equiv- is widely regarded as inevitable, making proactive preparation alence is considered under FIPS PQ standards (for ex- essential. ample, FIPS 203 for KEMs, FIPS 204 and FIPS 205 for 2. The Compliance Threat: even before a CRQC materializes, or- signatures) [13–15]. ganizations face regulatory and market pressures. Governments • Alternative Recommendations: Viable fallback or in- and agencies worldwide have issued clear PQC adoption time- terim options for scenarios where the primary PQ rec- lines, with many mandating exclusive PQC use by the early ommendations are impractical (for example, due to hard- 2030s. Failure to comply not only increases technical exposure, ware or configuration constraints) but which still meet but also risks loss of market access and trust (see Table 2). equivalent security-strength targets. In summary, both the inevitability of the quantum threat (as cap- The evaluation criteria for these quantum-resistant recommenda- tured by Mosca’s Theorem and expert forecasts) and the accelerating tions are critical for reorganizations planning a migration strategy pace of compliance requirements underline the urgency of migrating to PQ-secure systems. They guide the assessment of cryptographic to post-quantum cryptography. Since such transitions are complex and primitives under both classical and quantum threat models and were multi-year in nature, action must begin well before the threat fully applied in our structured framework to provide quantum-safe rec- materializes. 4 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 2 key infrastructure and authentication protocols. Additional communi- International guidelines on preferred and mandatory dates for the adoption of cation protocols are discussed in Section 11. A synthesized discussion PQC. Max lifetime (yrs) indicates the number of years a product is expected in Section 12 draws connections between these findings, and the paper to remain on the market. concludes in Section 13. Guideline PQC preferred Only PQC Max lifetime (yrs) ASD Australia [17] 2025 2030 5 2. Security strength CNSA 2.0 (NSA) [18] 2025 2033 8 EU NIS CG [19] 2025 2030 5 NIST IR 8547 [20] 2026 2035 10 The main factor to consider when evaluating a cryptographic scheme ANSSI (France) [21] 2025 2030 5 is how secure it is. However, it is difficult to accurately assess the UK NCSC [22] 2027 2035 10 security of post-quantum cryptosystems, as noted by NIST. This is because there is a risk of discovering new quantum algorithms that could be used to attack these systems, and it is difficult to predict the 1.6. Contributions future capabilities of quantum computers in terms of cost, speed, and memory size. This paper presents a systematic evaluation of global cryptographic NIST will create a set of broad security strength categories instead of standards, encompassing symmetric and asymmetric encryption, hash quantifying the strength of a submitted method using specific estimates functions, MACs, digital signatures, key establishment, and secure com- of the amount of ‘‘bits of security’’. Each category will be defined by a munication protocols such as TLS, SSH, SAML, and OAuth, with a very simple-to-analyze reference primitive, whose security will serve focus on post-quantum readiness. By integrating classical and quantum as a baseline for a wide range of metrics that NIST considers to be threat models, it provides actionable guidance for the design and potentially relevant to practical security. To fit into multiple categories, deployment of secure, future-proof cryptographic infrastructures. The a cryptosystem might be implemented with distinct parameter sets. The key contributions are: classification objectives are as follows: ∙ We develop a structured evaluation framework to analyze cryp- 1. To make meaningful performance comparisons between the pro- tographic primitives and protocols under both classical and quan- vided methods easier, make sure that the parameter sets being tum adversaries. The framework aligns with NIST guidelines and compared are as secure as possible. is illustrated through a layered model that depicts the hierarchy of 2. To enable NIST to make informed judgments on when to switch cryptographic standards and defines the order of recommendation to longer keys in the future. flow. 3. To assist contributors in making consistent and rational decisions ∙ We present an integrated perspective that links foundational about the symmetric primitives to utilize in padding mechanisms primitives to higher-level architectures, regulatory compliance, or other symmetric cryptography-related components of their and protocol design. Hybrid approaches are examined to ensure schemes. backward compatibility while enabling smooth migration toward 4. To get a better understanding of the security/performance trade- quantum-resilient systems. offs that a particular design style entails. ∙ We construct structured reference tables that consolidate key NIST will base its classification on the range of security strengths attributes, including algorithm, standard, year, purpose, notes, offered by existing NIST standards in symmetric cryptography, which and deployment recommendations. These tables serve as a prac- NIST expects to offer significant resistance to quantum cryptanalysis, tical guide for migration planning and cryptographic infrastruc- in accordance with the second and third goals above. NIST will create ture design, offering clear recommendations for both classical a distinct category for each of the security standards listed below. and post-quantum contexts based on defined criteria that eval- uate quantum readiness by considering their respective security 1. Any attack that breaks the applicable security criteria must strengths. necessitate computing resources equal to or higher than those required for key search on a 128-bit block cipher (e.g., AES128) Overall, this work bridges existing cryptographic standards with 2. Any attack that breaks the applicable security criteria must use emerging post-quantum requirements, offering a reproducible and ex- computational resources equal to or more than those necessary tensible framework to support informed decision-making by researchers, for collision search on a 256-bit hash function (e.g., SHA256/ policymakers, and practitioners. SHA3-256). 3. Any attack that defies the applicable security criteria must ne- 1.7. Organization cessitate computing resources equal to or higher than those required for key search on a 192-bit block cipher (e.g., AES192) This research paper conducts a comprehensive investigation into 4. Any attack that violates the applicable security requirement cryptographic standards and recommendations across multiple do- must necessitate computing resources equal to or more than mains. The structure of the paper is organized as follows: In Section 2, those necessary for collision search on a 384-bit hash function we review the NIST’s security strength framework to define security (e.g., SHA384 /SHA3-384) levels. Section 3 delves into the realm of ciphers, exploring estab- 5. Any attack that violates the applicable security criteria must lished standards and recommended practices. Section 4 scrutinizes the necessitate computing resources equal to or higher than those cryptographic standards and recommendations for hash and MAC func- required for key search on a 256-bit block cipher (e.g., AES 256) tions, followed by Section 5, which focuses on cryptographic standards and recommendations for digital signatures. The key establishment Computational resources may be quantified using a variety of mea- algorithms are examined in Section 6, while Section 7 explores the sures in this case (e.g., number of classical elementary operations, hybridization of cryptographic primitives, considering the prevailing quantum circuit size, etc.). For a cryptosystem to meet one of the afore- standards and recommendations. We survey the global landscape of mentioned security requirements, any attack must necessitate com- cryptographic standards in Section 8, highlighting the variations across puting resources equal to or greater than the specified threshold for countries. Furthermore, Section 9 addresses lightweight cryptography, all metrics considered by NIST to be potentially relevant to practical and Section 10 delves into authentication standards, including public security. 5 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 3 NIST security levels with classical/quantum security and required gates. Level Algorithm Classicalsecurity Quantumsecurity Classical gates Quantum gates I AES 128: 128bits 64bits 2143 2157 /MAXDEPTH II SHA256/SHA3-256 128bits 80bits 2146 III AES192: 192bits 96bits 2207 2221 /MAXDEPTH IV SHA384/SHA3-384 192bits 128bits 2210 V AES256: 256bits 128bits 2272 2285 /MAXDEPTH NIST proposes restricting quantum attacks to a defined operating 3.1.1. Standards for modes of operation period or circuit depth. This option is known as MAXDEPTH. This Organizations such as NIST, ISO, and ANSI have standardized modes limitation results from the difficulties of performing extremely lengthy of operation that are widely used in various cryptographic libraries and serial calculations. Possible MAXDEPTH values range from 240 logical applications. Several standards for modes of operation are available, gates (the approximate number of gates that currently envisioned quan- each providing different security features. Choosing the right mode of tum computing architectures are expected to serially perform in a year) operation is crucial since each mode has advantages and disadvantages. to 264 logical gates (the approximate number of gates that current clas- Therefore, evaluating the specific requirements of the application is sical computing architectures can serially perform in a decade), with no necessary before selecting an appropriate mode of operation [37]. more than 296 logical gates being possible (the approximate number of It is vital to employ a mode of operation when using a block gates that atomic-scale qubits with the speed of light propagation times cipher such as the Advanced Encryption Standard (AES), which defines could perform in a millennium) [23]. applying the cipher to plaintext. The modes of operation most fre- The complexity of quantum attacks might also be expressed as a quently employed for AES block ciphers are Electronic Codebook (ECB), function of the size of the circuit. These figures can be compared with Cipher Block Chaining (CBC), Counter (CTR), Cipher Feedback (CFB), the resources needed to decrypt AES and SHA3. At the moment, NIST estimates the classical and quantum gate counts for the optimum key Output Feedback (OFB), XEX-based Tweaked Codebook with Ciphertext recovery and collision attacks on AES and SHA3, respectively, when the Stealing (XTS), Galois/Counter Mode (GCM), Cipher-based Message Au- circuit depth is restricted to MAXDEPTH [24,25]. thentication Code (CMAC), and Counter with CBC-MAC (CCM). Several It is worth noting that levels I, III, and V are, for example, char- modes are available for the 3DES cipher block, including TECB-I, TCBC- acterized in terms of block ciphers that can be cracked using Grover’s I, TCFB-I, and TOFB-I. However, it should be noted that these modes technique with a quadratic quantum speedup. However, Grover’s ap- will no longer be allowed after 2023 [37,38]. proach necessitates a lengthy serial calculation, which is difficult to apply in reality. In a genuine attack, numerous smaller instances of the 3.1.2. Modes of operation in quantum algorithm must be performed in parallel, making the quantum speed-up Except for ECB and XTS, the stated modes of operation are recog- less dramatic [23]. nized to be secure against indistinguishability under Chosen Plaintext We have explored the four main types of post-quantum cryptosys- Attack (IND-CPA) in classical settings, provided that the block cipher tems: code-based, lattice-based, supersingular elliptic curve isogeny, used is a Pseudo-Random Function (PRF). Although the security of XTS and hash-based schemes [26,27]. They have been divided into two is uncertain, ECB is generally deemed insecure for many applications main types: encryption candidates and signature candidates. For each for different reasons. The security of ECB can be significantly impacted type, we compare them based on the underlying problem, the claimed by the block size, which determines the amount of data that can be classical security level, the claimed quantum security level, public key safely encrypted using a single key. The ECB mode always generates size, private key size, and signature size. The comparison of the KEM the same ciphertext block for a given plaintext block encrypted with schemes is shown in Table 4. The comparison of the signature-based the same key. When the block size is small, patterns in the plaintext can schemes is shown in Table 5. However, the practicality of Grover-based be exposed in the ciphertext, thereby decreasing the overall security of attacks remains debated, and recent studies highlight challenges such the ECB [39]. as circuit depth, fault-tolerant overhead, and quantum decoherence, all of which significantly limit real-world applicability [24,28]. Con- Regarding quantum computing, two types of IND-CPA notions exist, sequently, while symmetric schemes such as AES-256 and CMAC are namely ‘‘standard IND-CPA’’ and ‘‘IND-qCPA’’. The standard IND-CPA often cited as post-quantum resistant under Grover’s model, such claims security notion allows a quantum attacker to make classical encryption should be interpreted with this caveat in mind. queries. In the classical setting, it remains secure, assuming that the According to the NIST guidelines for classical systems up to 2030 underlying block cipher is a PRF. By contrast, IND-qCPA allows the and beyond, as detailed in the NIST Recommendation for Key Man- attacker to make quantum encryption queries [39]. agement [11], we strongly recommend ensuring the security of all In addition, with IND-qCPA, security is ensured even when messages cryptographic systems based on their equivalence to the security levels are encrypted using the encryption key that is in a superposition state. (refer to Table 3) of classical systems, as mentioned in Tables 4 and 5. The security concept of IND-qCPA aims to offer a type of passive protection by protecting against potential attackers who could gain 3. Cryptographic standards and recommendations for ciphers access to the encryption of specific plaintexts while in a superposition state. In the context of quantum computing, there are two versions 3.1. Block ciphers standards and recommendations of the classical Pseudo-Random Function (PRF): standard secure PRF and quantum secure PRF. In the first version, the function appears to Block ciphers are a crucial building block in cryptography. They be random when classical queries are made. In the second version, are encryption algorithms that use a symmetric key to operate on quantum queries that involve multiple superposition inputs cannot fixed-length data blocks, usually 64 or 128 bits. When using a block cipher to encrypt data bits or plaintext, it is recommended to follow determine the function [39]. a specific mode of operation. Remember that a block cipher can only encrypt a single n-bit string, not a complete message. Additionally, 3.1.3. Recommendations when encrypting a string of data, it is essential to use a mode of As depicted in Table 6, current secure block ciphers offer a variety operation to prevent information from leaking due to repeated patterns of options for cryptographic operations, ensuring robust protection in the data. These modes ensure the encrypted data’s confidentiality for sensitive data. In Table 6, we present cryptographic standards for and integrity. They also prevent specific attacks, such as replay attacks block ciphers, detailing several key columns. For detailed guidelines on and message modification attacks. table columns and cryptographic recommendations, including the basic 6 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 4 Security strength of NIST selected algorithms and 4th round KEM/ENC candidates. Type Algorithm NIST Security level Classical security (bits) Quantum security (bits) CRYSTALS–Kyber-512 1 128 107 Lattice-based CRYSTALS–Kyber-768 3 182 165 CRYSTALS–Kyber-1024 5 256 132 BIKE-L1 1 128 – BIKE-L3 3 192 – BIKE-L5 5 256 – HQC-128 1 128 64 Code-based HQC-192 3 192 96 HQC-256 5 256 128 Classic-McEliece-348864 1 128 – Classic-McEliece-460896 3 192 – Classic-McEliece-8192128 5 256 – Table 5 Security strength of NIST selected signature candidates. Type Algorithm NIST security level Classical security (bits) Quantum security (bits) CRYSTALS–Dilithium2 2 123 112 CRYSTALS–Dilithium3 3 182 165 Lattice-based CRYSTALS–Dilithium5 5 252 229 Falcon-512 1 120 108 Falcon-1024 5 277 252 SPHINCS+ −128 1 128 64 Hash-based SPHINCS+ −192 3 192 96 SPHINCS+ −256 5 256 128 Table 6 Standards for block cipher. Algorithm Standards Year Purpose Note Recommendations Classical PQ (till 2030 & beyond) (Available) (Alternatives) FIPS PUB 2023a Description of AES There are three Rijndael family 197-1 [29] for block ciphers members: AES-128/192/256. Each member converts data into 128-bit blocks, and the numeric suffix indicates the length of the cryptographic keys used. AES AES-128/192/256 AES-256 Camellia-256 ISO/IEC 2020a Encryption algorithms Specifies 128-bit block ciphers: AES, 18033-3 [30] for block ciphers Camellia, SEED ISO/DIS 2017 Banking and related Describes a method of transporting and 20038 [31] financial services – storing cryptographic keys using the Key wrap using AES AES block cipher algorithm. NIST SP 2017 Recommendation for Determines the Triple Data Encryption 800-67r2 [32] the Triple Data Algorithm (TDEA) and its primary Encryption Algorithm component, the Data Encryption (TDEA) Block Cipher Algorithm (DEA). 3DES Disallowed after 2023 (By NIST [32]) ISO/IEC 2018a Security requirements Outlines the encryption systems (known 19790 [33] for cryptographic as ciphers) that are used to maintain modules data confidentiality. RFC 3713 2004 A Description of the Camellia is a 128-bit block cipher Camellia-128/192/256 [34] Camellia Encryption Camellia -256 Algorithm RFC 5529 2009 Modes of Operation Explains how the Camellia block cipher [35] for Camellia for use algorithm is utilized in CTR and CCM Camellia-CBC-128/192/256 Camellia-CBC-256 with IPsec mode as additional, optional-to-implement IKEv2 and ESP AES-256 Camellia mechanisms RFC 4312 2005 The Camellia Cipher Explains how the Camellia block cipher [36] Algorithm and its use algorithm is utilized in CBC mode. Camellia-CTR-128/192/256 Camellia-CTR-256 With IPsec ISO/IEC 2020 Encryption algorithms 128-bit block ciphers: AES, Camellia, 18033-3:2010 for block ciphers SEED Camellia-CCM-128/192/256 Camellia-CCM-256 [30] a Standard was last reviewed and confirmed in the mentioned year. 7 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 criteria we follow, refer to Sections 1.3 and 1.4. Based on these stan- 3.3.1. Standardization dards, for classical security, AES-128/192/256 and Camellia-128/256 We reviewed classical and post-quantum encryption standards for are recommended, while 3DES is disallowed. For post-quantum se- asymmetric cryptography in Table 8 and provided recommendations curity, AES-256 and Camellia-256 are preferred, with Camellia-256 for each standard based on the criteria defined in Section 1.4. serving as a viable alternative if AES-256 is impractical. Recommended The RSA encryption algorithm is extensively used for secure data transmission, digital signatures, and key exchange. The IETF has rec- modes of operation include CBC, CTR, CFB, OFB, GCM, CCM, and ommended guidelines for implementing public-key cryptography using CMAC, while ECB and XTS are discouraged due to security weaknesses, the RSA algorithm, which are standardized in RFC 8017. particularly against quantum attacks. In contrast, Elliptic Curve Cryptography (ECC) leverages the math- ematics of elliptic curves to provide comparable security with signif- 3.2. Stream ciphers standards and recommendations icantly smaller key sizes. ECC has become widely adopted in modern protocols such as SSH, PGP, and TLS. For example, the X25519 curve, which is both efficient and secure, serves as the default key exchange A stream cipher is an encryption method that transforms plaintext method in TLS 1.3 [57]. Furthermore, recent security initiatives have into unreadable code byte by byte, using a proper key. This linear investigated hybrid key-exchange mechanisms that combine classical encryption technique uses the same key for both the encryption and the ECC with post-quantum cryptography to ensure protection against both decryption of messages. Although stream ciphers are not easily cracked, classical and quantum adversaries. Real-world deployments include hy- hackers have found ways to do so. brid key exchange implementations in Google Chrome, Mozilla Firefox, and OpenSSL 3.0, where schemes such as X25519 together with Kyber ChaCha20 is a widely used symmetric cipher, but it does not provide are tested in production to achieve a balance between performance and resistance against post-quantum attacks. Under a quantum adversary forward-looking security. model, Grover’s algorithm yields a quadratic speedup for exhaustive On the other hand, NIST is actively working on standardizing key search (reducing a 256-bit key to 128-bit effective security), and post-quantum algorithms and has conducted several rounds of eval- concrete quantum resource estimates for applying Grover’s algorithm to uations with their respective results. In 2022, NIST announced that ChaCha20 have been published [40]. For more details on the relevant the CRYSTALS-KYBER key encapsulation algorithm to be standardized, standards, see Table 7. along with four alternative KEM algorithms (Classic McEliece, HQC, AES is inherently a block cipher with a fixed block size of 128 bits. BIKE, and SIKE) [6]. However, several standardized modes of operation enable it to function as a stream cipher. Specifically, CTR, OFB, and CFB modes transform 3.3.2. Recommendations AES into a keystream generator, allowing bit- or byte-oriented encryp- The asymmetric encryption standards and specifications are listed in Table 8, including both classical and post-quantum algorithms. These tion similar to conventional stream ciphers. Among these, CTR mode is standards and specifications are crucial for securing communication the most widely used due to its efficiency, parallelizable structure, and applications, such as email and web security, as well as other en- identical procedures for encryption and decryption. All three modes cryption systems that require key exchange over public networks. By (CTR, OFB, and CFB) are approved by NIST in SP 800-38 A, confirming following these recommended standards and algorithms (as per the their suitability for secure data encryption applications that require criteria defined in Section 1.4), users can enhance the security of their stream-like processing. cryptographic systems and protect against potential future threats. 3.3.3. Use-case: Phased RSA to kyber migration in financial systems 3.2.1. Recommendations A global bank aims to strengthen its public-facing TLS infrastruc- Stream ciphers are designed for fast, bytewise encryption and are ture against prospective quantum threats by transitioning from clas- well suited to low-latency applications (e.g., streaming media, VoIP, sical RSA-2048 key exchange to hybrid RSA plus Kyber1024 hand- and real-time data channels). Care must be taken to prevent key shake, in accordance with emerging IETF draft ciphersuites and NIST or nonce reuse, as keystream compromise can catastrophically break guidance [58]. confidentiality. Table 7 summarizes the relevant standards. 1. Phased migration plan. Among stream-cipher-style constructions, we recommend AES-CTR/ OFB/CFB with a 256-bit key as the sole option to retain a conser- P1 Inventory and Compatibility. Identify all Internet-facing end- vative security margin against quantum adversaries (via Grover-type points. Enable hybrid ciphersuites on pilot load balancers and conduct TLS 1.3 interoperability tests with major browsers and search), assuming proper nonce uniqueness and high-entropy keys. HSM firmware. Classical stream ciphers (e.g., ChaCha20, RC4, Trivium, Grain, Rabbit) P2 Parallel Deployment. Serve dual RSA and Kyber key shares do not provide post-quantum resistance and should be restricted to during the handshake. Legacy clients utilize the RSA share, while classical threat models. For confidentiality and integrity, pair AES- quantum-ready clients process the Kyber share. CTR/OFB/CFB (256) with a strong MAC in an encrypt-then-MAC com- P3 Gradual Client Rollout. Employ feature flags and canary re- position or use an AES-based AEAD where available. leases to incrementally expand hybrid support. Monitor latency and certificate-chain telemetry to ensure performance and sta- bility. 3.3. Asymmetric ciphers standards and recommendations P4 Legacy Retirement. Once at least 95% of sessions negotiate the Kyber share, deprecate pure RSA ciphersuites and rotate Asymmetric ciphers provide a way to achieve secure communication remaining keys. between two parties without sharing a secret key, making it easier 2. Performance & bandwidth impact. Recent evaluations show that Ky- to establish secure communication between parties who have never ber1024 introduces minimal computational overhead compared to clas- communicated before. However, asymmetric ciphers, which require a sical RSA operations on commodity servers, remaining within accept- pair of keys for encryption and decryption, are generally slower and able latency thresholds for time-sensitive applications such as online less efficient than symmetric ciphers that use a single key. Additionally, banking and trading [58]. Furthermore, hybrid Kyber+ RSA hand- asymmetric ciphers require more computational power and resources, shakes have comparable message sizes to traditional RSA-only profiles, which can be a disadvantage in resource-limited environments. avoiding bandwidth penalties for mobile or low-power clients. 8 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 7 Standards for stream cipher. Algorithm Standard Year Purpose Note Recommendations Classical PQ (till 2030 & beyond) (Available) (Alternatives) RFC 8439 [41] 2018 Defines the ChaCha20 stream Describes the ChaCha20 stream cipher as well as the use of cipher and Poly1305 the Poly1305 authenticator authenticator as stand-alone algorithms or Authenticated Encryption with Associated Data (AEAD) algorithm. ChaCha20 RFC 8103 [42] 2017 Using ChaCha20-Poly1305 Outlines the guidelines for ChaCha20 AES-CTR/OFB/CFB (256) Authenticated Encryption in utilizing ChaCha20-Poly1305 the Cryptographic Message Authenticated Encryption Syntax (CMS) within the Cryptographic Message Syntax (CMS). RFC 7905 [43] 2016 ChaCha20-Poly1305 Cipher Explains how the ChaCha Suites for Transport Layer stream cipher and Poly1305 Security (TLS) authenticator are utilized in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. RFC 7634 [44] 2015 ChaCha20, Poly1305, and ChaCha20 stream cipher and Their Use in the Internet Key Poly1305 authenticator Exchange Protocol (IKE) and combined into AEAD algorithm IPsec for IKEv2 and IPsec RFC 6229 [45] 2011 Vectors for the Stream Cipher Includes test vectors designed RC4 for the RC4 stream cipher. ISO/IEC 18033-4:2011 [46] 2022a IT - Security techniques - Specifies how to combine a RC4 Encryption algorithms - Part 4: keystream with plaintext and RC4 is not recommended Stream ciphers provides keystream generators for producing the keystream. IEEE 802.11i-2004 [47] 2004 Wireless LAN Medium Access Defines MAC and PHY Control (MAC) and Physical specifications for wireless Layer (PHY) specifications: connectivity for STAs within a Amendment 6: Medium Access local area. Control (MAC) Security Enhancements ISO/IEC 29192-3:2012 [48] 2018a IT - Security techniques - Defines lightweight keystream Enocoro Lightweight cryptography - generators with 80 or 128-bit Enocoro-128 AES-CTR/OFB/CFB (256) Part 3: Stream ciphers key size for stream ciphers ISO/IEC 29192-3:2012 [48] 2018a IT - Security techniques - Two dedicated keystream Lightweight cryptography - generators are specified for Part 3: Stream ciphers lightweight stream ciphers: Trivium Trivium, with a key size of 80 None AES-CTR/OFB/CFB (256) bits NISTIR 8114 [49] 2018a Presents a summary of NIST’s Outlines proposals for the lightweight cryptography standardization of lightweight project. cryptographic algorithms. ISO/IEC 29167-13:2015 [50] 2021a Specifies the Crypto Suite for ISO committees may refer to Grain-128A for RFID devices this common crypto suite for based on the ISO/IEC 18000 RFID devices used in air Grain air interface standards interface and application Grain-128AEAD AES-CTR/OFB/CFB (256) standards. NISTIR 8369 [51] 2021 Select one or more AEAD Authenticated Encryption with schemes with optional hashing Associated Data (AEAD) for constrained environments. (continued on next page) 3. Key-management considerations. The referenced evaluation classi- path if post-quantum parameters or standards evolve, all without the fies Kyber key material in the low-size category, meaning it already protocol-level upheaval sometimes necessary for larger post-quantum fits within standard X.509 v3 extensions with no format changes re- key sets. quired. Migration, therefore, focuses on light-touch updates, regis- 4. Benefits. The approach delivers quantum resilience without disrupt- tering new post-quantum OIDs in certificate transparency logs, and ing legacy ecosystems, satisfies payment-card and regulatory crypto- enabling PQC-aware keywrap support in HSM s, rather than whole- agility requirements, and aligns with the algorithm-selection frame- sale PKI redesign. The operation of TLS in a hybrid RSA+ Kyber work that identifies Kyber as the top-performing KEM for financial keeps legacy clients working while providing an immediate rollback use-cases [58]. 9 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 7 (continued). Algorithm Standard Year Purpose Note Recommendations Classical PQ (till 2030 & beyond) (Available) (Alternatives) ISO/IEC 18033-4:2011 [46] 2022a IT - Security techniques - Specifies the functions that Encryption algorithms - Part 4: combine a keystream with Stream ciphers plaintext, as well as the Rabbit keystream generators used to Rabbit-128 AES-CTR/OFB/CFB (256) produce the keystream. RFC 4503 [52] 2006 A Description of the Rabbit Provides information for the Stream Cipher Algorithm Internet community. It does not specify an Internet standard of any kind RFC3686 [53] 2018a AES can act as a stream Explains how to use AES AES- AES- AES- AES cipher using CTR, OFB, or CFB Counter Mode with an explicit CTR/OFB/CFB CTR/OFB/CFB CTR/OFB/CFB modes. CTR mode is the most initialization vector as an IPsec (128, 192, 256) (256) (256) efficient. Encapsulating Security Payload confidentiality method. a Standard was last reviewed and confirmed in the mentioned year. Table 8 Encryption standards for asymmetric cryptography. Algorithm Standards Year Purpose Recommendations Classical PQ (till 2030 & beyond) (Available) Alternatives RSA IETF RFC 8017 [54] 2016 PKCS #1: RSA Cryptography MS ≥ 3072 ∙ NIST’s KEM PQC (Specifications) ∙ Quantum-safe Hybrid PKE ECC PKCS #13 1998a ECC Standard KS ≥ 256 SM2 ISO/IEC 14888 [55] 2018 Provide secure digital KS ≥ 256 signatures and key exchange Kyber Kyber-512/768/1024 Kyber-768/1024 McEliece-256, HQC-256, BIKE-256 NISTb 2022 Encapsulation McEliece McEliece-128/192/256 McEliece-256 Kyber-768/1024, HQC-256, BIKE-256 HQC HQC-128/192/256 HQC-256 Kyber-768/1024, McEliece-256, BIKE-256 BIKE BIKE-128/192/256 BIKE-256 Kyber-768/1024, McEliece-256, HQC-256 SIKE Not Recommended Note: Abbreviations are defined as follows: KS: Key Size and MS: Modulus Size. + The Chinese national standard GM/T 0003-2012 was subsequently adopted and harmonized into the international standard ISO/IEC 14888. a Apparently abandoned, only reference is a proposal from 1998. b In 2022, NIST completed the 4th round of the PQC standardization process [56]. Later, on August 13, 2024, NIST released the final versions of the first three post-quantum cryptography standards: FIPS 203, FIPS 204, and FIPS 205, including Kyber. 3.3.4. Use-case: PQC rollout aligned with EO 14144 for federal systems transport, DNS resolvers), record current vendor/firmware and A Federal Civilian Executive Branch (FCEB) agency that operates PQC capability status [10]. citizen-facing API gateways must comply with Executive Order 14144, E2 Procurement Requirements. For any solicitation issued after which (i) directs CISA to publish a list of product categories where a category appears on CISA’s list, include a requirement that post-quantum cryptography is widely available; (ii) requires agencies products support PQC (with a 90-day window from listing) [10]. to include PQC-support in solicitations for any such product categories E3 Enable PQC/Hybrid as Soon as Practicable. Where deployed within 90 days; (iii) mandates implementation of PQC key establish- products already provide support, enable PQC key establishment ment or hybrid key establishment (including a PQC algorithm) as soon (e.g., ML-KEM) or hybrid key establishment including a PQC al- as practicable when supported by deployed network-security products; gorithm on external and internal TLS 1.3 endpoints, prioritizing and (iv) requires TLS 1.3 (or its successor) support by January 2, public-facing API gateways and cross-agency interfaces [10]. 2030 [10]. E4 TLS Baseline. Ensure agency systems support TLS 1.3 (or its successor) no later than January 2, 2030 (OMB for non-NSS; DoD 1. Compliance-driven migration plan (per EO 14144). for NSS), with configuration baselines updated accordingly [10]. E1 Track PQC-Available Categories. Monitor CISA’s list of product E5 Audit Evidence. Log negotiated key-exchange groups categories where PQC is widely available (due within 180 days (e.g., X25519ML-KEM768), certificate OIDs/policies, and con- of the executive order). For each in-scope category already figuration state to the SIEM to demonstrate conformance with deployed (e.g., TLS terminators, service-mesh gateways, email EO timelines and solicitation clauses [10]. 10 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 9 Performance evidence supporting EO 14144 compliance: Observed PQC/hybrid impacts for TLS 1.3 show modest overhead, validating the practicability of near- term federal deployment. TTLB: Time-To-Last-Byte. Handshake overhead from Chrome desktop rollout [59]; TTLB results from MADWeb’24 [60]; broader PQ-TLS performance from CCS’23 [61]. Context KEX/Auth Median Handshake Overhead TTLB Overhead (typical) Key/Msg Size (on-wire) Source Web desktop (field) X25519+ML-KEM-768 (hybrid), ECDSA ∼4% – ClientHello split [59] Stable high-bw nets ML-KEM-768, ML-DSA-44/65 – <5% TTLB ∼10 KB handshake [60] Low-bw (50 KiB+ data) ML-KEM-768, ML-DSA-44/65 – <15% TTLB ∼11–14 KB auth [60] Emulated Web envs Kyber/HQC; Dilithium/Falcon On par w/ classical No hybrid drawback Param-dependent [61] 2. Performance & bandwidth impact. Published field measurements and 4.2. Message authentication codes standards controlled studies report modest overheads for PQC and hybrid key ex- changes in TLS 1.3. Chrome’s desktop rollout of hybrid Kyber reports a The financial sector utilizes MACs to protect the integrity and median ∼4% handshake-latency increase due to ClientHello size (packet millions of daily banking communications, as well as to verify the split), while broader studies show that overall time-to-last-byte (TTLB) authenticity of mobile phones. In order for a MAC algorithm to be impact diminishes as payload size grows [59–61] (see Table 9). effective, it must meet the specific requirements outlined in ISO/IEC 9797-1. This standard requires that a MAC algorithm demonstrate the 3. Key-management & protocol notes. EO 14144 allows agencies to adopt following two properties: hybrid key establishment including a PQC algorithm while existing au- thentication remains classical, easing near-term deployment on current • MAC generation from the plaintext message and a secret key must PKI/HSM stacks. Agencies should prefer TLS 1.3 key-exchange groups be straightforward (usability). that are listed by vendors as compliant with EO-aligned PQC categories • It must be practically impossible to derive an MAC for a particular (e.g., X25519+ML-KEM-768) and should record policy/OID usage for plaintext message without authorized access to the secret key, auditing purposes [10]. even if the intruder has access to accurate MACs for various other messages, including some that the attacker may choose (security). 4. Benefits. This plan directly satisfies EO 14144’s procurement trig- gers and deployment timelines, achieves harvest-now/decrypt-later risk ISO/IEC 9797 is an extensive collection of standardized MAC algo- reduction via PQC/hybrid key establishment, and keeps latency within rithms, divided into three parts. Part 1 comprises six distinct variants measured bounds for public services [10,59,60]. of CBC-MAC. On the other hand, Part 2 and Part 3 encompass a range of MAC techniques that rely on hash functions. 4. Cryptographic standards and recommendations for hash and 4.3. Hash and MAC functions recommendations MAC functions Tables 10 and 11 list the standards and specifications for the hash A hash function is a mathematical computational procedure that can and MAC functions. Hash functions provide information on the relevant accept inputs of any size and produce a consistent hash code of a prede- standards and offer recommendations for their usage in applications termined length that is hard to predict. In cryptography, hash functions such as digital signatures, password storage, and data integrity checks are peculiar in that they usually do not depend on secret keys, and to ensure data integrity. However, MAC functions provide information therefore their use is restricted to a limited range of security services. on relevant standards and offer recommendations for their usage in As a result, they are often used as a basis for other security systems. If applications such as network communication protocols, payment sys- a weak hash function is employed, the security of the overall scheme tems, and digital rights management systems to ensure data integrity is undermined. Hash functions are utilized to ensure data integrity and authenticity. By adhering to the recommended algorithms and in Message Authentication Codes (MACs), create message digests to standards for hash and MAC functions (as per the criteria defined support digital signature schemes, and generate manipulation detection in Section 1.4), users can enhance data protection and secure their codes in key establishment and entity authentication procedures. In this cryptographic systems against potential threats. Our assumption for section, we reviewed Hash and MAC function standards in Tables 10 hash functions is based on prioritizing the highest level of security in and 11, and provided recommendations for specific standards based on the context of potential quantum threats. We consider NIST Level 5 the criteria defined in Section 1.4 . as the minimum requirement because it provides the strongest pro- tection against both classical and quantum attacks. Level 5 ensures 4.1. Hash functions standards that cryptographic algorithms maintain their security even against powerful quantum computers. Therefore, we do not classify SHA-384 as quantum-resistant, as it does not meet the stringent security standards Three major organizations, ISO/IEC JTC1, NIST, and IETF, have required for NIST Level 5. We view SHAKE256 as offering a degree developed widely recognized hash function standards, indicating a of quantum resistance when used with longer message digests, such significant level of standardization in this area. as 512 bits or more. Although SHAKE256 alone does not provide The NIST secure hash standard, also known as NIST FIPS Pub. 180, complete quantum resistance, utilizing it with longer output lengths has been amended many times, with the most recent version (NIST helps mitigate the impact of quantum attacks, including those posed FIPS Pub. 180-4) released in 2015. This standard defines specialized by Grover’s algorithm, which effectively reduces security levels. hash functions such as SHA-1, SHA-224, SHA-256, SHA-384, and SHA- 512. The length of the message digests can range from 160 to 512 5. Cryptographic standards and recommendations for digital sig- bits, depending on the algorithm used. The adoption of hash func- natures tions has been standardized by the IETF. The SHA family is one of their standardized hash functions and is widely used. However, it is Digital signatures have several important properties that make them recommended to avoid using SHA-1 for such purposes, as it can no a powerful tool for ensuring the authenticity and integrity of digital longer guarantee strong cryptographic security. Instead, more secure documents and messages. These properties, such as security, efficiency, and advanced hashing algorithms, such as SHA-256 or SHA-3, should integrity, and authentication, make it an essential tool to ensure the be utilized to ensure the confidentiality and integrity of sensitive data. security and authenticity of digital transactions. 11 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 10 Standards for hash functions. Algorithm Standards Year Purpose Recommendations Classical PQ (till 2030 & beyond) (Available) (Alternatives) IETF RFC 3174 [62] 2001 Secure Hash Algorithm 1 SHA-1 NIST deprecated the use of SHA-1 The USA Secure Hash Algorithms suite includes IETF RFC 6234 [63] 2011 SHA, SHA-based HMAC, and HKDF b SHA-1 and SHA-2 NIST FIPS Pub. 180-4 [64] 2015 Secure Hash Standard for both SHA-1 and SHA-2 Permutation-based hash functions (SHA-3-224, SHA-3 SHA-3-256, SHA-3-384, SHA-3-512) NIST FIPS Pub. 202 [65] 2015 Extendable-Output functions (SHAKE128 and SHA-2/SHA-3 SHAKE SHAKE256) Provides an explanation of the BLAKE2 HL ≥ 256 HL ≥ 512 BLAKE2 IETF RFC 7693 [66] 2015 cryptographic hash function Provide a secure and efficient cryptographic SM3 draft-sca-cfrg-sm3-01 [67] 2018 hash function for data integrity verification and digital signatures ISO/IEC 101184: 1998 [68] 2022a Security techniques for Hash-functions (using modular arithmetic) HASHc Security techniques for dedicated hash ISO/IEC 10118-3 [69] 2018 functions Note: Abbreviations are defined as follows: HL: Hash Length. a Standard was last reviewed and confirmed in the mentioned year. b In 2023, NIST decided to revise FIPS 180-4. c Comprises a set of security and cryptography standards designed explicitly for HASH. Several digital signature algorithms are widely used in practice. The for creating and verifying digital signatures using the DSA. The choice of digital signature algorithm depends on various factors, such as DSA is a public key cryptography algorithm that is based on security requirements, performance considerations, and compatibility the discrete logarithm problem. It uses a pair of keys, a private with existing systems. key and a public key, to sign and verify digital signatures. DSS The digital signature employs three primary algorithms: key gener- specifies the key sizes, hash algorithms, and other parameters ation, signing, and verification algorithms. It is important to note that required for creating and verifying DSA digital signatures. DSS-5, the security of the digital signature system depends on the confidential- the latest version of the DSS, specifies the DSA for creating and ity of the private key. If the security of the private key is compromised, verifying digital signatures. malicious entities can generate fraudulent digital signatures that appear • NIST SP 800-131 A Rev. 2 [87] is the revised version of NIST legitimate. Therefore, strong cryptographic algorithms and the follow- SP 800-131 A. Includes updated guidelines for the use of cryp- ing best practices for key management and storage are essential. In tographic algorithms and key sizes. Specifically, stronger elliptic addition, it is crucial to update the keys to maintain system security curves and larger key sizes are now recommended for RSA and periodically. DSA. The updated guidelines also provide additional guidance on Various cryptographic algorithms are available to generate pub- using the SHA-256 and SHA-384 hash functions and recommend lic and private keys within digital signature systems. Examples of using validated entropy sources for random number generation. algorithms that are frequently utilized to generate keys for digital Finally, the guidance on the use of digital certificates has been signatures include Rivest-Shamir-Adleman (RSA), Digital Signature Al- clarified and updated to include recommendations for the use of gorithm (DSA), Elliptic Curve Digital Signature Algorithm (ECDSA), Certificate Transparency and Online Certificate Status Protocol and Edwards-curve Digital Signature Algorithm (EdDSA). (OCSP) to enhance certificate revocation checking. It also pro- vides guidance on the transition to more secure cryptographic 5.1. Digital signature standards algorithms and key sizes and best practices for key management, digital signatures, and other security-related processes. It con- Digital signature standards are rules and criteria that specify how tains a plan to phase out the use of the Triple Data Encryption digital signatures should be created and verified to guarantee their Algorithm (TDEA). security and interoperability. Several organizations and governments • ANSI X9.30.1 [88] is a standard published by the Accredited around the world have developed different digital signature standards. Standards Committee (ASC) X9 of the ANSI. The standard speci- Some of the commonly used digital signature standards include the following: fies the requirements for financial institutions and payment pro- cessors to securely exchange Electronic Funds Transfer (EFT) data • Public Key Cryptography Standard#1 (PKCS#1) is a widely over public networks. used standard for RSA digital signatures. It defines the syntax and The purpose of the standard is to ensure and maintain a high structure of digital signatures using RSA encryption. level of security for EFT transactions. It is widely used in the • Digital Signature Standard (DSS) is a US government standard financial industry for secure electronic payments and other types developed by NIST for DSA. The DSS specifies the requirements of financial transactions. 12 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 11 Standards for symmetric digital signature and MAC. Algorithm Standards Year Purpose Recommendations Classical PQ (till 2030 & beyond) (Available) (Alternatives) NIST SP 800-131A Rev. 1 2015 [70] CMAC-AES AES-128,192,256 AES-256 ISO/IEC 15946-5 [71] 2022a ISO/IEC 19790 [72] 2018a Symmetric ISO/IEC 24727 [73] 2021a NIST SP 800-131A Rev. 1 2015 CMAC-3DES [70] Disallowed after 2023 ISO/IEC 19790[72] 2018a ISO/IEC 24727 [73] 2021a ISO/IEC 29192-6:2019 [74] 2019 IT Lightweight cryptography for MACs (Part 6) MACb ISO/IEC 9797-3: 2011/Amd 2020 Security techniques for MACs (universal 1: 2020 hash-function) ISO/IEC 9797-2: 2021 [75] 2021 Info. Security for MACs (dedicated hash-function) ISO/IEC 9797-1: 2011 [76] 2022a Security techniques for MACs (using a block cipher) IETF RFC 2202 [77] 1997 Test cases for HMAC-MD5 and KS ≥ 128 and HL ≥ 256 KS ≥ 256 and HL ≥ 512 HMAC HMAC-SHA-1 NIST FIPS 1981 [78] 2008 Keyed-Hash Message Authentication Code (HMAC) IETF RFC 6151 [79] 2011 Updated Security Considerations for the HMAC-MD5 cSHAKE, NIST SP 800-185 [80] 2016 SHA-3 Derived Functions KMAC, TupleHash, and ParallelHash BLAKE2 IETF RFC 7693 [66] 2015 Provides an explanation of the BLAKE2 cryptographic hash function and Message Authentication Code Poly1305 RFC 8439 [41] 2018 Describes the utilization of the Poly1305 authenticator Note: Abbreviations are defined as follows: KS: Key Size and HL: Hash Length. a Standard was last reviewed and confirmed in the mentioned year. b It comprises a set of security and cryptography standards designed explicitly for MACs. • ANSI X9.62 [81] is a ANSI standard published by the ASC X9. must be generated using a cryptographic random number The standard specifies the requirements for the ECDSA, a crypto- generator. (ii) The key size for the private key should be at graphic algorithm for generating digital signatures. ANSI X9.62 least 160 bits. (iii) The key size for the public key depends defines the mathematical operations used in ECDSA and the on the size of the elliptic curve domain parameters. For procedures for generating and verifying digital signatures. The example, if the elliptic curve has a 160-bit prime field, the standard also specifies the parameters for elliptic curves that can public key should be at least 160 bits. (iv) The security level be used with ECDSA and the key generation and management of the ECDSA algorithm is related to the size of the elliptic requirements. Overall, ANSI X9.62 provides a comprehensive curve domain parameters. The standard recommends using elliptic curves with a security level equivalent to at least 112 standard for the ECDSA and is widely used in the financial bits (the same level of security as a 3072-bit RSA key). industry and other applications where secure digital signatures – ISO/IEC 9796-3 [84] specifies digital signature schemes are required. that use a hash function, such as DSA and the RSA digital • IEEE 1363 [89] is a standard published by the IEEE for public signature algorithm. key cryptography. It specifies several digital signature algorithms, – ISO/IEC 15946-5 [71] is the latest version of ISO/IEC including the DSA and ECDSA. 15946, a standard specifying digital signature schemes based • ISO/IEC JTC1 [90] is significant in developing international on ECC. It defines multiple digital signature schemes that standards for digital signatures, ensuring that the algorithms and utilize elliptic curve cryptography, such as the ECDSA and protocols are secure, interoperable, and usable in a wide range the EdDSA. of applications. It has developed several standards related to dig- – ISO/IEC 19790:2012 [33] can accommodate various cryp- ital signature, including ISO/IEC 14888, ISO/IEC 9796, ISO/IEC tographic algorithms, such as symmetric-key cryptography, 15946, ISO/IEC 19790, and ISO/IEC 24727. public-key cryptography, and elliptic curve cryptography. It is recommended to use keys with a minimum length – ISO/IEC 14888-3 [55] defines the ECDSA digital signature of 112 bits for symmetric encryption algorithms like AES algorithm for use with elliptic curve cryptography. The and a minimum of 2048 bits for public key cryptography standard defines the key size requirements for the ECDSA al- algorithms such as RSA. This standard was last reviewed and gorithm as follows: (i) The elliptic curve domain parameters confirmed in 2018. 13 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 12 Standards for asymmetric digital signature. Algorithm Standards Year Purpose/Type Recommendations Classical PQ (till 2030 & beyond) (Available) (Alternatives) ANSI X9.62 [81] 2023 ECDSA IEEE 1363 (I) [82] 2004 KS ≥ 256 FIPS 186-5 [83] 2023 RFC 8017 2016 PQ Signature ISO/IEC 9796-3 [84] 2018a RSAES-PKCS1-v1_5 Asymmetric (Dilithium ISO/IEC 14888-1 [85] 2019a Not Quantum- 3/5, ISO/IEC 15946-5 [71] 2022a Resistant Falcon-1024, RFC5756 [86] 2010 MS ≥ 3072 SPHINCS-256) ISO/IEC 24727 [73] 2021a RSASSA-PSS NIST-DSS(FIPS 186-5) [83] 2023 RFC 8017 [54] 2016 IEEE 1363 [82] 2004 RSA-OAEP RFC5756 [86] 2010 Dilithium Dilithium 2/3/5 Dilithium 3/5 Falcon-1024, NIST [56] 2022b Post-Quantum SPHINCS-256 Falcon Falcon-512/1024 Falcon-1024 Dilithium 3/5, SPHINCS-256 SPHINCS+ SPHINCS-128/192/256 SPHINCS-256 Dilithium 3/5, Falcon-1024 (𝐼) Represents Inactive. Note: Abbreviations are defined as follows: KS: Key Size and MS: Modulus Size. Note: RSASSA-PSS combines the RSASP1 and RSAVP1 primitives with the EMSA-PSS encoding method. Similarly, RSASSA-PKCS1-v1_5 combines the RSASP1 and RSAVP1 primitives with the EMSAPKCS1-v1_5 encoding method. a Standard was last reviewed and confirmed in the mentioned year. b Algorithms selected for standardization this year. Later in 2024, NIST finalized the first three post-quantum cryptography standards: FIPS 203, FIPS 204, and FIPS 205, which include Dilithium and SPHINCS+. – ISO/IEC 24727-1:2014 It defines a common framework for of Symmetric, Hash-Based, Asymmetric, and Post-Quantum algorithms Identity Management (IdM) systems. This standard was last usable in the digital signature, with their properties, such as stan- reviewed and confirmed in 2021. Therefore, this version dardization body, last version publication date, type, and our rec- remains current. ommendations in terms of classical and post-quantum based on the criteria defined in Section 1.4. As presented, asymmetric algorithms • FIPS 186 is a US government standard for digital signature al- such as RSA, DSA, and ECDSA are not quantum-resistant. In addition, gorithms. It specifies the requirements for creating and verifying symmetric algorithms will prohibit the use of 3DES after 2023. digital signatures using the DSA and the RSA algorithm. FIPS 186-4 [91] specifies several key sizes that can be used with 5.2. Recommendations the DSA and the ECDSA. DSA is a widely used algorithm for generating digital signatures and is based on the difficulty of The different algorithms used in the digital signatures in Table solving the discrete logarithm problem. The standard specifies 12 ensure that authenticity and integrity are maintained securely and the following key sizes: 2048, 3072, and 4096 bits. ECDSA is a reliably. These algorithms also provide valuable information on the newer algorithm based on elliptic curve cryptography. It is known standards that should be followed and offer recommendations on how for its efficiency and smaller key sizes; the standard specifies they can be used in various applications, such as digital documents, the following key sizes: 224, 256, 384, and 521 bits. It will be messages, and transactions. To ensure the authenticity and integrity of withdrawn on February 03, 2024. the data, users can improve secure and reliable verification methods For financial applications, a key size of 3072 bits or higher is by following the recommended algorithms and standards for digital recommended by some security experts. This provides a high level signatures. Our recommendations for post-quantum algorithms (based of security against brute-force attacks and other types of attacks. on the criteria defined in Section 1.4) are aligned with the NIST stan- However, it is important to note that the larger key sizes may also dardized algorithms. Dilithium, Falcon, and SPHINCS+ are considered impact the performance and scalability of the system. secure in both classical and post-quantum contexts, with adjustments In addition to DSA and ECDSA, FIPS 186-5 [83] specifies several other cryptographic algorithms for key generation and encryp- to their security levels. tion. These include the Secure Hash Algorithm (SHA) family of hash functions, the AES for symmetric encryption, and the RSA 6. Cryptographic standards and recommendations for key estab- algorithm for key exchange and digital signatures. lishment • X.509 [11] is a standard for digital certificates that includes Key establishment is a critical aspect of cryptography, enabling digital signature specifications. It defines the format and structure of digital certificates used to verify the signer’s identity. They secure communication between two or more parties. It involves the are used to verify the identity of a party in a communication, process of generating, exchanging, and managing cryptographic keys. authenticate the parties involved, and ensure the confidentiality The Key establishment can be broadly categorized into three primary and integrity of the communication. techniques: key exchange, key transport, and post-quantum key encap- sulation. Table 12 lists a comprehensive checklist of standards and speci- Key exchange is a method through which two or more parties fications used for digital signatures. This table illustrates a summary can securely establish a shared secret key, which is then used for 14 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 13 Standards for key establishment algorithms: A comparison of standards and recommendations for key exchange, key transport, and post-quantum key encapsulation. Algorithm Standards Issue year Purpose/type Recommendations Classical PQ (till 2030 & beyond) (Available) (Alternatives) ANSI-X9.63 [92] 2017 ANSI-X9.42 [93] 2013 DH Agreement 256, 3072 KEM RFC-2631 [94] 1999 NIST SP-800-56A [95] 2018 NIST SP-800-56A [95] 2018 RFC 7748 [96] 2016 Not ECDH Agreement 256, 3072 KEM RFC 6278 [97] 2011 Quantum-Resistant ISO/IEC 18033-1 [98] 2021 ANSI X9.63 (I) [92] 2017 MQV IEEE-P1363 (I) [99] 2000 Agreement 256 KEM NIST SP-800-56A [95] 2018 NIST.SP.800-56Br2 [100] 2019 RSA Transport 3072 KEM NIST.SP.800-131Ar2 [101] 2019 Kyber NIST-PQC [6,13,56] 2022 Encapsulation Kyber- Kyber-768 (key size: McEliece(6944,5208,136), 512/768/1024 9472), Kyber-1024 BIKE-192(149), (key size: 12544) BIKE-256(189), HQC-256(128) McEliece NIST-PQC [56] 2022 Encapsulation McEliece- (𝑛, 𝑘, 𝑡) ∶ (6944, 5208, Kyber-768, Kyber-1024, 128/192/256 136) BIKE-192(149), BIKE-256(189), HQC-256(128) HQC NIST-PQC [56] 2022 Encapsulation HQC- HQC-256(128) Kyber-768, Kyber-1024, 128/192/256 BIKE-192(149), BIKE-256(189), McEliece(6944,5208,136) BIKE NIST-PQC [56] 2022 Encapsulation BIKE- BIKE-192(149), Kyber-768, Kyber-1024, 128/192/256 BIKE-256(189) McEliece(6944,5208,136), HQC-256(128) SIKE NIST-PQC [56] 2022 Encapsulation Not recommended (𝐼) Represents Inactive. subsequent encryption and decryption of messages. A popular key 5. The encapsulated key can then be used for symmetric encryption exchange algorithm is the Diffie–Hellman (DH) protocol. DH is a public- and decryption of messages. key cryptosystem that allows two users to generate a shared secret key, even if they are communicating over an insecure channel. The security Key establishment is a fundamental aspect of secure communication of DH relies on the difficulty of solving the discrete logarithm problem. in cryptography. Key exchange, key transport, and post-quantum key Key transport refers to the process of securely transmitting a cryp- encapsulation are three techniques that enable the secure generation, tographic key from one party to another. This technique often employs transmission, and management of cryptographic keys. By understand- public-key cryptography to protect the key during transmission. In a ing these methods and selecting the most suitable approach for a given typical scenario, the sender encrypts the key with the recipient’s public scenario, secure communication can be achieved, protecting sensitive key, and the recipient decrypts it using their private key. The RSA information from unauthorized access and ensuring robustness against cryptosystem is commonly used for key transport. potential quantum computer threats. Post-quantum key encapsulation is a technique that employs asym- metric cryptographic algorithms believed to be resistant to quantum 6.1. Key establishment standards computer attacks. Quantum computers have the potential to solve certain problems much faster than classical computers, which could In this section, we will explore several key establishment stan- potentially break widely used cryptographic schemes such as RSA dards, including those developed by ANSI, IETF, NIST, ISO, etc. These and ECC. Post-quantum Key Encapsulation Mechanisms (KEMs) are standards provide guidelines for the implementation of secure key designed to provide key establishment that remains secure even in establishment schemes, including symmetric and asymmetric key al- the presence of quantum computers. One notable post-quantum KEM gorithms, key management practices, and protocols for key exchange is the kyber-based KEM. Kyber is a lattice-based cryptosystem that is and transport. Additionally, we will examine the emerging field of considered to be resistant to quantum attacks. The kyber-based KEM post-quantum cryptography and the ongoing efforts to develop key es- operates as follows: tablishment algorithms that can resist attacks from quantum computers. Table 13 outlines these standards and offers recommendations based on 1. The recipient generates a public/private key pair based on the the criteria defined in Section 1.4. kyber algorithm. 2. The sender generates a random ‘‘encapsulated key’’ and encrypts • ANSI X9: In 1985, ANSI released its initial standards related to it using the recipient’s public key, creating a ciphertext. key management, including ANSI X9.17 [102] and ANSI X9.24 3. The sender transmits the ciphertext to the recipient. [103]. These standards were designed to address the key manage- 4. The recipient decrypts the ciphertext using their private key to ment issues facing financial institutions. Specifically, ANSI X9.17 obtain the encapsulated key. focused on key management between banking establishments, 15 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 while ANSI X9.24 dealt with key management between retail The purpose of this standard is to establish a common foundation devices and the financial institutions that managed them, such for the development, evaluation, and comparison of encryption as point-of-sale devices. algorithms and protocols, ensuring secure communication and data protection. – ANSI X9.17 [102]: This standard was primarily aimed at • NIST SP 800-56B Rev. 2 [104]: This standard, issued by NIST, using single-length DES keys for secure key establishment focuses on key establishment schemes using Integer Factorization within financial institutions. However, it became apparent Cryptography (IFC), primarily the RSA algorithm. In the context that the protection provided by single-length DES keys did of key transport, NIST SP 800-56B Rev. 2 provides guidelines not meet the stringent security requirements of these insti- for secure key-wrapping and unwrapping, ensuring the protection tutions (refer to Section 3.1 for an in-depth discussion on of cryptographic keying material during transmission between DES). Consequently, the ANSI X9.17 standard was officially parties. The standard aims to promote the proper use of crypto- withdrawn in 1999. graphic techniques for key transport in order to maintain secure – ANSI X9.24 [103]: Focuses exclusively on symmetric key communication and data protection. management and standardization techniques that employ • NIST SP 800-131 A Rev. 2 [105]: This standard, published by symmetric cryptography. Although it does not explicitly NIST, provides guidance on the transition from older crypto- outline a key management framework, the standard implies graphic algorithms and key lengths to more secure ones in order one by imposing stringent rules governing the usage and to enhance the security of federal information systems. NIST SP manipulation of keys. 800-131 A Rev. 2 outlines recommendations for key manage- ment practices, focusing on the usage of secure cryptographic • IETF RFC 2631: This standard, established by the IETF, outlines algorithms and key sizes for various applications, including key the Diffie–Hellman key agreement method for public key cryptog- establishment, digital signatures, and encryption. The standard raphy. It enables secure key exchange between parties over an in- aims to improve the overall security of information systems by secure communication channel, without requiring any pre-shared promoting the adoption of up-to-date cryptographic techniques secrets. By specifying the protocol, message formats, and crypto- and key management practices. graphic calculations, RFC 2631 facilitates secure communication • NIST Post-Quantum Cryptography [6]: NIST initiated the Post- and data protection over the Internet. Quantum Cryptography (PQC) project to address the potential • NIST SP 800-56A [95]: This standard, developed by the NIST, threats posed by quantum computers to current cryptographic provides guidelines for implementing key establishment schemes algorithms. The project aims to develop, standardize, and pro- using asymmetric key pairs. Covers key agreement and transport mote the adoption of new cryptographic algorithms that can protocols, specifying requirements for secure key exchange and withstand attacks from quantum computers, ensuring long-term key derivation functions. The purpose of NIST SP 800-56 A is to security for communication and data protection. NIST is in the ensure secure communication and data protection by promoting process of evaluating and selecting candidate algorithms for key the proper use of cryptographic techniques in key establishment exchange, digital signatures, and encryption that are resistant to processes. quantum attacks, with the goal of incorporating them into future • RFC 7748: This standard, published by the IETF, specifies two el- cryptographic standards. liptic curves for use in cryptography: Curve25519 and Curve448. These curves are designed for key agreement using the Ellip- 6.2. Recommendations tic Curve Diffie–Hellman (ECDH) protocol. RFC 7748 provides detailed information on the mathematical properties, coordinate Table 13 presents an overview of key establishment algorithms, systems, and encoding formats of these curves. The primary goal including key exchange, key transport, and post-quantum key encap- of the standard is to enhance security and performance in crypto- sulation mechanisms. It provides information on the relevant standards graphic applications, such as key exchange and digital signatures, and offers recommendations based on the criteria defined in Section 1.4 by promoting the use of these modern elliptic curves. for their use in secure communication and data protection applications. • IEEE-P1363 (I) [89]: IEEE P1363 is a set of standards devel- According to traditional recommendations, all surveyed algorithms oped by the IEEE for public-key cryptography. It includes several generally provide sufficient security, with the exception of SIKE, which related standards, each addressing different aspects of public- has been reported as compromised. In the case of RSA, a key length key techniques. The P1363 standard defines methods for key of 3072 bits is considered secure. For MQV, a key length of 256 bits agreement using public-key cryptography, such as Diffie–Hellman is recommended. For DH and ECDH, key pair lengths of (256, 3072) and Elliptic Curve Cryptography. It also specifies methods for key are considered robust. Regarding post-quantum algorithms, aside from transport based on encryption, with RSA commonly used in these SIKE, all other analyzed algorithms appear to offer satisfactory security. schemes. On the other hand, none of the classical algorithms has demon- • RFC 6278: This standard outlines the utilization of the static- strated the ability to effectively resist quantum attacks. Remarkably, static ECDH key agreement scheme within the Cryptographic not all post-quantum algorithms are equipped to withstand such at- Message Syntax. In this approach, both sender and receiver em- tacks either. This implies that not all versions of these algorithms ploy long-term, static Diffie–Hellman values, which are stored in are quantum-resistant; only those that ensure a 128-bit security level certificates. The document provides guidance on implementing against post-quantum attack, namely: Kyber-768, Kyber-1024, McEliece this key agreement method to improve secure communication (6944, 5208, 136), HQC-256, BIKE-192, and BIKE-256, have proven to between parties. be resistant. • ISO/IEC 18033-1 [98]: This standard, published by the Inter- national Organization for Standardization (ISO) and the Interna- 7. Hybridization of cryptographic primitives: Standards, recom- tional Electrotechnical Commission (IEC), provides an overview mendations, and analysis of the ISO/IEC 18033 series on encryption algorithms. As the first part of the series, ISO/IEC 18033-1 defines general concepts, Post-quantum hybridization analysis is a rapidly developing area of terminology, and security requirements for various cryptographic research that seeks to create solutions by combining classical and post- techniques, including symmetric key algorithms, asymmetric key quantum algorithms to withstand the threat of quantum computers. algorithms, and mechanisms for key exchange and management. This approach is a promising way to address the challenges posed by 16 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 14 Table 15 Number of messages stored/sent for storage and network. Digital signature performance analysis. Operation Storage Network Approach Algorithm Storage cost Network cost PK Pr Sign Cipher PK Sign Cipher Classical RSA-15360 9600 3840 Signature 2 1 2 0 1 1 0 Dilithium5 19 238 7187 Encryption 2 1 0 2 1 0 1 PQ Falcon-1024 8551 3123 Key Exchange 2 2 0 2 2 0 2 SPHINCS+ 99 968 49 920 RSA-Dilithium5 28 838 11 027 Hybrid RSA-Falcon-1024 18 151 6963 RSA-SPHINCS+ 109 568 53 760 quantum computing and plays a critical role in developing effective hybrid cryptographic solutions. By leveraging the strengths of both classical and post-quantum mechanisms, we can design robust protocols that protect sensitive data. As we move toward a post-quantum era, this analysis remains essential to ensure data security against emerging quantum threats. Table 16 The post-quantum hybridization analysis aims to evaluate various Key exchange performance analysis. combinations of classical and post-quantum cryptographic primitives, Approach Algorithm Storage cost Network cost such as hash functions, encryption schemes, and signature schemes, to Classical RSA-15360 19 264 7680 identify the most promising combinations that can offer high levels McEliece 4218140 2095090 of security, efficiency, and compatibility with existing systems. Re- PQ HQC-256 101490 43 428 searchers in this field use techniques such as mathematical modeling, Kyber1024 18944 6272 simulation, and experimentation to analyze the complexity of opera- RSA-McEliece 4237340 2102770 tions, available resources, and the size of the data to be processed. The Hybrid RSA-HQC-256 120690 51108 outcome of post-quantum hybridization analysis is recommendations RSA-Kyber1024 38144 13952 for designing and implementing secure and efficient cryptographic protocols that are resistant to quantum attacks. These recommendations are critical for organizations that rely on cryptography to protect sensitive data, such as healthcare providers, governments, and financial • For Hybrid: institutions. – At Sender: 2Pk, 2Pr, Signature This section begins by assessing the feasibility of the resulting – At Receiver End: 2Pk, Signature; hybrid cryptographic algorithms in detail. Our analysis covers various – Total: 4Pk + 2Pr + 2Signature; aspects such as signature, encryption, and key exchange. Furthermore, we thoroughly evaluate the storage and network overhead associated with hybrid algorithms, examining their computational complexity and resistance to attacks. (ii) Encryption Hybrid Cost Computation: • For Classical or PQ 7.1. Hybridization analysis – Receiver: Pk, Pr, Cipher; A hybrid system employs at least two algorithms, such as classical – Sender: Pk and Cipher; and post-quantum algorithms. The anticipated storage and network – Total Cost: 2Pk + Pr + 2Cipher; costs of the hybrid approach are the sum of the respective individual algorithm approximation costs utilized in the hybrid configuration. • For Hybrid: The analysis provided here delves into the employment of RSA as the – Receiver: 2Pk, 2Pr, Cipher; classical standard, post-quantum algorithms, and hybrid algorithms (in- – Sender: 2Pk and Cipher; corporating both classical and post-quantum approaches) across three – Total Cost: 4Pk + 2Pr + 2Cipher; key functionalities: digital signatures, encryption, and key exchange. Our evaluation encompasses all classical and post-quantum algorithms operating at level V security to ensure a comprehensive performance assessment and comparison. The primary focus of this comparison lies (iii) Key Exchange Cost Computation: in scrutinizing key storage and network costs, measured in bytes. We • Classical Key Exchange Cost: have excluded the SIKE algorithm as it has been reported to be bro- ken [106]. The costs associated with these functionalities, as mentioned – At User End (for each user): Pk, Pr, Cipher; in Table 14, are interpreted based on the required number of messages – Received from the other user: Pk and Cipher; as follows: – Final key (256-bit): 32byte; – Total Cost: 2Pk + 2Pr + 2Cipher + 2*32 7.1.1. Storage cost In terms of storage costs, presented below is a concise overview of the incurred costs: • Post-quantum Key Exchange Cost: (i) Digital Signature Cost Computation: – At User End (for each user): Pk, Pr, Cipher; – Received from the other user: Pk, Cipher; • For Classical or PQ – Final key (256-bit): 32byte; – At Sender End: Pk, Pr, Signature; – Total Cost: 2Pk + 2Pr + 2Cipher +2*32 – At Receiver End: Pk, Signature; – Total Cost: 2Pk + Pr + 2Signature; 17 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 17 storage and network costs among the post-quantum candidates. This Encryption performance analysis. characteristic makes Falcon-1024 the most economically viable option Approach Algorithm Storage cost Network cost within the hybrid approach for RSA-Falcon-1024. As we delve into Classical RSA-15360 9600 3840 encryption and key exchange performance, Tables 16 and 17 exhibit McEliece 2 109 038 1047545 Kyber-1024’s efficiency from a cost perspective. Consequently, a fusion PQ HQC-256 50 713 21 714 of Kyber-1024 with RSA (RSA-Kyber1024) yields the most favorable Kyber-1024 9440 3136 overall cost result. RSA-McEliece 2 118 638 1051385 Hybrid RSA-HQC-256 60 313 25 554 RSA-Kyber-1024 19 040 6976 7.3. Standards and recommendations Table 18 presents several hybrid approaches, some of which have already been standardized or are currently undergoing standardization in draft form. Based on our extensive research, we have identified • Hybrid: several notable hybrid approaches, specifically KEM, encryption, and key exchange. For each standard, we provide information on the year of – At User End (for each user): 2Pk, 2Pr, Cipher; publication or proposal, the intended purpose, any noteworthy aspects, – Received from the other user: 2Pk, Cipher; and recommendations based on the criteria defined in Section 1.4 – Final key (256-bit): 32byte; regarding the use of classical and post-quantum algorithms to achieve – Total Hybrid Cost: 4Pk + 4Pr + 2Cipher + 2*32 hybridization. 7.1.2. Network cost 8. Worldwide cryptographic standards and security recommenda- In terms of network costs, presented below is a concise overview of tions across countries the incurred costs: This section provides an overview of publicly available crypto- (i) Digital Signature Cost: graphic standards or guidelines for several countries, including Canada, • For Classical or PQ Australia, USA, UK, Japan, and others. These standards and guidelines are designed to enhance the security of cryptographic systems and – Sender Transmits: Pk, Signature; mitigate potential threats. – Total Cost: Pk + Signature • Total Hybrid Cost: 2Pk + 2Signature 8.1. Recommendations (ii) Encryption Cost: • For Classical or PQ We have compiled country-specific recommendations from official sources, such as government or standards websites, in Table 19. These – Sender Transmits: Pk, Cipher; recommendations are categorized according to different algorithm – Total Cost: Pk + Cipher types, including Hash and MAC, Symmetric Encryption, Asymmetric Encryption, Digital Signature, and Key Establishment. • Total Hybrid Cost: 2Pk + 2Cipher We examined various cryptographic standards and offered potential (iii) Key Exchange Cost: classical and post-quantum recommendations to protect against poten- tial threats. Referring to our suggested recommendations, the entries • Classical Key Exchange: highlighted in bold in Table 19 indicate algorithms that, according – Sender Transmits Pk, Cipher; to our analysis, are deemed inappropriate. Furthermore, in Table 22, – Total Cost: Pk + Cipher we present our assessment of the security strengths of established cryptographic algorithms. The table reflects our analysis of whether • Post-quantum Key Exchange: these algorithms are currently classically secure, projected to remain so – Sender Transmits: Pk, Cipher; beyond 2030, or are quantum-resistant, based on the criteria defined – Total Cost: Pk + Cipher in Section 1.4. It also provides alternative recommendations for the quantum era derived from our evaluation. • Hybrid: 9. Cryptographic standards and recommendations for light-weight – Sender Transmits: 2Pk + 2Cipher cryptography – Total Cost: 2Pk + 2Cipher Since 2015, NIST has led the effort to standardize lightweight cryptography that is suitable for resource-constrained environments 7.2. Findings such as IoT devices and embedded systems. The aim was to iden- tify Authenticated Encryption with Associated Data (AEAD) schemes In analyzing the performance of the digital signature presented and optional hashing capabilities that share common components to in Table 15, Falcon-1024 emerges as the optimal choice in terms of minimize implementation size and complexity. 18 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 18 IETF RFCs/Drafts on hybrid approaches. Algo- RFC/Draft Year Purpose Note Recommendations rithm KEM draft-ounsworth-cfrg-kem- 2023 Defines combiner function for Hybrid Expired in September 2023 combiners-03 [107] KEMs 9180 [108] 2022 Hybrid Public Key Encryption (HPKE) HPKE applies to various combinations ∙ Any classical algorithm of asymmetric KEM, KDF, and AEAD should provide at least a Encryption encryption functions 128-bit security level, such as RSA-3072, ECC-256, etc. draft-westerbaan-cfrg-hpke- 2023 Defines X25519Kyber768Draft00, a Expired in October 2023 ∙ Only NIST’s KEM PQC that xyber768d00-02 [109] hybrid PQ KEM, for HPKE (RFC9180) provides 128 security bits draft-irtf-cfrg-dnhpke-04 [110] 2022 Deterministic Nonce-less Hybrid Public Expired in August 2024 should be used Key Encryption draft-kampanakis-curdle-ssh-pq- 2023 Defines PQ hybrid KE methods These methods are formulated for ke-01 [111] application within the context of Key Exch. SSH/TLS draft-tls-westerbaan- 2023 Defines X25519Kyber768Draft00-03, Expired in March 2024 xyber768d00-03 [112] a hybrid PQ KE for TLS 1.3 draft-ietf-tls-hybrid-design-10 2023 Hybrid key exchange within the Expired in October 2024 [113] context of the TLS 1.3 Table 19 Country-wise recommendation. Algorithm Canada Australia USA-NIST USA-NSA Japan (till next rev) UK ECRYPT-CSA Hash SHA-2/SHA-3≥ SHA-2≥ 224 SHA-2/SHA- SHA-384 or SHA-512 SHA-1; SHA-256 SHA-2/SHA-3≥ 224 224 3≥224 SHA-2≥ 224; (256 beyond 2030) HASH and (256 beyond (256 beyond SHA-3≥ 256; MAC 2030) 2030) SHAKE128, SHAKE256 MAC KS ≥ 128 — KS ≥ 128 — KS ≥ 128 — — Algorithm AES≥ 128 AES≥ 128; AES≥ 128 AES-256 AES≥128; — AES/Camellia/Serpent TDES(using 3 Camellia≥128 ≥ 128 Distinct Keys (3DES)); (must not use ECB mode) Symmetric Encryption Mode ECB (not ECB (Must not ECB (not — ECB (not allowed after ECB (not allowed OFB, CFB, CTR, CBC, allowed after use), CBC, allowed after 2023), CBC, CTR, CFB, after 2023), CBC, ECB (No. acceptable), 2023), CBC, CTR, OFB, CFB 2023), CBC, OFB, XTS, GCM, CTR, CFB, OFB, XTS, EME, FFX, CCM, CTR, CFB, CTR, CFB, CMAC, CBC-MAC, CCM XTS, GCM CWC, GCM, OCB, EAX, OFB, XTS, OFB, XTS, GCM, GCM, CMAC, GCM, CMAC, ChaCha20+Poly1305 CBC-MAC, CCM CBC-MAC, CCM RSA/DSA FFC(DSA, — RSA-OAEP (≥2048), — Asymmetric Encryption ≥2048 DH,MQV): ECC (key sizes 256, (3072 beyond K_pu≥2048 384 or 521) 2030); (3072 XMSS; DSA p≥2048, q≥224; RSA 2048; ECDSA ≥224 beyond2030), LMS (SHA-256/192); ECSDA ≥224; ECDSA-256 P-256 (256 beyond K_pr≥224 RSA/DSA≥3072, ECC ≥ 224 CRYSTALS-Dilithium RSASSA-PKCS1-v1_5/ Curve 2030) (256 Digital Signatures DH ≥1024; (Level V); RSASSA-PSS≥2048; beyond2030); RSA/DSA ECDSA (Curve P-384); IFC(RSA) ≥ ≥2048; RSA≥3072 2048 FFC/DH/MQV ECDSA/ECDH ECDH (Curve P-384); DH/MQV — (3072 ≥ 2048 ≥160 DH ≥ 3072; p≥2048, q≥224; beyond2030); (3072 beyond ECC(ECDSA, RSA≥3072; ECDH/ECMQV ≥224 2030); EdDSA, CRYSTALS-Kyber(Level Key Establishment ECC-CDH or DH,MQV): V) ECC-MQV ≥ f ≥ 224 224 (256 (256 beyond beyond2030); 2030) Note: p is the prime modulus and q is the prime divisor, f is the range, and ‘‘–’’ means not available/mentioned. Abbreviations are defined as follows: LMS: Leighton–Micali Signature, MQV: Menezes–Qu–Vanstone, FFC: Finite Field Cryptography, PSS: Probabilistic Signature Scheme, XMSS: eXtended Merkle Signature Scheme, MS: Modulus Size, KS: Key Size, HL: Hash Length. 9.1. Lightweight AEAD standards and recommendations Romulus, SPARKLE, TinyJAMBU, and Xoodyak. These schemes were chosen to proceed to the final round of the selection process, which During March 2021, NIST revealed a list of 10 finalists, including is shown in Table 20. In February 2023, NIST announced its deci- ASCON, Elephant, GIFT-COFB, Grain-128AEAD, ISAP, PHOTON-Beetle, sion to standardize the ASCON family for lightweight cryptography 19 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 20 Authenticated Encryption with Associated Data (AEAD) standardized algorithms. Algorithm Standards Year Purpose (building block) Recommendations Classical PQ (till 2030 & beyond) (Available) (Alternatives) Ascon [116] A permutation-based scheme that uses the Ascon-128, – SCHWAEMM256-256, monkeyDuplex construction Ascon-128a, TinyJAMBU-256 Ascon-80pq A permutation-based scheme that follows a Jumbo (127), – SCHWAEMM256-256, Elephant [118] NIST [117] 2023 nonce-based encrypt-then-MAC construction Delirium (127) TinyJAMBU-256 A block-cipher based where the underlying GIFT-COFB(128) – SCHWAEMM256-256, GIFT-COFB [119] block cipher is GIFT-128 and the mode is TinyJAMBU-256 Combined Feedback A stream cipher optimized for hardware Grain-128AEAD – SCHWAEMM256-256, Grain [120] implementations TinyJAMBU-256 A permutation-based with a nonce-based ISAP-A-128a, – SCHWAEMM256-256, ISAP [121] encrypt-then-MAC construction mode ISAP-K-128a, TinyJAMBU-256 ISAP-A-128, ISAP-K-128 A permutation-based approach with a PHOTON-Beetle- – SCHWAEMM256-256, PHOTON [122] combined feedback mode AEAD TinyJAMBU-256 A scheme that is based on the tweakable Romulus-N, – SCHWAEMM256-256, Romulus [123] block cipher Skinny with MAC-then-Encrypt Romulus-M TinyJAMBU-256 mode SPARKLE permutations-based operations that SCHWAEMM192– SCHWAEMM256-256 TinyJAMBU-256 SPARKLE [124] apply multiple distinct instances of Alzette – 192(184), a four-round 64-bit block cipher SCHWAEMM256- 256(248) TinyJAMBU [125] A keyed permutation that is based on a TinyJAMBU-192, TinyJAMBU-256 SCHWAEMM256-256 128-bit nonlinear feedback shift register TinyJAMBU-256 Built from a fixed 384-bit permutation Xoodyak-128 – SCHWAEMM256-256, Xoodyak [126] (called Xoodoo) operated in Cyclist mode TinyJAMBU-256 applications. On June 20, 2023, NIST’s report provides a public record • High PQ margin (targeting ≥100–128-bit PQ): choose SPARKLE/ of the final round of the standardization process and explains the Schwaemm256-256 or TinyJAMBU-256. Independent work esti- evaluation of the finalists that were chosen for standardization [114]. mates Grover-attack resources for Schwaemm and finds no short- The finalized standard, NIST SP 800-232, was released in August 2025 cut beyond the square-root speed-up; NIST also points to these and specifies Ascon-AEAD128, Ascon-Hash256, Ascon-XOF128, and larger-key options for PQ-sensitive deployments [114,130]. Ascon-CXOF128 [115]. Note. NIST remarks that the standardized ASCON variants do not include a 256-bit key option. If approximately 128-bit post-quantum 9.1.1. Recommendations security (symmetric-only) is required, a 256-bit candidate such as In the quantum setting, Grover’s algorithm roughly halves the ef- AES-GCM-256 should be used [114]. fective security of symmetric keys. Thus, a 128-bit key provides only about 264 quantum security. Larger keys (or hash output) are required 9.2. Lightweight hash standards and recommendations to restore the margin. NIST’s LWC status report [114] and the final standard [115] both highlight these post-quantum considerations and Table 21 shows the standard lightweight hash algorithms that have been recognized as standards by NIST. Five algorithms have the ability note which finalists or standardized variants offered > 128-bit options. to be used as hash functions in addition to their normal functionality • Default for ultra-constrained IoT (≈ 64-bit PQ): Ascon-AEAD as (AEAD) algorithms. 128/128a, as standardized in SP 800-232 [115], remains the 9.2.1. Recommendations recommended baseline choice. Other 128-bit key finalists with- Every lightweight hash standard algorithm presented in Table 21 out known quantum-specific weaknesses (e.g. GIFT-COFB, Grain- provides at least one version that guarantees adequate security for 2030 128AEAD, ISAP, PHOTON-Beetle, Romulus, Xoodyak) also achieve and beyond. However, according to our research, none of these hash similar PQ levels. Public analyses and NIST reviews indicate algorithms appears to offer security against quantum attacks. only generic Grover-type impacts or preimage bounds; no faster Table 21 lists the standardized lightweight hash functions (some quantum attacks are known for these schemes [114,127,128]. finalists also offer hash/XOF modes). NIST’s final-round report for • Small PQ bump with minimal overhead: ASCON-80pq (160-bit the LWC process summarizes published quantum preimage resource key) was added by the designers specifically to increase resistance estimates for ASCON-Hash, PHOTON-Beetle-Hash, and Xoodyak-Hash; to quantum key search, while keeping the same design philosophy independent studies provide similar estimates for SPARKLE/Esch [131, as ASCON-128 [129]. 132]. These results support the standard guidance: 20 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 21 Lightweight hash functions standardized algorithms. Algorithm Standards Year Purpose (Building Block) Recommendations Classical PQ (till 2030 & beyond) (Available) (Alternatives) Ascon [116] A permutation-based approach that ASCON-Hash-256, ASCON-Hasha-256 – uses the monkeyDuplex construction PHOTON- NIST [117] 2023 A permutation-based is based on a PHOTON-Beetle-Hash-256 – Beetle-hash sponge structure [122] Romulus A permutation-based with a Romulus-H-256 – [123] combined feedback mode SPARKLE SPARKLE permutations-based that ESCH256-256, ESCH384-384 – [124] apply multiple distinct instances of Alzette – a 4-round 64-bit block cipher Xoodyak Built from a fixed 384-bit Xoodyak-256 – [126] permutation (called Xoodoo) operated in Cyclist mode • For preimage security at approximately 128-bit strength against collection of authentication protocols centered on digital signatures, quantum adversaries, select a 256-bit output (e.g., Ascon-Hash- although these are a subset of those defined in ISO/IEC 9798-3. 256, PHOTON-Beetle-Hash-256, Esch-256, Xoodyak-Hash-256/ Internet RFC 4120 specifies Version 5 of the Kerberos network XOF) [131,132]. authentication protocol, which is based on symmetric cryptography. • If collision resistance near 128-bit quantum strength is required, Another protocol, named S/KEY, tailored for user authentication to use a 384-bit output (e.g., ESCH-384), since collisions admit an remote servers is detailed in RFC 1760 [144]. This protocol relies on 𝑂(2𝑛∕3 ) quantum attack [133,134]. a cryptographic hash function. In addition, RFC 1507 [142] introduces an authentication protocol (DASS) that uses digital signatures. It should In short, these lightweight hashes remain quantum-resistant up to the be noted that specific authentication requisites for the Internet context generic bounds. Choose the output length to meet your target quantum are discussed in RFC 1704 [143]. security level. Multiple cryptographic mechanisms are available to ensure the integrity and origin authentication of individual protocol messages. We 10. Cryptographic standards and recommendations for authenti- examine five primary options, forming the foundation of the mecha- cation nisms standardized within ISO/IEC 9798. 10.1. Entity-based: Authentication standards • Symmetric encryption • Use of a MAC function We reviewed standards for authentication mechanisms as detailed • Use of a digital signature in Table 23, listing recommendations for each standard based on its • Use of asymmetric encryption cryptographic support. The International Organization for Standard- • Use of other asymmetric cryptographic techniques ization (ISO) and the International Electrotechnical Commission (IEC) have collaboratively introduced a multipart standard known as ISO/IEC 10.1.1. Recommendations 9798. This standard outlines a collection of authentication mechanisms Table 23 presents a comprehensive list of authentication standards designed for general-purpose applications. The series currently consists and specifications. It includes recommendations for each standard of six sections, each addressing specific aspects as follows: based on their cryptographic support, which are crucial for ensuring the security of various authentication applications, such as web se- • ISO/IEC 9798-1: serves as a foundational component, providing curity, online banking, and secure remote access. Implementing these definitions for key terms and notation. It also presents a basic recommended standards and algorithms allows users to strengthen their model of an authentication mechanism. cryptographic systems and protect themselves against potential future • ISO/IEC 9798-2: details mechanisms that rely on symmetric threats. encryption for their operation. • ISO/IEC 9798-3: outlines mechanisms centered on the utilization 10.2. Certificate-based: Public key infrastructure of digital signatures. • ISO/IEC 9798-4: specifies mechanisms that make use of MACs. The primary emphasis of the Public Key Infrastructure (PKI) re- • ISO/IEC 9798-5: focuses on a variety of zero-knowledge tech- volves around producing, disseminating, and continually administering niques. public key certificates. These certificates encompass a set of data ele- • ISO/IEC 9798-6: involving manual data transfer mechanisms. ments that comprise a public key, multiple identifiers linked to the key holder, and additional information (such as an expiration date). All of The protocols outlined in ISO/IEC 9798 have been designed with these components are subjected to digital signing by the Trusted Third versatility to cater to various application domains, aiming to achieve Party (TTP), recognized as a Certificate Authority (CA). This digital maximum robustness. signature ensures the cohesive association of the diverse elements Additional organizations, namely ITU-T, NIST, and the IETF, have within the certificate. also introduced standards for entity authentication. For instance, ITU- A PKI can consist of diverse components that vary based on the T X.509, recognized for its specifications related to public key and technology and organizational framework employed to distribute and attribute certificates, encompasses three authentication protocols that ensure the accuracy of public keys. rely on digital signatures. Similarly, NIST FIPS Pub. 196 presents a This encompasses a variety of entity types, comprising: 21 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 22 Security Strength Assessment of Cryptographic Algorithms: classical security and post-quantum readiness. Type Algorithm Variant Security Classically Classically Quantum Quantum Era Level Secure Secure Resistance (Alternatives) (Current) (till 2030 & beyond) AES-128 128 Yes Yes No AES Camellia-256 AES-192 192 Yes Yes No Symmetric AES-256 256 Yes Yes Yes Block DES cipher Deprecated AES-256, Camellia-256 Triple DES Camellia-128 128 Yes Yes No Camellia Camellia-256 Camellia-192 192 Yes Yes No Camellia-256 256 Yes Yes Yes RC4 Deprecated Grain Grain-128 128 Yes Yes No AES-CTR/OFB/CFB (256) Symmetric Trivium Trivium-80 80 No No No Stream Rabbit Rabbit-128 128 Yes Yes No Cipher Enocoro Enocoro-128 128 Yes Yes No AES-CTR/OFB/CFB-128 128 Yes Yes No AES-CTR/OFB/CFB AES-CTR/OFB/CFB (256) AES-CTR/OFB/CFB-192 192 Yes Yes No AES-CTR/OFB/CFB (256) 256 Yes Yes Yes ChaCha ChaCha20 256 Yes Yes No AES-CTR/OFB/CFB (256) RSA-2048 112 No RSA RSA-3072 128 Yes No Yes RSA-7680 192 Asymmetric RSA-15360 256 NIST PQ ECC-224 112 No ECC ECC-256 128 Yes No Yes ECC-384 192 ECC-512 256 SM2 SM2-256 256 Yes Yes No SHA-1 Deprecated SHA/SHA3-512, SHAKE-256 SHA-224 112 Yes No No SHA-2 SHA-256 128 Yes Yes SHA3-512, SHAKE-256 SHA-384 192 Yes Yes HASH SHA-512 256 Yes Yes Yes SHA-224 112 Yes No No SHA-3 SHA-256 128 Yes Yes SHA-512, SHAKE-256 SHA-384 192 Yes Yes SHA-512 256 Yes Yes Yes SHAKE-128 128 Yes Yes No SHAKE SHA/SHA3-512 SHAKE-256 256 Yes Yes Yes SM3 SM3-256 256 Yes Yes No SHA/SHA3-512, SHAKE-256 (continued on next page) • CAs: are accountable for producing public key certificates follow- Usually, each certificate is assigned a distinctive serial number. Con- ing a specified certification practice statement. These certificates sequently, the Certificate Revocation List (CRL) only has to encompass can be interpretable within the framework of a defined certificate the serial numbers of certificates that have been revoked. policy. • Registration Authorities (RAs): fulfill the role of authenticating 10.2.1. Recommendations Public key cryptography standards and specifications play a cru- the identities of individuals who seek to obtain a certificate from cial role in ensuring the security of communications and data protec- a CA tion. Tables 24 and 25 list these standards, providing classical and • Certificate Repositories: are entities that securely store and post-quantum recommendations for each standard based on the types provide access to public key certificates. of cryptography it supports. These PKI standards and specifications • Certificate Status Servers: are entities that, upon request, pro- are vital to establishing secure and trusted communication channels. vide online information about the current validity status of a They provide a framework for secure key exchange, digital signa- certificate. tures, and encryption. By adhering to these recommended standards 22 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 22 (continued). Type Algorithm Variant Security Classically Classically Quantum Quantum Era Level Secure Secure Resistance (Alternatives) (Current) (till 2030 & beyond) SHA-1 Deprecated HMAC CMAC, GMAC, BLAKE2-512 SHA-2 Similar to the SHA-2 algorithm assessment listed above SHA-3 Similar to the SHA-3 algorithm assessment listed above CMAC HMAC, GMAC, BLAKE2-512 MAC AES GMAC HMAC, CMAC, BLAKE2-512 Poly1305 Poly1305-128 128 Yes No HMAC, CMAC, GMAC, UMAC-64 64 No BLAKE2-512 UMAC UMAC-128 128 Yes Yes No BLAKE2-256 128 Yes Yes No BLAKE2 HMAC, CMAC, GMAC BLAKE2-512 256 Yes Yes Yes ECDSA Similar to the ECC algorithm assessment listed above Asymmetric RSAES-PKCS Similar to the RSA algorithm assessment listed above NIST PQ Signature RSASSA-PSS RSA-OAEP Kyber-512 128 No McEliece-192/256 Kyber Yes Yes HQC-256 Kyber-768 192 Yes BIKE-192/256 Kyber-1024 256 McEliece-128 128 No Kyber-768/1024 McEliece Yes Yes HQC-256 PQ KEM McEliece-192 192 Yes BIKE-192/256 McEliece-256 256 HQC-128 128 No Kyber-768/1024 HQC Yes Yes McEliece-192/256 HQC-192 192 Yes BIKE-192/256 HQC-256 256 BIKE-128 128 No Kyber-768/1024 BIKE Yes Yes McEliece-192/256 BIKE-192 192 Yes HQC-256 BIKE-256 256 Dilithium-2 128 No Falcon-1024 Dilithium Yes Yes Dilithium-3 192 SPHINICS-192/256 Yes PQ Dilithium-5 256 Signature Falcon-512 256 No Dilithium-3/5 Falcon Yes Yes SPHINICS-192/256 Falcon-1024 512 Yes SPHINCS+-128 128 No Dilithium-3/5 SPHINCS+ Yes Yes SPHINCS+-192 192 Falcon-1024 Yes SPHINCS+-256 256 DH Similar to the RSA algorithm assessment listed above Key PQC Establishment ECDH Similar to the ECC algorithm assessment listed above MQV Similar to the RSA algorithm assessment listed above and algorithms, organizations can achieve the following benefits and standards. Table 26 provides a comprehensive overview of these stan- advantages: robust security, confidentiality, authentication, integrity, dards, listing both classical and post-quantum recommendations for non-repudiation, and interoperability. In summary, adhering to the each standard based on its cryptographic support. Through a thorough recommended PKI standards and algorithms ensures the security and examination of the security aspects of these standards, we provide rec- reliability of the communication channels. By implementing PKI, or- ommendations to enhance the effectiveness of Kerberos. The protocol ganizations can protect sensitive information, establish trust among utilizes symmetric key cryptography to establish strong authentica- parties, and mitigate the risks associated with unauthorized access, tion mechanisms, encryption algorithms to protect data integrity, and tampering, and denial of involvement. secure key distribution techniques for session key establishment. In general, Kerberos relies on robust cryptographic standards to secure 10.3. Standards and recommendations for authentication protocols communication channels and prevent unauthorized access in untrusted environments. 10.3.1. Kerberos standards and recommendations The Kerberos protocol is widely used to authenticate service re- 10.3.2. DNSSEC standards and recommendations quests between trusted hosts over untrusted networks, such as the The DNSSEC protocol protects Internet users and applications from Internet. Ensure secure communication by employing cryptographic forged DNS data by utilizing public key cryptography to electronically 23 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 23 Standards for authentication mechanisms. Objective Standard Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ ISO/IEC 9798-1 [135] 2021a ∙ Defines an authentication model along ∙ Refer to Table 8 for asymmetric encryption with overarching prerequisites and ∙ Refer to Table 12 for asymmetric digital signature limitations ∙ Refer to Table 6 for symmetric encryption ∙ Support: ∙ Refer to Table 10 for hash algorithm Asymmetric encryption and signatures Symmetric encryption Hash algorithms ISO/IEC 9798-2 [136] 2019 ∙ Approaches utilizing authenticated ∙ Refer to Table 6 for symmetric encryption Security approaches for entity encryption Authentication authentication ∙ Support: Symmetric encryption ISO/IEC 9798-3 [137] 2019 ∙ Procedures utilizing digital signature ∙ Refer to Table 12 for asymmetric digital signature methods ∙ Support: Asymmetric digital signature ISO/IEC 9798-4 [138] 2021a ∙ Approaches incorporating cryptographic ∙ Refer to Table 11 for MAC algorithm check function ∙ Support: MAC algorithm ISO/IEC 9798-5 [139] 2018a ∙ Incorporation of zero-knowledge ∙ Refer to Table 8 for asymmetric encryption procedures ∙ Refer to Table 10 for hash algorithm ∙ Support: Asymmetric encryption Hash algorithms ISO/IEC 9798-6 [140] 2021a ∙ Procedures employing manual data ∙ Refer to Table 10 and Table 11 for Hash and transfer MAC recommendations, respectively ∙ Support: Hash and MAC functions NIST FIPS Pub. 196 [141] 1997 Entity Authentication Using ∙ Withdrawn on October 2015 ∙ Inactivated Public Key Cryptography IETF RFC 1507 [142] 1993 DASS - Distributed ∙ Based on the use of digital signatures ∙ Refer to Table 8 and Table 12 for asymmetric Authentication Security Service ∙ Support: encryption and signature, respectively Asymmetric encryption and signature (RSA) ∙ Refer to Table 6 for symmetric encryption Symmetric encryption (DES) ∙ Refer to Table 10 for hash algorithm Hash function (MD2) IETF RFC 1704 [143] 1994 Internet Authentication ∙ Provide guidance for selecting suitable ∙ Refer to Table 8 for asymmetric encryption authentication technologies based on ∙ Refer to Table 12 for asymmetric digital signature specific use cases, accessibility, and ∙ Refer to Table 6 for symmetric encryption network connectivity ∙ Refer to Table 10 for hash algorithm ∙ Support: Asymmetric encryption (RSA) and signatures (RSA/DH) Symmetric encryption (DES) Hash function (MD5) IETF RFC 1760 [144] 1995 S/KEY: One-Time Password ∙ Tailored for secure user authentication ∙ Refer to Table 10 for hash algorithm System for authentication with remote servers ∙ Support: Hash functions (MD4) IETF RFC 4120 [145] 2005 Kerberos Network ∙ Furnishes an outline and specifications ∙ Refer to Table 6 for symmetric encryption Authentication Service (V5) for version 5, along with a comprehensive ∙ Refer to Table 10 and Table 11 for Hash and MAC protocol description recommendations, respectively ∙ Support: Symmetric encryption (DES-CBC, AES-CTS-128/256) Hash (MD5, SHA-1) and MAC (HMAC) functions a Standard was last reviewed and confirmed in the mentioned year. sign authoritative zone data upon entry into the DNS and subse- process mitigates the risk of DNS cache poisoning and man-in-the- quently verify these data upon reaching its intended endpoint. Table middle attacks, preserving the accuracy and reliability of Internet traffic 27 provides a comprehensive overview of the cryptographic standards routing. Table 27 provides a comprehensive resource for understanding used in the DNSSEC protocol, listing both classical and post-quantum and selecting suitable DNSSEC cryptographic standards based on their recommendations based on the cryptographic support of each stan- intended purpose and cryptographic support. dard. We thoroughly analyze the security aspects of these standards Our analysis delves into the security aspects of DNSSEC crypto- and offer relevant recommendations to enhance their implementa- graphic standards, which are mentioned in the notes column of the tion. corresponding table. For example, this standard supports digital signa- The purpose of DNSSEC is to ensure the integrity and authenticity tures and hash functions. Due to the use of specific cryptography, there of DNS data. Digitally signing authoritative zone data prevents tamper- is a chance that some algorithms are outdated or vulnerable. In this ing and unauthorized modifications during transit. This authentication way, we identify potential vulnerabilities and suggest corresponding 24 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 24 PKI standardization bodies and standards. Objective Standards Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ ISO/IEC 9594-8 2020b Framework for public-Key and attribute ∙ Defines frameworks for PKI and PMI ∙ Refer to Table 12 for digital signature [146] (ITU-T X.509) certificates ∙ Also defines directory schema information ∙ Refer to Table 6 for symmetric encryption allowing PKI and PMI-related data to be stored in ∙ Refer to Table 10 and Table 11 for Hash and MAC a directory recommendations, respectively ∙ Support: Asymmetric digital signatures (i.e., RSA, DSA, ECDSA) Symmetric encryption (AES-128/192/256) Hash and MAC functions (SHA-1, SHA-2, SHA-3, HMAC) ISO/IEC 15945 [147] 2018a Certificate management (security ∙ ISO/IEC 15945 [147] has additionally been ∙ Refer to Table 12 for digital signature Specifications techniques for defining TTP services that embraced in the capacity of an ITU-T ∙ Refer to Table 10 for hash algorithms facilitate the implementation of digital Recommendation, designated as X.843 signatures) ∙ Support: Asymmetric digital signature Hash functions ISO 21188 [148] 2018 Establishing a policy framework and ∙ It revised the ISO 15782-1 & 15782-2 ∙ Refer to Table 13 and Table 12 for asymmetric key practices for PKI in the financial services ∙ Support: exchange and digital signature sector Asymmetric key exchange and digital signature ∙ Refer to Table 6 for symmetric encryption Symmetric encryption ∙ Refer to Table 11 for MAC recommendations MAC function ANSI X9.62 [149] 1998 PKC with ECDSA For The Financial ∙ Defines a technique for generating and ∙ Refer to Table 12 for asymmetric digital signature Services Industry validating digital signatures ∙ Refer to Table 10 for hash algorithms ∙ Support: Asymmetric digital signature (ECDSA) Hash functions (SHA-1, SHA-2) ANSI X9.63 [150] 2001 Utilizing ECC in PKC for the Financial ∙ Defines Key Agreement and key transport ∙ Refer to Table 13 and Table 12 for asymmetric Services Sector: Facilitating Secure Key mechanism cryptography Agreements and Key Transports ∙ Support: ∙ Refer to Table 10 and Table 11 for Hash and MAC Asymmetric key agreement/transport (using ECC) recommendations, respectively Hash and MAC functions (SHA-1, HMAC) PKCS #7 [151] 1998 ASN.1-driven approach to structuring ∙ DER or PEM format ∙ Refer to Table 8 for asymmetric encryption cryptographic messages ∙ Support: ∙ Refer to Table 6 for symmetric encryption Asymmetric encryption (RSA) ∙ Refer to Table 10 for hash algorithms Symmetric encryption (DES) Hash function (MD5) ‘‘–’’ represents Not Applicable/Available. a Standard was last reviewed and confirmed in the mentioned year. b Standard was last approved/revised in the mentioned year. recommendations, which are already mentioned in the previous tables. impacted. To maintain long-term security for SAML-dependent systems, Thus, we refer to those existing tables in the recommendation field. it is necessary to transition to post-quantum signature algorithms in By offering recommendations, we ensure the effective and secure SAML implementations. implementation of DNSSEC, keeping pace with best practices, emerging Although there is no specific hybrid version of SAML, it uses crypto- threats, and advancements in cryptographic techniques. With Table 27 graphic algorithms that can replace quantum-safe ones. SAML utilizes as a reference, users and implementers can make informed decisions to message digest algorithms such as SHA-1, SHA-256, or SHA-512 to protect against forged DNS data, ultimately improving the security of create hash values for digital signatures and message integrity checks. Internet users and applications. Post-quantum recommendations for the Hash function can be found in Table 10. SAML supports various asymmetric key algorithms for 10.3.3. SAML standards and recommendations digital signatures and exchange, including RSA and DSA. Table 8 SAML represents the Security Assertion Markup Language, an open presents post-quantum recommendations for asymmetric cryptography. standard widely adopted that facilitates the interchange of authentica- SAML utilizes key transport algorithms to securely transmit symmetric tion and authorization information among diverse entities, especially keys for message encryption, typically involving asymmetric encryption in web applications. With SAML, users only need to authenticate once algorithms such as RSA or Diffie–Hellman key exchange. Table 13 with an Identity Provider (IdP) and can then access multiple services or provides post-quantum recommendations for key exchange. applications without repeatedly entering their credentials. This feature is called Single-Sign-On (SSO) [213]. The OASIS (Organization for the Advancement of Structured In- 10.3.4. Oauth standards and recommendations formation Standards) consortium is responsible for developing and OAuth (Open Authorization) is a protocol that helps protect the maintaining the SAML standard. Although OASIS is the primary orga- security of user or application resources. It allows users to give limited nization for developing SAML standards, other groups, such as IETF, access to their data or functionality to other applications without also contribute to advancing SAML-related technology. Tables 28 and sharing their login information [214]. To ensure compatibility and con- 29 illustrate the SAML IETF and OASIS standards, respectively. We ref- sistency across different systems, OAuth has been standardized through erence both classical and post-quantum recommendations based on the efforts of the IETF, which has defined various RFCs for OAuth stan- cryptographic support of the corresponding standards. We thoroughly dardization. The standardization of OAuth by IETF is shown in Table analyze the security aspects of these standards and offer relevant 30, listing both classical and post-quantum recommendations based on recommendations to enhance their implementation. the cryptographic support of each standard. We thoroughly analyze the Regarding post-quantum cryptography, the use of digital signatures security aspects of these standards and offer relevant recommendations for authentication and integrity verification in SAML is significantly to enhance their implementation. 25 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 25 IETF standards for cryptography in Public Key Infrastructure (PKI). Algorithm RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 4055 [152] 2005 Enhancing RSA cryptography with ∙ Updates RFC 3279 and Updated by RFC ∙ Refer to Table 12 and Table 13 for asymmetric supplementary algorithms and identifiers 5756 digital signature and key transport, respectively for integration within the PKIX profile ∙ Support: ∙ Refer to Table 10 for hash algorithms Asymmetric digital signature (RSASSA-PSS) and key transport (RSAES-OAEP) Hash functions (SHA-1, SHA-2) 5756 [86] 2010 Enhancements for RSAES-OAEP and ∙ Updates the standards for algorithm ∙ Refer to Table 12 and Table 13 for asymmetric RSASSA-PSS algorithm configuration parameters within the subjectPublicKeyInfo digital signature and key transport, respectively field of an X.509 certificate ∙ Support: RSA Asymmetric digital signature (RSASSA-PSS) and key transport (RSAES-OAEP) 8017 [54] 2016 RSA Cryptography Specifications ∙ Recommendations including ∙ Refer to Table 8 and Table 12 for asymmetric cryptographic primitives, encryption encryption and digital signature, respectively schemes, signature schemes, etc. ∙ Refer to Table 10 for hash algorithms ∙ Support: Asymmetric encryption (RSA, RSAES-OAEP) and digital signature (RSASSA-PSS, RSASSA-PKCS1-v1_5) Hash functions (MD5, SHA-1, SHA-2) 8018 [153] 2017 Password-Based Cryptography Specification ∙ Recommendations encompass essential ∙ Refer to Table 8 for asymmetric encryption key derivation functions, encryption ∙ Refer to Table 6 for symmetric encryption methodologies, message authentication ∙ Refer to Table 10 and Table 11 for Hash and protocols, etc. MAC recommendations, respectively ∙ Support: Asymmetric encryption (RSA) Symmetric encryptions (DES/3DES-CBC, AES-CBC-128/192/256 RSA) Hash and MAC functions (MD5, SHA-1, SHA-2, HMAC) 5753 [154] 2010 Use of ECC Algorithms in CMS ∙ Obsoletes RFC 3278 ∙ Refer to Table 13 and Table 12 for asymmetric ∙ Support: cryptography Asymmetric cryptography (ECDSA, DH, ∙ Refer to Table 6 for symmetric encryption RSA) ∙ Refer to Table 10 and Table 11 for Hash and Symmetric encryption (3DES-CBC, MAC recommendations, respectively ECC AES-CBC-128/192/512) Hash and MAC functions (SHA-1, SHA-2, HMAC) 5480 [155] 2009 Defines the syntax and semantics for the ∙ Updates RFC 3279 and Updated by RFC ∙ Refer to Table 13 and Table 12 for asymmetric Subject Public Key Information field in 8813 cryptography certificates that enable ECC support ∙ Support: ∙ Refer to Table 10 for hash algorithms Asymmetric cryptography (ECDSA, ECDH, ECMQV) Hash functions (SHA-1, SHA-2) (continued on next page) At present, the OAuth protocol does not have any quantum-safe IPsec, SSH, FTP, and S/MIME. Our goals are to (1) evaluate the crypto- cryptography measures. Despite not having a hybrid option, the pro- graphic mechanisms and algorithms currently employed and (2) pro- tocol uses cryptographic algorithms that can potentially be replaced by vide security recommendations addressing both classical and post- quantum-safe alternatives. Like other cryptographic protocols, OAuth quantum threats. By assessing protocols current security posture and uses cryptographic algorithms such as symmetric encryption, asymmet- considering the potential impact of quantum computing, our goal is to ric encryption, and digital signatures. Tables B.37, 8, and 12, containing provide actionable guidance to strengthen their resilience and ensure post-quantum recommendations for symmetric/asymmetric cryptogra- the continued protection of sensitive information. phy and digital signature recommendations, respectively. OAuth 2.0 is We present both classical and post-quantum recommendations for the most commonly used version of OAuth. It employs secure commu- these protocols (Tables 31–36), based on their cryptographic sup- nication protocols such as TLS [215] to ensure the confidentiality and port as defined in Section 1.4. The analysis covers security aspects integrity of data transmission. Table 31 presents a hybrid version of of the standards and offers recommendations to improve their imple- TLS that can be used in place of the classical version to improve safety mentation. For detailed guidelines on table columns, cryptographic in the context of post-quantum security. recommendations, and evaluation criteria, see Sections 1.3 and 1.4. 11.1. TLS standards and recommendations 11. Standards and recommendations for communication protocols Table 31 presents a comprehensive overview of Transport Layer This section analyzes the cryptographic standards used in widely Security (TLS) cryptographic standards, which are widely used to en- adopted network communication and security protocols such as TLS, sure secure communication across networks. As part of our examination 26 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 25 (continued). Algorithm RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 8692 [156] 2019 Enhancing Algorithm Identifiers for ∙ Describes the guidelines governing the ∙ Refer to Table 12 for asymmetric digital RSASSA-PSS and ECDSA utilizing SHAKEs utilization of the SHAKE function family signature for Internet X.509 PKI ∙ Support: ∙ Refer to Table 10 for hash algorithms Asymmetric digital signature (RSASSA-PSS, ECDSA) Hash functions (SHA-3 (SHAKE-128/256)) 5758 [157] 2010 Enhanced Algorithms and Identifiers for ∙ Define algorithm identifiers and ASN.1 DSA and ECDSA within the Internet X.509 encoding rules Multiple PKI ∙ Support: Algorithmsa Asymmetric digital signature (DSA, ECDSA) Hash functions (SHA-2) 3279 [158] 2002 Specifies algorithm identifiers and ASN.1 ∙ Algorithms and Identifiers for the PKIX ∙ Refer to Table 12 and Table 13 for asymmetric encoding formats for digital signatures and profile digital signature and key exchange, respectively subject public keys in the Internet X.509 ∙ Updated by RFC 4055 [152], RFC 4491 ∙ Refer to Table 10 for hash algorithms PKI [159], RFC 5480 [155], RFC 5758 [157], RFC 8692 [156] ∙ Support: Asymmetric digital signature (RSA, DSA, ECDSA) and key exchange (DH) Hash functions (MD5, SHA-1) 6955 [160] 2013 Crafted with the intent of offering a ∙ Obsoletes RFC 2875 and outlines a pair ∙ Refer to Table 12 and Table 13 for asymmetric Proof-of-Possession for the private key of techniques for generating an integrity digital signature and key agreement, respectively rather than serving as a general-purpose check value from a DH key pair, along ∙ Refer to Table 10 and Table 11 for Hash and signing algorithm with a method for deriving an integrity MAC recommendations, respectively check value from an EC key pair ∙ Support: Asymmetric digital signature (ECDSA) and key agreement (DH, ECDH) Hash and MAC functions (SHA-1, SHA-2, HMAC) MAC 9045 [161] 2021 Revisions have been made to the ∙ PKI CRMF specified in RFC 4211 ∙ Refer to Table 6 for symmetric encryption cryptographic algorithm prerequisites for ∙ Support: ∙ Refer to Table 10 and the Password-Based MAC in the Internet Symmetric encryption (DES/3DES, Table 11 for Hash and MAC recommendations, X.509 PKI CRMF AES-GMAC-128) respectively Hash and MAC functions (SHA-1, SHA-256, HMAC, GMAC) 5754 [162] 2010 Outlines the guidelines for utilizing SHA-2 ∙ Provides ‘SMIMECapabilities’ attribute ∙ Refer to Table 12 for asymmetric digital Algorithms within CMS values for each algorithm signature ∙ Support: ∙ Refer to Table 10 and Table 11 for Hash HASH Asymmetric digital signature (RSA, DSA, and MAC recommendations, respectively ECDSA) Hash and MAC functions (SHA-2, HMAC) 8702 [163] 2020 Outlines the guidelines for incorporating Hash functions used with the RSASSA-PSS the SHAKE family of hash functions into and ECDSA the CMS ∙ Support: Asymmetric digital signature (RSASSA-PSS, ECDSA) Hash and MAC functions (SHA-3 (SHAKE-128/256), KMAC) Note: Abbreviations are defined as follows: MS: Modulus Size, KS: Key Size, HL: Hash Length. a It comprises a set of security and cryptography standards that employ a combination of algorithms. of the cryptographic standards of TLS, we analyze its security aspects support for each standard. Our exploration of these standards includes and provide relevant recommendations. Standards that share the same a thorough analysis of their security aspects, and we provide relevant cryptographic recommendations are consolidated and categorized ac- recommendations based on our findings. To simplify the presentation, cording to the cryptographic mechanisms they employ. Additionally, we have grouped standards with similar cryptographic recommenda- the table includes the hybrid draft standard of TLS, which enhances tions based on the specific mechanisms they employ. Additionally, the security in the post-quantum cryptography era by employing multiple table includes the IKE standard for post-quantum security, which incor- key exchange algorithms simultaneously. porates Mixing Pre-shared Keys to provide resistance against quantum computers. 11.2. Ipsec standards and recommendations 11.3. SSH standards and recommendations Tables 32 and 33 provide a comprehensive overview of the IPsec/IKE cryptographic standards, which are widely utilized for secure com- Table 34 presents a comprehensive overview of Secure Shell (SSH) munication purposes. IPsec/IKE is commonly employed to establish cryptographic standards, a widely used network protocol that pro- secure Virtual Private Networks (VPNs) and protect data transmission vides secure remote login, file transfer, and command execution be- over the Internet. The table offers valuable information such as the tween network devices. As we explore SSH cryptographic standards, year of publication, intended purpose, specific notes, and cryptographic we extensively analyze their security aspects and provide relevant 27 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 26 IETF cryptographic standards/drafts for well-known Kerberos protocols. Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 2712 [164] 1999 Propose new cipher suites in ∙ Enabling mutual authentication and ∙ Refer to Table 13 and Table 23 for asymmetric TLS for Kerberos-based secure communication Key exchange and authentication, respectively authentication ∙ Support: ∙ Refer to Table 6 for symmetric encryption Asymmetric Cryptography for ∙ Refer to Table 10 and Table 11 for Hash and Authentication and key exchange (RSA, MAC recommendations, respectively DH) ∙ Refer to Table 31 for TLS Symmetric encryption (DES, 3DES) Hash and MAC functions (MD5, SHA) TLS 3962 [165] 2005 Specify the integration AES ∙ Support: ∙ Refer to Table 6 for symmetric encryption algorithm into the Kerberos 5 Symmetric encryption (AES-CTS-128/256) ∙ Refer to Table 10 and Table 11 for Hash and Kerberos cryptosystem suite Hash and MAC functions (SHA-1, HMAC) MAC recommendations, respectively Authentication ∙ Refer to Table 23 for Authentication 4120 [145] 2005 The Kerberos Network ∙ Support: Authentication Service (V5) Symmetric encryption (DES, AES-CTS-128/256) Hash and MAC functions (MD5, SHA-1, HMAC) Authentication 8009 [166] 2016 Specify encryption and ∙ Support: checksum types for Kerberos 5 Symmetric encryption (AES-CTS-128/256) using AES in CTS mode and Hash and MAC functions (SHA-2-256/384, HMAC with SHA-2 HMAC) Authentication 5349 [167] 2008 ECC Support for PKC for Initial ∙ Describes the use of ECC in PKINIT for ∙ Refer to Table 12 and Table 13 for asymmetric Authentication in Kerberos secure public key-based authentication and digital signature and Key exchange, respectively (PKINIT) key exchange ∙ Refer to Table 10 for Hash recommendations ∙ Support: ∙ Refer to Table 23 for authentication Asymmetric digital signature and key ∙ Refer to Table 24 for PKI recommendations exchange (ECDSA) Hash functions (SHA-1, SHA-256/384/512) Authentication and PKI 6251 [168] 2011 Specify the integration of the ∙ Defines Kerberos V5 protocol integration ∙ Refer to Table 23 for Authentication Kerberos V5 protocol with TLS with TLS to enhance security ∙ Table 24 for PKI recommendations ∙ Support: ∙ Refer to Table 31 for TLS Authentication, PKI, and TLS 6803 [169] 2012 Specify camellia encryption for ∙ Defines encryption and checksum types ∙ Refer to Table 6 for symmetric encryption Kerberos 5 using Camellia block cipher and CMAC ∙ Refer to Table 10 and Table 11 for Hash and algorithm MAC recommendations, respectively ∙ Support: Symmetric encryption (Camellia-CTS-128/256) Hash and MAC (SHA-1, HMAC, CMAC) 7751 [170] 2016 Introduce a Kerberos ∙ Supporting multiple MACs ∙ Refer to Table 11 for MAC recommendations authorization data container ∙ Support: ∙ Refer to Table 23 for Authentication with multiple MACs to enhance MAC and Authentication authentication 8636 [171] 2019 PKC for Initial Authentication in ∙ Enhances PKINIT standard by removing ∙ Refer to Table 13 for asymmetric Key exchange ∙ Kerberos (PKINIT) Algorithm algorithm dependencies, enabling Refer to Table 6 for symmetric encryption Agility flexibility, and future-proofing against ∙ Refer to Table 10 and Table 11 for Hash and vulnerabilities MAC recommendations, respectively ∙ Support: ∙ Refer to Table 23 for authentication Asymmetric key exchange (DH) ∙ Refer to Table 24 for PKI recommendations Symmetric encryption (AES-CTS-256) Hash and MAC functions (SHA-1, SHA-256/384/512) Authentication and PKI recommendations to ensure the confidentiality and integrity of data exchange with PQ KEM to provide PQ hybrid key exchange meth- transmission. We categorize standards that share the same crypto- ods. This comprehensive overview of SSH cryptographic standards graphic recommendations, grouping them according to the specific aims to help researchers, developers, and security practitioners in cryptographic mechanisms they use. Additionally, the table includes understanding and implementing robust security measures in SSH com- the hybrid draft standard of SSH, which combines classical ECDH key munications. 28 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 27 IETF cryptographic standards/drafts for well-known DNSSEC protocols. Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 4033 [172] 2005 DNS Security ∙ Ensures data source authentication and ∙ Refer to Table 12 for digital signature Introduction and content integrity within the Domain Name ∙ Refer to Table 10 for Hash recommendations Requirements System ∙ Refer to Table 23 for authentication ∙ Support: Digital signature Hash functions Authentication 4398 [173] 2006 Storing cryptographic ∙ CERT resource records enable ∙ Refer to Table 12 for asymmetric digital signature certificates and authentication of cryptographic public keys DNSSEC revocation lists in in DNS ∙ Refer to Table 10 for Hash recommendations DNS ∙ Support: ∙ Refer to Table 24 for PKI recommendations Asymmetric digital signatures Hash functions PKI 5155 [174] 2008 DNSSEC Hashed ∙ NSEC3 resource record in DNSSEC ∙ Refer to Table 12 for asymmetric digital signature Authenticated Denial enhances denial of existence authentication of Existence and safeguards against zone enumeration ∙ Refer to Table 10 for Hash recommendations and facilitates expansion of delegation-centric zones ∙ Support: Asymmetric digital signatures (DSA, RSA) Hash functions (SHA-1) 6781 [175] 2012 Provide operational ∙ Covering key management, signature ∙ Refer to Table 12 and Table 13 for asymmetric guidelines for zone generation, and related policies digital signature and Key exchange administrators ∙ Support: ∙ Refer to Table 10 for Hash recommendations deploying DNSSEC Asymmetric digital signatures and key ∙ Refer to Table 23 for Authentication exchange (RSA) ∙ Refer to Table 31 for TLS Hash functions (MD5, SHA-1, SHA-256) Authentication and TLS 7091 [176] 2013 Digital Signature ∙ Offers comprehensive guidance on the ∙ Refer to Table 12 for asymmetric digital signature Algorithm is specified generation and authentication of digital by GOST R signatures using GOST R 34.10-2012 ∙ Refer to Table 10 for Hash recommendations 34.10-2012 ∙ Support: Digital signature (GOST R 34.10-2012) Hash functions 8080 [177] 2017 Provides guidelines ∙ Focuses on the utilization of EdDSA with ∙ Refer to Table 12 for digital signature for specifying EdDSA the two specified curves (Ed25519 and keys and signatures Ed448) for DNSSEC implementation in DNSSEC ∙ Support: Digital signature (EdDSA (Ed25519 and Ed448)) (continued on next page) 11.4. FTP standards and recommendations allowing us to provide relevant and actionable recommendations. To enhance readability and comprehension, we have consolidated the Table 35 presents a comprehensive overview of three widely used standards based on the specific cryptographic recommendations they protocols for secure file transfer: FTP, FTPS, and SFTP. FTP, which employ, allowing for a systematic evaluation process. stands for File Transfer Protocol, is a conventional network protocol used to facilitate the transfer of files between a computer network’s 11.5. S/MIME standards and recommendations client and server. Its purpose is to facilitate the efficient exchange of files, allowing users to upload, download, and manage files remotely. On the other hand, FTPS, or FTP Secure, is an extension of FTP that S/MIME, which stands for Secure/Multipurpose Internet Mail Ex- adds an extra layer of security through the use of SSL/TLS encryption. tensions, is a commonly used standard that guarantees safety in email This protocol enhances the security of file transfers by encrypting communication. It involves a variety of protocols and formats that the data exchanged between the client and the server, ensuring that allow encryption, signing, and authentication of the email message. The sensitive information remains protected from unauthorized access. S/MIME protocol is built on the Cryptographic Message Syntax (CMS) SFTP, which stands for Secure File Transfer Protocol, is an entirely created by the IETF. It uses asymmetric encryption, digital signatures, different protocol from FTP and FTPS. Unlike its counterparts, SFTP and certificates to secure the privacy, accuracy, and legitimacy of email is not an extension, but rather a standalone protocol that operates content [278]. over SSH (Secure Shell) connections. SFTP provides secure file transfer S/MIME is not directly standardized by ISO and ANSI. The respon- capabilities combined with the strong authentication and encryption sibility for standardizing S/MIME lies with the IETF, which achieves features of SSH, making it an excellent choice for secure file transfers this through the creation of RFCs. These RFCs outline core specifi- in a wide range of environments. cations, including encryption, digital signatures, and certificate han- In Table 35, we thoroughly examine the security aspects of the FTP dling. They establish standards and protocols for the implementation cryptographic standards to identify their strengths and vulnerabilities, of S/MIME, serving as authoritative guides for its implementation and 29 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 27 (continued). Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 6605 [178] 2012 Elaborates on the ∙ Focuses on the utilization of EdDSA with ∙ Refer to Table 12 for asymmetric digital signature technique of defining the two specified curves (Ed25519 and ECDSA keys and Ed448) for DNSSEC implementation ∙ Refer to Table 10 for Hash recommendations signatures in DNS ∙ Support: Security (DNSSEC) Asymmetric digital signature (ECDSA using SHA-2 hashes (P-256, P-384) Hash Functions (SHA-256/384) 5933 [179] 2010 Utilizing GOST ∙ Outlines the process of creating digital ∙ Refer to Table 12 for asymmetric digital signature Signature Algorithms signatures and hash functions using GOST in DNSKEY and algorithms ∙ Refer to Table 10 for Hash recommendations RRSIG Resource ∙ Support: Records for DNSSEC Digital signature (ECC-GOST (GOST R 34.10-2001)) Hash functions (GOST R 34.11-94) 5702 [180] 2009 Incorporating SHA-2 ∙ Provides instructions for generating ∙ Refer to Table 12 for asymmetric digital signature algorithms in DNSKEY and RRSIG resource records for conjunction with RSA DNS Security Extensions ∙ Refer to Table 10 for Hash recommendations within DNSKEY and ∙ Support: RRSIG resource Asymmetric digital signature (RSA) records for DNSSEC Hash functions (SHA-256/512) 3110 [181] 2001 RSA/SHA-1 ∙ Incorporates advancements in hashing for ∙ Refer to Table 12 for asymmetric digital signature signatures and RSA DNS signatures and deprecates the weaker keys used in DNS mechanism ∙ Refer to Table 10 for Hash recommendations ∙ Support: Asymmetric digital signature (RSA) Hash functions (SHA-1) draft-makarenko- 2023 Provide guidelines ∙ Focuses on the usage of these algorithms ∙ Refer to Table 12 for asymmetric digital signature gost2012-dnssec- for generating digital for DNSKEY, RRSIG, and DS resource 05 [182] signatures and hash records in DNSSEC. Expired in July 2024 ∙ Refer to Table 10 and Table 11 for Hash and functions via GOST R ∙ Support: MAC recommendations, respectively 34.10-2012 and Asymmetric digital signature (GOST R GOST R 34.11-2012 34.10-2012) algorithms within Hash and MAC functions (GOST R DNSSEC 34.11-2012, HMAC) draft-dnsop- 2023 Mechanism to ∙ Protocol is extended to address ∙ Refer to Table 12 for digital signature dnssec-extension- enhance DNSSEC vulnerabilities in DNS messages, providing ∙ Refer to Table 24 for PKI recommendations pkix-01 [183] protocol, ensuring integrity assurance. Expired in September the integrity of DNS 2023 messages using PKIX ∙ Support: certificates Digital signature independently PKI draft-cuiling- 2023 Provide guidelines ∙ SM3 is used as the hash algorithm for ∙ Refer to Table 12 for asymmetric digital signature dnsop-sm2-alg-05 for specifying SM2 signatures in DNSSEC. Expired in [184] Digital Signature September 2023 ∙ Refer to Table 10 for Hash recommendations. Algorithm keys and ∙ Support: signatures in DNSSEC Digital signature (SM2) Hash functions (SM3) understanding. The S/MIME standardization RFCs are listed in Table offer protection against both classical and quantum-based attacks. The 36. recommendations for using hybrid TLS/SSL in S/MIME are presented The security of S/MIME relies on MIME and CMS. CMS is a syntax in Table 31, and in Table 12, there are hybrid recommendations for that encapsulates data for protection, and its parameters influence using digital signatures in S/MIME. many of S/MIME’s security properties. Fortunately, the CMS parameters are customizable, including the choice of the algorithm used. This 11.6. Summary flexibility facilitates the transition of protocols such as TLS, SSL, and RSA to quantum-safe cryptography [297]. When it comes to S/MIME, post-quantum cryptography has an This section offers a comprehensive overview of cryptographic stan- impact on encryption and digital signatures. This means that post- dards for different protocols and provides cryptographic recommenda- quantum encryption algorithms can replace current ones, such as RSA tions based on the supported cryptographic mechanisms. Its primary or ECC. Typically, S/MIME relies on the widely-used RSA encryption goal is to assist researchers, developers, and security practitioners in algorithm. However, to ensure secure encryption against quantum com- gaining a clear understanding of these standards and in effectively puters, it should be replaced with quantum-safe algorithms in a hybrid implementing robust security measures. By providing detailed infor- approach [298]. mation and insights, the section equips its intended audience with By using a combination of classical cryptographic algorithms and the knowledge necessary to navigate the complexities of cryptographic post-quantum algorithms, a post-quantum hybrid S/MIME system can protocols and ensure the implementation of robust security practices. 30 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 28 IETF cryptographic standards/drafts for SAML. Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 8409 [185] 2019 The Entity Category (SAML) ∙ Describes two SAML entity attributes: ∙ Refer to Table 12 for digital signatures Attribute Types one to indicate an entity’s membership in a category, and another to signal that an entity supports or interoperates with entities in such categories. ∙ Support:Digital signature 7833 [186] 2016 A RADIUS Attribute, Binding, ∙ Describes the use of the SAML with ∙ Refer to Table 31 for TLS Profiles, Name Identifier RADIUS in the context of the Application SAML Format, and Confirmation Bridging for Federated Access Beyond web Methods for the (SAML) (ABFAB) architecture ∙ Support: TLS 7522 [187] 2015 SAML 2.0 Profile for OAuth 2.0 ∙ Defines the use of a SAML 2.0 Bearer ∙ Refer to Table 12 for asymmetric digital signature Client Authentication and Assertion as a means for requesting an ∙ Refer to Table 10 for Hash recommendations Authorization Grants OAuth 2.0 access token as well as for ∙ Refer to Table 31 for TLS client authentication ∙ Refer to Table 24 for PKI recommendations ∙ Support: Asymmetric digital signature (RSA), Hash function (SHA-256), X.509 6595 [188] 2015 A Simple Authentication and ∙ Specifies a SASL mechanism and a ∙ Refer to Table 31 for TLS Security Layer (SASL) and GSS-API mechanism for SAML 2.0 that ∙ Refer to Table 24 for PKI recommendations GSS-API Mechanism for the allows the integration of existing SAML. SAML Identity Providers with applications using SASL and GSS-API ∙ Support: TLS, X.509 Table 29 OASIS cryptographic standards/drafts for SAML. Protocol Standard Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 2007 Metadata Profile for the OASIS Security ∙ Defines a profile of the OASIS SAML ∙ Refer to Table 10 for Hash Assertion Markup Language (SAML) V1.x V2.0 metadata specification for use in [189] describing SAML V1.0 and V1.1 entities. ∙ Support: Hash function 2005 Assertions and Protocols for the OASIS ∙ Defines the syntax and semantics for ∙ Refer to Table 31 for TLS/SSL SAML V2.0 [190] XML-encoded assertions about ∙ Refer to Table 8 for asymmetric cryptography authentication, attributes, and authorization ∙ Refer to Table 10 for Hash recommendations ∙ Support: TLS/SSL, Asymmetric, Hash SAML OASIS function 2011 SAML v2.0 Metadata Profile for Algorithm ∙ Defines metadata extension elements to ∙ Refer to Table 8 and Table 12 for asymmetric Support Version 1.0 [191] enable entities to describe the XML cryptography Signature [XMLSig] algorithms they ∙ Refer to Table 6 for symmetric encryption support ∙ Refer to Table 10 for Hash recommendations ∙ Support: Symmetric cryptography, Asymmetric cryptography, HASH function 2010 SAML V2.0 Holder-of-Key Web Browser ∙ The SAML V2.0 Holder-of-Key Web ∙ Refer to Table 31 for TLS/SSL SSO Profile Version 1.0 [192] Browser SSO Profile allows for transport of ∙ Refer to Table 24 for PKI recommendations holder-of-key assertions by standard HTTP user agents with no modification of client software and maximum compatibility with existing deployments ∙ Support: TLS, SSL, X.509 12. Discussion secure against quantum attacks by using larger key sizes or different algorithms. Many existing cryptographic standards, such as AES and Post-Quantum Cryptography (PQC) is designed to be secure against SHA-3, have been analyzed to determine their resistance to quan- both classical and quantum computers. PQC algorithms rely on math- tum attacks, and recommendations have been made to increase their ematical problems that are considered challenging for quantum com- security. Therefore, in this work, we have presented both classical puters to solve. Efforts to develop PQC standards are ongoing and and post-quantum recommendations for block ciphers, hash and MAC several organizations are actively involved in this area. For exam- functions, key establishment, digital signatures, some widely used cryp- ple, NIST has launched a competition to develop PQC standards. The tographic protocols, and so on. These recommendations can be used competition is now in its final stage, and several post-quantum cryp- to protect sensitive information in the post-quantum era. The main tography algorithms have been selected as finalists and standardized, goal of these recommendations is to ensure the ongoing security of as discussed in Section 1.2. However, PQC is not the only solution cryptographic standards in response to advancements in quantum com- to the quantum threat. Classical cryptography can also be made more puting. 31 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 30 IETF cryptographic standards for OAuth. Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 9201 [193] 2022 Introducing Additional OAuth Parameters Introduces novel parameters and encodings ∙ Refer to Table 6 for symmetric encryption for Authentication and Authorization in intended to enhance the OAuth 2.0 token Constrained Environments (ACE) and introspection endpoints ∙ Support: Symmetric key 8705 [194] 2020 OAuth 2.0 Protocol for Mutual-TLS Client ∙ Support: Asymmetric key (RSA), Hash ∙ Refer to Table 8 and Table 13 for asymmetric Authentication and Certificate-Bound function (SHA-256), TLS cryptography Access Tokens ∙ Refer to Table 10 for Hash recommendations ∙ Refer to Table 31 for TLS 7662 [195] 2015 OAuth 2.0 Token Introspection ∙ Support: TLS, SSL ∙ Refer to Table 31 for TLS/SSL 7523 [196] 2015 Profile of JSON Web Token (JWT) usage ∙ Support: Hash function, TLS ∙ Refer to Table 10 for Hash recommendations for OAuth 2.0 Client Authentication and ∙ Refer to Table 31 for TLS Authorization Grants 7628 [197] 2015 A collection of Simple Authentication and OAuth Security Layer (SASL) Mechanisms devised for integration with OAuth 7636 [198] 2015 Utilization of Proof Key for Code Exchange by Public Clients under OAuth 7521 [199] 2015 Framework for Assertion within OAuth 2.0 ∙ Support: Asymmetric digital signature ∙ Refer to Table 12 for asymmetric digital signature Client Authentication and Authorization (ECDSA P-256), Hash and MAC functions Grants (SHA-256, MAC) ∙ Refer to Table 10 and Table 11 for Hash and MAC recommendations, respectively 7522 [187] 2015 Exploration of SAML 2.0’s application as a ∙ Support: Asymmetric digital signature ∙ Refer to Table 12 for asymmetric digital signature profile for OAuth 2.0 Client Authentication (RSA), Hash and MAC functions (SHA-256, and Authorization Grants MAC), TLS ∙ Refer to Table 10 and Table 11 for Hash and MAC recommendations, respectively ∙ Refer to Table 31 for TLS 9101 [200] 2021 Enhancing OAuth 2.0 by securing ∙ Support: Asymmetric encryption (DSA, ∙ Refer to Table 8 and Table 12 for asymmetric authorization requests with JWT RSA, GOST) and signature (ECDSA P-256), cryptography symmetric encryption (DES/3DES/GOST), ∙ Refer to Table 6 for symmetric encryption Hash functions (MD5, SHA-1, GOST) ∙ Refer to Table 10 for hash algorithms 9200 [201] 2022 Authentication and Authorization within ∙ Support: Asymmetric digital signature, ∙ Refer to Table 12 for asymmetric digital signature Constrained Environments leveraging the Hash and MAC functions, TLS ∙ Refer to Table 10 and Table 11 for Hash and OAuth 2.0 Framework (ACE-OAuth) MAC recommendations, respectively ∙ Refer to Table 31 for TLS 6819 [202] 2013 Threat Model and Security Considerations ∙ Support: Asymmetric Cryptography, ∙ Refer to Table 8 and Table 12 for asymmetric pertaining to OAuth 2.0 Symmetric Keys, Hash and MAC functions, cryptography TLS ∙ Refer to Table 6 for symmetric encryption 7591 [203] 2015 Dynamic Client Registration Protocol for ∙ Support: Asymmetric digital signature ∙ Refer to Table 12 for asymmetric digital signature OAuth 2.0 (RS256), MAC function, TLS ∙ Refer to Table 11 for MAC recommendations ∙ Refer to Table 31 for TLS 6750 [204] 2012 The OAuth 2.0 Authorization Framework: ∙ Support: Asymmetric digital signature, Bearer Token Usage MAC function, TLS 9068 [205] 2021 Profile of JWT meant for OAuth 2.0 Access ∙ Support: Asymmetric digital signature, ∙ Refer to Table 8 and Table 12 for asymmetric Tokens digital signature 6749 [206] 2012 The OAuth 2.0 Authorization Framework ∙ Support: MAC functions, TLS ∙ Refer to Table 11 for MAC recommendations ∙ Refer to Table 31 for TLS 7009 [207] 2013 OAuth 2.0 Token Revocation 7592 [208] 2015 Management Protocol for Dynamic Client Registration within OAuth 2.0 ∙ Support: TLS ∙ Refer to Table 31 for TLS 8252 [209] 2017 OAuth 2.0 Application Pattern for Native Apps 8414 [210] 2018 Metadata for OAuth 2.0 Authorization Servers 8628 [211] 2019 OAuth 2.0 Device Authorization Grant 8693 [212] 2020 OAuth 2.0 Token Exchange For instance, we have provided recommendations on the appro- available post-quantum mechanisms for asymmetric cryptography. It is priate key and hash sizes for symmetric cryptography to maintain important to note that the development of post-quantum cryptography a quantum-resistant environment. We also recommend considering standards and the evaluation of classical standards against quantum 32 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 31 IETF cryptographic standards/drafts for well-known network protocols (TLS/SSL). Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 5288 2008 AES-GCM Cipher Suites for TLS provide ∙ Support: ∙ Refer to Table 13 for asymmetric key exchange [216] confidentiality and data origin Asymmetric key exchange (RSA, DSA, DH) ∙ Refer to Table 6 and Table B.37 for symmetric authentication. Symmetric encryption (AES-GCM encryption and recommendations on classical and (128/256)) PQ modes Hash functions (SHA-2-256/384) ∙ Refer to Table 10 and Table 11 for Hash and MAC recommendations, respectively 5487 2009 Enhancing security with TLS Pre-Shared ∙ Support: ∙ Refer to Table 13 for asymmetric key exchange [217] Key (PSK) cipher suites featuring Asymmetric key exchange (PSK, DHE_PSK, ∙ Refer to Table 6 SHA-256/384 and AES GCM and RSA_PSK) and Table B.37 for symmetric encryption and Symmetric encryption (AES-GCM recommendations on classical and PQ modes (128/256)) ∙ Refer to Table 10 and Table 11 for Hash and Hash and MAC functions (SHA-256/384, MAC recommendations, respectively HMAC) 5489 2009 ECDHE_PSK Cipher Suites for TLS ∙ Support: TLS/SSL [218] Asymmetric key exchange (ECDHE_PSK) Symmetric encryption (3DES, AES-CBC (128/256)) Hash and MAC functions (SHA-1, SHA-256/384, HMAC) 5932 2010 Specify a collection of cipher suites for ∙ Support: [219] TLS that support the Camellia encryption Asymmetric key exchange (RSA, DHE_RSA, algorithm DH_RSA, DHE_DSS, DH_DSS) Symmetric encryption (Camellia-CBC (128/256)) Hash and MAC functions (SHA-1 , SHA-256, HMAC) 6655 2012 AES-CCM Cipher Suites for TLS ∙ Support: [220] Asymmetric key exchange (PSK, RSA, DHE_RSA) Symmetric encryption (AES-CCM (128/256)) Hash and MAC functions (SHA-256, HMAC) 7251 2014 Illustrating AES-CCM integration in TLS ∙ Support: [221] and define cipher suites using ECC Asymmetric key exchange (ECDHE_ECDSA) Symmetric encryption (AES-CCM (128/256)) Hash and MAC functions (SHA-256/384/512, HMAC) 8446 2018 Specifies TLS Protocol Version 1.3 ∙ Support: ∙ Refer to Table 13 and Table 12 for asymmetric [222] Asymmetric key exchange (PSK, RSA, DH, key exchange and digital signature, respectively ECDHE (secp256r1, X25519)) and digital ∙ Refer to Table 6 and Table B.37 for symmetric signature (RSASSA-PSS, encryption and recommendations on classical and RSASSA-PKCS1-v1_5, ECDSA) PQ modes Symmetric encryption (AES-CCM/GCM ∙ Refer to Table 10 and Table 11 for Hash and (128/256)) MAC recommendations, respectively Hash and MAC functions (SHA-1, SHA-256/384/512, HMAC) (continued on next page) attacks is an ongoing process. As quantum computing technology con- be crypto-agile, organizations can ensure they are prepared to in- tinues to evolve, new attacks may emerge, requiring the development tegrate new algorithms without overhauling their entire infrastruc- of new defenses. Therefore, ongoing research and development in ture. This forward-thinking approach future-proofs security systems, quantum-resistant cryptography is crucial to safeguard sensitive in- allowing them to remain resilient in the face of evolving threats. formation in the post-quantum era. To address this challenge, we As a concrete illustration of crypto-agility, Section 3.3.3 presents a suggest adopting crypto-agile practices. Crypto-agility [299] refers to phased migration for financial-grade TLS from RSA-2048 key exchange the ability of a cryptographic system to switch quickly and seamlessly to a hybrid RSA+ Kyber1024 handshake. The plan preserves backward between different cryptographic algorithms, protocols, and standards compatibility, enables controlled canary rollouts, and limits operational as they evolve. This adaptability is essential because, as quantum change to load-balancer configuration, HSM policy, and certificate computing progresses, algorithms that are currently considered se- workflows rather than a complete redesign PKI redesign. The measured cure may become vulnerable to quantum-based attacks, while new latency and bandwidth impacts remain within the online banking bud- quantum-resistant algorithms will emerge. By designing systems to gets, and Kyber’s compact artifacts fit existing X.509 v3 structures and 33 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 31 (continued). Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 5289 2008 Introducing cipher suites based on ECC ∙ Support: ∙ Refer to Table 13 and Table 12 for asymmetric [223] featuring SHA-256/384 and AES-GCM Asymmetric key exchange (ECDHE) and key exchange and digital signature digital signature (ECDSA, RSA) ∙ Refer to Table 6 for symmetric encryption Symmetric encryption ∙ Refer to Table 10 and Table 11 for Hash and (AES-GCM/CBC-128/256) MAC recommendations, respectively Hash and MAC functions (SHA-256/384, HMAC) 6101 2011 Specifies the SSL 3.0 protocol ∙ Support: [224] Asymmetric key exchange (RSA, DH) and digital signature (RSASSA-PKCS1, DSS) Symmetric encryption (DES, 3DES) Hash and MAC functions (SHA, MD5, MAC) 9325 2022 Offering best practices for the secure use ∙ Support: [225] of TLS/DTLS Asymmetric key exchange (ECDHE) and digital signature (ECDSA, RSA) Symmetric encryption (AES-GCM-128/256) Hash and MAC functions (SHA-256/384, HMAC) 8422 2018 Describe key exchange algorithms based on ∙ Specifies the use of ECDHE key ∙ Refer to Table 13 and Table 12 for asymmetric [226] ECC for the TLS agreement in a TLS handshake key exchange and digital signature ∙ Support: ∙ Refer to Table 6 and Table B.37 for symmetric Asymmetric key exchange (ECDHE) and encryption and recommendations on classical and digital signature (ECDSA, EdDSA, RSA) PQ modes Symmetric encryption ∙ Refer to Table 10 for Hash recommendations (AES-CBC/GCM-128/256) Hash functions (SHA-256/384) 9367 2023 GOST Cipher Suites for TLS 1.3 ∙ Specifies the utilization of GOST ∙ Refer to Table 13 and Table 12 for asymmetric [227] algorithms to establish cipher suites, key exchange and digital signature signature schemes, and key exchange ∙ Refer to Table 6 for symmetric encryption methods ∙ Refer to Table 10 and Table 11 for Hash and ∙ Support: MAC recommendations, respectively Asymmetric key exchange (ECDHE, PSK) and digital signature (GOST R 34.10-2012) Symmetric encryption (GOST R 34.12-2015) Hash and MAC functions (GOST R 34.11-2012, HMAC) 8734 2020 ECC Brainpool Curves for TLSv1.3 ∙ Incorporates essential protocol ∙ Refer to Table 13 and Table 12 for asymmetric [228] mechanisms to enable the utilization of key exchange and digital signature ECC Brainpool curves within TLS 1.3 ∙ Refer to Table 10 for Hash recommendations ∙ Support: Asymmetric key exchange (ECDHE) and digital signature (ECDSA) Hash functions (SHA-256/384/512) 7027 2013 Specifies ECC Brainpool Curves for TLS ∙ Provides authentication and key ∙ Refer to Table 13 for asymmetric key exchange [229] exchange ∙ Support: Asymmetric cryptography for key exchange (ECC Brainpool curves) 6091 2011 Define TLS authentication use ∙ Also establishes a registry for non-X.509 ∙ Refer to Table 13 [230] certificate types for asymmetric key ∙ Support: exchange Asymmetric key exchange (DHE_DSS, DHE_RSA) 7366 2014 Propose a method to facilitate the ∙ Addressing the security vulnerabilities ∙ Refer to Table 6 for symmetric encryption [231] negotiation of the encrypt-then-MAC associated with the MAC-then-encrypt ∙ Refer to Table 11 for MAC recommendations security mechanism within TLS/DTLS ∙ Support: Symmetric encryption MAC function (HMAC) (continued on next page) certificate-transparency processes. This hybrid posture provides an im- In summary, the threat quantum computing poses to cryptography is mediate rollback path as standards evolve and helps satisfy regulatory a significant challenge that requires continuous attention and research. expectations for crypto-agility in payment environments. PQC and classical standards resistant to quantum attacks are being 34 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 31 (continued). Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 9147 2022 Specify version 1.3 of the DTLS protocol ∙ Enabling secure communication over the ∙ Refer to Table 6 for symmetric encryption [232] Internet while preventing eavesdropping, ∙ Refer to Table 10 for Hash recommendations tampering, and message forgery ∙ Support: Symmetric encryption (AES-GCM/CCM-128/256) Hash-function (SHA-256) 7905 [43] 2016 ChaCha20-Poly1305 Cipher Suites for TLS ∙ Outline the utilization of the ChaCha ∙ Refer to Table 8 and Table 13 for asymmetric stream cipher and Poly1305 authenticator encryption and key exchange, respectively in the TLS and DTLS protocols ∙ Refer to Table 10 for Hash recommendations ∙ Support: Asymmetric key exchange (DHE_RSA, ECDHE_RSA, ECDHE_ECDSA) Symmetric encryption (CHACHA20) Hash functions (SHA-256, POLY1305) TLS-Hybrid draft-ietf- 2023 Introduce hybrid key exchange in TLS 1.3 ∙ Utilizing multiple key exchange ∙ Refer to Table 13 for asymmetric key exchange tls-hybrid- algorithms simultaneously for enhanced ∙ Refer to Table 10 for Hash recommendations design-10 security in the post-quantum cryptography [113] era (Draft is Expired in October 2024) ∙ Support: Asymmetric key exchange (ECDHE (x25519, secp256r1) with kyber (512, 768) Hash functions (SHA-3) developed, but the field is constantly evolving. Organizations must stay strategies, particularly in authentication and communication proto- up-to-date with the latest advancements in quantum-resistant cryptog- cols, will better protect sensitive data and communications during the raphy to ensure the security of their digital communications and data. transition. This approach mitigates the risks associated with quantum Furthermore, we recommend implementing ‘‘crypto-agile’’ practices for vulnerabilities without requiring a complete redesign of existing sys- existing cryptographic systems. This involves designing systems that tems, ensuring continuity. Furthermore, these recommendations pro- can easily adapt to new cryptographic standards, recommendations, vide forward-looking strategies to help organizations future-proof their and algorithms as they are developed, ensuring ongoing security in the security infrastructure as quantum technologies evolve. era of quantum computing. The adoption of crypto-agile systems will be pivotal in navigating the uncertainties of the post-quantum era. Crypto-agile systems, de- 13. Conclusion signed to adapt to evolving cryptographic standards, will empower organizations to swiftly respond to future cryptographic challenges. The advent of quantum computing poses a significant threat to Future research should continue to refine quantum-resistant cryp- the security of traditional cryptographic algorithms, necessitating an urgent shift toward a quantum-resistant environment. In this paper, we tographic techniques, optimize hybrid implementations, and ensure provide a comprehensive evaluation of cryptographic standards across seamless integration of these solutions into global standards and widely various domains, including both symmetric and asymmetric algorithms, adopted protocols. By embracing these recommendations and fostering and propose quantum-resistant recommendations to facilitate a secure cryptographic agility, the global cryptographic community can pave the transition for existing systems. Our analysis covers essential crypto- way for a quantum-resistant future, ensuring the long-term security of graphic primitives, such as block and stream ciphers, hash functions, digital systems in the quantum age. digital signatures, and key establishment protocols. We also review global cryptographic standards and security recommendations from CRediT authorship contribution statement various countries to assess the current state of readiness for quantum threats. Additionally, we examine the quantum readiness of cryptographic Vikas Chouhan: Writing – review & editing, Writing – original standards and provide essential Quantum-Resistant/Post-Quantum (PQ) draft, Validation, Project administration, Methodology, Investigation, recommendations for authentication. This includes entity-based au- Formal analysis, Conceptualization. Mohammed Aldarwbi: Writing – thentication standards, public key infrastructure for certificate-based review & editing, Writing – original draft, Supervision, Project admin- authentication, and specific PQ recommendations for widely used istration, Investigation, Formal analysis, Conceptualization. Somayeh authentication protocols such as Kerberos, DNSSEC, SAML, and OAuth. Sadeghi: Writing – review & editing, Writing – original draft, Val- We further explore the standards for communication protocols, in- idation, Investigation, Formal analysis. Ali Ghorbani: Supervision, cluding TLS, IPsec, SSH, FTP, and S/MIME, offering the necessary PQ Resources, Project administration. Aaron Chow: Writing – review & recommendations for these protocols. These standards are crucial for editing, Validation, Supervision, Project administration, Methodology, securing data transmission and maintaining integrity across diverse Investigation, Formal analysis. Robby Burko: Validation, Supervision, applications, particularly as we transition to a quantum-resistant en- Project administration, Investigation, Formal analysis. vironment. Moreover, we assess hybrid cryptographic standards and emerging drafts that combine classical and quantum-resistant mech- Declaration of competing interest anisms to ensure backward compatibility and minimize disruption during the transition. The proposed quantum-resistant recommendations offer immediate The authors declare that they have no known competing finan- benefits by strengthening cryptographic defenses against both classi- cial interests or personal relationships that could have appeared to cal and quantum-based attacks. Organizations that adopt these PQ influence the work reported in this paper. 35 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 32 IETF cryptographic standards/drafts for well-known network protocols (IPsec/IKE). Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ draft-ietf-ipsecme- 2023 Establish a mechanism in the IKEv2 that ∙ Expired in October 2023 ∙ Refer to Table 12 for asymmetric digital signature ikev2-auth- enables implementations to communicate ∙ Support: announce-03 the list of supported authentication Asymmetric digital signature (RSA, DSS, ∙ Refer to Table 10 for Hash recommendations [233] methods ECDSA-SHA-256 (P-256 curve), ECDSA-SHA-384 (P-384 curve)), ECDSA-SHA-512 (P-521 curve) Hash functions (SHA-256/384) 7296 [234] 2014 Describe IKEv2 ∙ Support: ∙ Refer to Table 12 and Table 13 for asymmetric Asymmetric Digital Signature digital signature and Key exchange, respectively (RSASSA-PKCS1-v1_5) ∙ Refer to Table 6 for symmetric encryption Diffie–Hellman exchange ∙ Refer to Table 10 and Table 11 for Hash and Symmetric encryption (3DES, IDEA, MAC recommendations, respectively AES-128/192/256) ∙ Refer to Table 24 for PKI recommendations IKE Hash (MD5, SHA-1) and MAC (HMAC, CMAC) functions PKI 9370 [235] 2023 Describe the extension of the IKEv2 to ∙ Support: ∙ Refer to Table 13 for Key exchange allow multiple key exchanges Asymmetric key exchange ∙ Refer to Table 6 for symmetric encryption (DH,ECDH,PQ_KEM) ∙ Refer to Table 10 and Table 11 for Hash and Symmetric encryption (AES) MAC recommendations, respectively Hash (SHA-2) and MAC (HMAC) functions 7427 [236] 2015 Signature authentication in the IKEv2 ∙ Introduces negotiation for the signature ∙ Refer to Table 12 for asymmetric digital signature hash algorithm ∙ Support: ∙ Refer to Table 8 for asymmetric encryption Asymmetric Digital Signature (RSA, DSA, ∙ Refer to Table 10 for Hash recommendations ECDSA, RSASSA-PSS,ECGDSA, ElGamal) ∙ Refer to Table 24 for PKI recommendations Asymmetric encryption (RSA) Hash (SHA-1, SHA-2, SHA-3) functions PKI 6989 [237] 2013 Additional Diffie–Hellman Tests for the ∙ Ensuring the secure operation of the ∙ Refer to Table 13 for key exchange IKEv2 IKEv2 specifically with elliptic curve groups ∙ Support: Asymmetric Key exchange (DH, ECDH) 4754 [238] 2007 IKE and IKEv2 Authentication Using the ∙ Emphasizes that the addition of ECDSA ∙ Refer to Table 12 for asymmetric digital signature ECDSA does not require any modifications to the existing IKE ∙ Refer to Table 10 for Hash recommendations ∙ Support: Asymmetric digital signature (ECDSA-256, ECDSA-384, ECDSA-521) Hash functions (SHA-256/384/512) (continued on next page) Appendix A. Standardization organizations effort between ISO and the IEC. JTC1 has several subcommittees, including JTC1/SC17, JTC1/SC27, and JTC1/SC37, which all fo- Standardization organizations play a crucial role in establishing cus on different aspects of cryptographic standards. JTC1/SC17 uniformity and quality benchmarks across industries worldwide, facil- is responsible for developing international standards for per- itating cooperation among stakeholders to develop and maintain stan- sonal identification and security cards, while the main focus of dards that enhance efficiency, interoperability, and consumer safety. JTC1/SC27 is on innovation related to information technology Below are the following standardization organizations that contribute security, such as cryptography, intrusion detection, and incident to shaping global/national norms and practices across various sectors. management. Finally, JTC1/SC37 is responsible for develop- A.1. International standardization organizations ing international standards for biometric techniques, such as fingerprint recognition and facial recognition. (i) International Organization for Standardization (ISO) The technical committee, TC68, focused on the financial services The standardization efforts of ISO21 are carried out by multi- industry, comprises several subcommittees that specialize in ple Technical Committees (TCs) that focus on specific fields of using cryptography to protect financial information. These sub- study. These committees assign responsibilities to Subcommit- committees primarily interpret the general cryptography stan- tees (SCs), which further distribute the workload among multi- dards established by JTC1 and adapt them for use in the financial ple Working Groups (WGs). The development of cryptographic domain. standards within ISO is primarily handled by two technical ISO standards are assigned standard numbers that are used to committees: TC68 and JTC1, the latter being a collaborative refer to them. For instance, ISO 8730 specifies the requirements for message authentication codes utilized in the financial sector. 21 https://www.iso.org When ISO and the IEC publish a standard jointly via the JTC, 36 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 32 (continued). Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 4307 [239] 2005 Define a set of mandatory-to-implement ∙ Support: ∙ Refer to Table 6 for symmetric encryption cryptographic algorithms for the IKEv2 Symmetric encryption (3DES-CBC, ∙ Refer to Table 10 and Table 11 for Hash and AES-128-CBC, AES_CTR, AES128_CBC, MAC recommendations, respectively AES_XCBC_96) Hash and MAC functions (HMAC_MD5, HMAC_MD5_96, HMAC-SHA-1, HMAC_SHA-1_96) 4434 [240] 2006 Describe the AES-XCBC-PRF-128 algorithm ∙ Support: for the IKE Symmetric encryption (AES-XCBC-PRF-128) Hash and MAC functions (HMAC-SHA-1, MAC-PRF) 5930 [241] 2010 Utilize the AES-CTR with the IKEv2 ∙ AES-CTR is employed by IKEv2 to ∙ Refer to Table 6 for symmetric encryption enhance the security and confidentiality of data transmission ∙ Support: Symmetric encryption (AES-CTR) 8420 [242] 2018 Utilization of the EdDSA within the IKEv2 ∙ Providing secure digital signatures and ∙ Refer to Table 12 for asymmetric digital ensuring the authenticity and integrity of signatures the exchanged data ∙ Support: Asymmetric digital signature (EdDSA) 8784 [243] 2020 Mixing Preshared Keys in the IKEv2 for ∙ Describe the extension of IKEv2 to ∙ Refer to Tables 8, 12, and 13 for asymmetric Post-quantum Security provide resistance to quantum computers cryptography through the utilization of preshared keys ∙ Refer to Table 6 for symmetric encryption IKE-PQ ∙ Support: Asymmetric cryptography Symmetric encryption draft-smyslov- 2023 Alternative procedure for Mixing Preshared ∙ Provide protection against quantum ∙ Refer to Table 13 for key establishment ipsecme-ikev2-qr- Keys in IKEv2 for PQ Security computers for both IPsec traffic and the mechanisms alt-07 [244] initial IKEv2 SA in scenarios. This draft Expired in October 2023 ∙ Support: Pre-shared key mechanism it is recognized as an ISO/IEC standard. Notably, ISO 2700122 (ii) International Electrotechnical Commission (IEC) is one of the most widely adopted international standards for The IEC26 is in charge of producing standards for all types of Information Security Management Systems (ISMS). It offers orga- electrical and electronic technologies. Regarding cryptography nizations a systematic approach to managing sensitive company and security-related issues, the IEC’s primary emphasis is on its information, ensuring its security across people, processes, and collaboration with ISO through the joint technical committee, IT systems by implementing a robust risk management pro- JTC1. This collaboration helps the IEC to achieve its objectives cess. ISO 2700223 provides best practice recommendations on in this field. information security management for use by those responsible (iii) International Telecommunication Union (ITU) for initiating, implementing, or maintaining ISMS. ISO 2701724 ITU27 is an organization sponsored by the United Nations that offers guidelines for information security controls applicable to aims to facilitate global telecommunications networks and ser- the provision and use of cloud services, ensuring both cloud vices through government and corporate collaboration. ITU is service providers and their customers have the same informa- divided into three main branches, namely ITU-R, ITU-D, and tion security controls to mitigate risks in the cloud environ- ment. ISO 2701825 focuses on protecting personal data in the ITU-T, where ITU-R is responsible for radio communication, cloud, establishing control objectives, controls, and guidelines ITU-D focuses on the development of telecommunications ser- for implementing measures to protect Personally Identifiable vices, and ITU-T creates telecommunications standards. One of Information (PII) in accordance with the privacy principles in the most important standards in ITU-T is the X series, which ISO 29100 for the public cloud computing environment. These is concerned with data networks and emphasizes network de- ISO standards are essential for organizations to establish robust sign over cryptography. However, the X series covers signifi- information security management practices, especially in the era cant topics such as public-key infrastructures and cryptographic of increasing cyber threats and data breaches. In addition to network services. ITU-T standards are typically referred to as standards, ISO issues technical reports, which are specifications ‘‘recommendations’’. for specific tasks rather than actual standards. Technical reports (iv) Internet Engineering Task Force (IETF) can be recognized by the letters ‘‘TR’’, as seen in the example of The Internet is the outcome of a collaborative effort between ISO/IEC TR 14516, which provides recommendations regarding various entities such as governments, academia, and enterprises the utilization of trusted third parties. to establish a global communication network. To ensure the Internet functions efficiently and securely, it must be built on 22 https://www.iso.org/standard/27001 23 https://www.iso.org/standard/75652.html 24 26 https://www.iso.org/standard/82878.html https://www.iec.ch 25 27 https://www.iso.org/standard/76559.html https://www.itu.int 37 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 33 (Cont.) IETF cryptographic standards/drafts for well-known network protocols (IPsec/IKE). Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 3602 [245] 2003 Describes the utilization of the ∙ Support: ∙ Refer to Table 6 for symmetric encryption AES-CBC Cipher Algorithm for the Symmetric encryption ∙ Refer to Table 10 and Table 11 for Hash and IPsec Encapsulating Security (AES-CBC-128/192/256) MAC recommendations, respectively Payload (ESP) Hash and MAC functions (SHA-256/384/512, HMAC) 3566 [246] 2003 Introduces the AES-XCBC-MAC-96 ∙ Support: algorithm and specifies its use with Symmetric encryption (AES-XCBC, IPsec AES-128) Hash and MAC functions (HMAC) 4494 [247] 2006 Specify the use of the AES-CMAC-96 ∙ Support: algorithm for the IPsec Symmetric encryption (AES-CMAC-96) Hash and MAC functions (MAC, CMAC) 4894 [248] 2007 Discuss the usage of hash functions ∙ Support: ∙ Refer to Table 6 for symmetric encryption IPsec/IKE in the IKEv1, IKEv2, and IPsec Symmetric encryption (AES-XCBC-PRF-128) ∙ Refer to Table 10 and Table 11 for Hash and protocols Hash and MAC functions MAC recommendations, respectively (SHA-256/384/512, HMACs) ∙ Refer to Table 24 for PKI recommendations PKI 4308 [249] 2005 Provide the specification for ∙ Support: ∙ Refer to Table 6 for symmetric encryption cryptographic suites used in IPsec Symmetric encryption ∙ Refer to Table 10 and Table 11 for Hash and (TripleDES-CBC,AES-XCBC) MAC recommendations, respectively Hash and MAC functions ∙ Refer to Table 13 for key establishments Diffie–Hellman 6379 [250] 2011 Proposes cryptographic user ∙ Support: interface suites for IPsec Symmetric encryption (AES-GCM/GMAC-128/256) Hash and MAC functions (HMAC-SHA-256/384) Diffie–Hellman 4106 [251] 2005 Utilization of GCM mode in IPsec ∙ Support: ∙ Refer to Table 6 for Encapsulating Security Payload Symmetric encryption symmetric encryption (ESP) (AES-GCM-128/192/256) 4312 [36] 2005 Describe the utilization of the ∙ Support: Camellia algorithm for IPsec Symmetric encryption (Camellia-128/192/256) 3526 [252] 2003 Define new Modular Exponential ∙ Introduces new Diffie–Hellman groups ∙ Refer to Table 13 for key exchange (MODP) Diffie–Hellman Groups for with varying bit lengths (2048, 3072, ∙ Refer to Table 6 for symmetric encryption the IKE 4096, 6144, and 8192) ∙ Support: Asymmetric Key exchange (Diffie–Hellman (2048 to 8192 bit MODP Group)) Symmetric encryption (AES-128/192/256) (continued on next page) standardized communication protocols, which the IETF28 de- IANA29 initially administered by Jon Postel in the late 1970s, signs. Apart from the IETF, the Internet Research Task Force IANA’s functions are now operated by the Internet Corporation (IRTF) is also responsible for exploring research issues relevant for Assigned Names and Numbers (ICANN). It manages the to the Internet in the long run. The IRTF is focused on exploring global allocation of IP addresses, domain names, protocol pa- new and innovative solutions to some of the Internet’s most com- rameters, and other Internet resources. IANA’s work ensures the plex and challenging issues, such as network security, scalability, stable and secure operation of the Internet’s unique identifiers and performance. Through these efforts, the IRTF helps to ensure through its coordination and management of various registries, that the Internet remains a vital and reliable resource for people such as the Domain Name System (DNS) root zone and the around the world. Internet Protocol (IP) address space. Its responsibilities include In addition to developing Internet standards, the IETF has also overseeing the assignment of Internet number resources to Re- created a set of publication records called Requests for Com- gional Internet Registries (RIRs) and maintaining registries for ments (RFCs). These documents provide guidance, recommenda- protocol parameters defined by the Internet Engineering Task tions, and information on a wide range of topics related to the Force (IETF). Internet, including protocols, procedures, and concepts. RFCs are published openly and are freely available to the public, making A.2. National standardization organizations them an invaluable resource for developers, researchers, and anyone interested in the workings of the Internet. The establishment of national standardization organizations is a (v) Internet Assigned Numbers Authority (IANA) common practice across many countries aimed at ensuring standardiza- 28 29 https://www.ietf.org https://www.ietf.org/process/iana 38 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 33 (continued). Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 1828 [253] 1995 Utilization of keyed MD5 with the ∙ Keyed MD5 is utilized to provide ∙ Refer to Table 10 for Hash recommendations IP Authentication Header integrity and authentication ∙ Support: Hash function (MD5) 2085 [254] 1997 Describe a keyed-MD5 transform to ∙ Support: ∙ Refer to Table 10 and Table 11 for Hash and be used with the IP Authentication Hash and MAC functions (HMAC, MD5) MAC recommendations, respectively Header 2403 [255] 1998 Utilization of the HMAC algorithm with MD5 as an authentication mechanism in revised IPSEC 2404 [256] 1998 Utilization of the HMAC algorithm ∙ Support: using SHA-1 for authentication Hash and MAC functions (HMAC, SHA-1) purposes within the updated IPSEC 2857 [257] 2000 Utilization of the HMAC approach ∙ Support: using the RIPEMD-160 algorithm Hash and MAC functions (HMAC, for authentication within the RIPEMD-160) revised IPSEC 4868 [258] 2007 Employing HMAC along with the ∙ Support: SHA-256, SHA-384, and SHA-512 Hash and MAC functions (HMAC, algorithms within the realm of IPsec SHA-256/384/512) 6380 [259] 2011 Specify the conventions and ∙ Providing relevant details and aiding ∙ Refer to Tables 12 and 13 for asymmetric guidelines for using Suite B developers who opt to implement Suite B cryptography cryptography in (IPsec) cryptography in IPsec ∙ Refer to Table 6 for symmetric encryption ∙ Support: ∙ Refer to Table 10 and Table 11 for Hash and Asymmetric Key exchange (ECDH (P-256 & MAC recommendations, respectively P-384)) ∙ Refer to Table 24 for PKI recommendations Asymmetric digital signature (ECDSA (P-256 & P-384)) Symmetric encryption (AES-128/256) Hash (SHA-256/384) and MAC (HMAC, GMAC-128, GCM-256) functions PKI 5529 [35] 2009 Utilization of the Camellia ∙ Camellia algorithm is an ∙ Refer to Table 6 for symmetric encryption algorithm in various modes (CBC, optional-to-implement component in IKEv2 ∙ Refer to Table 11 for MAC recommendations CTR, and CCM) with IPsec and ESP, offering robust security features for secure communication over the Internet ∙ Support: Symmetric encryption (Camellia-CBC/CTR/CCM-128/192/256) MAC function tion in various fields. These entities have the autonomy to produce their (ii) British Standards Institution (BSI) standards while also collaborating with international standardization BSI32 is responsible for managing standardization efforts in the bodies to contribute to the development of global standards. This dual United Kingdom and serves as the official member body rep- role enables national standardization bodies to maintain a balance be- resenting the country in ISO. While BSI is not widely known tween domestic needs and global standards, promoting interoperability for its technical cryptographic standards, it has made signifi- and enhancing efficiency in various sectors. cant contributions to the field of management techniques. For instance, BSI has produced several influential standards, such as (i) American National Standards Institute (ANSI) ANSI30 functions as the coordinating organization for volun- the BS 7799-2 standard, which provides guidelines and require- tary standardization initiatives in the United States (U.S.) and ments for information security management systems. Overall, represents the U.S. in the ISO. In addition to its coordination BSI’s contributions to the field of standardization extend beyond role, ANSI is also responsible for developing its own standards, cryptography and highlight the importance of organizational which cover a wide range of industries and technologies. Among management and processes in ensuring security and efficiency in the standardization bodies accredited by ANSI, X931 is the most various sectors. Later, it was adopted by ISO (ISO/IEC 27001) in eminent in cryptography. X9 is dedicated to creating, publishing, 2005. and advocating standards for the financial services industry and (iii) National Institute of Standards and Technology (NIST) working in close collaboration with the ISO’s TC68 commit- NIST33 is a significant standards organization in the United tee. Thanks to its expertise and contributions, X9 has played States that operates as the federal agency responsible for stan- a vital role in ensuring the security and integrity of financial dardization within the technology administration of the U.S. transactions worldwide, and its standards are widely adopted by Commerce Department. In addition to its wide-ranging secu- financial institutions and organizations. 30 32 http://www.ansi.org https://www.bsigroup.com 31 33 https://x9.org https://www.nist.gov 39 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 34 IETF cryptographic standards/drafts for well-known network protocols (SSH). Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 4251 [260] 2006 SSH Protocol Architecture ∙ Support: ∙ Refer to Table 6 for symmetric encryption Symmetric encryption (3DES, AES) ∙ Refer to Table 13 for Key exchange Asymmetric key exchange (DH) ∙ Refer to Table 10 and Table 11 for Hash and Hash and MAC functions (MAC, HMAC, MAC recommendations, respectively SHA-1) 6668 [261] 2012 SHA-2 Data Integrity ∙ Support: ∙ Refer to Table 10 and Table 11 for Hash and Verification for the SSH Hash and MAC functions (HMAC, MAC recommendations, respectively SHA-2-256, SHA-2-512) draft-gutmann 2022 A Pre-Authentication Mechanism ∙ Support: -ssh-preauth-00 for SSH. This draft Expired in Hash and MAC functions (HMAC, [262] June 2023. SHA-256) 9142 [263] 2022 Revisions to the suggested ∙ Revision of SSH protocol’s key exchange ∙ Refer to Table 6 for symmetric encryption number of key exchange methods to address the need for stronger ∙ Refer to Table 13 for Key exchange SSH techniques within the SSH security ∙ Refer to Table 10 for Hash recommendations protocol ∙ Support: Asymmetric key exchange (ECC, DH, ECDH, RSA-1024/2048) Symmetric encryption (3DES-cbc, AES-128/192/256) Hash functions (SHA-1, SHA-256/384/512) 6594 [264] 2012 Enhance the SSHFP DNS ∙ Support: ∙ Refer to Table 12 for asymmetric digital Resource Record by Asymmetric digital signature (RSA, DSA, signatures incorporating the SHA-256 ECDSA) ∙ Refer to Table 10 for Hash recommendations algorithm with RSA, DSA, and Hash-function (SHA-256) ECDSA 8332 [265] 2018 Introducing new public key Asymmetric digital signature algorithms using RSA keys (RSASSA-PKCS1-v1_5) alongside SHA-256 and SHA-512 Hash functions (SHA-256/512) in the SSH Protocol 8709 [266] 2020 Outlines the utilization of the Asymmetric digital signature (Ed25519 and Ed25519 and Ed448 digital Ed448) signature schemes in the SSH Hash functions (SHA-256) 8731 [267] 2020 Specifies the usage of ∙ Incorporating key exchange methods in ∙ Refer to Table 12 and Table 13 for asymmetric Curve25519 and Curve448 key SSH for enhanced security and digital signature and key establishment exchange algorithms in the SSH cryptographic operations mechanisms, respectively protocol ∙ Support: ∙ Refer to Table 10 for Hash recommendations Asymmetric key exchange (ECDH, Curve25519, Curve448), key agreement (ECMQV), and digital signature (ECDSA) Hash functions (SHA-256/512) 8268 [268] 2017 Enhancement of the Modular ∙ Rectification of an error pertaining to the ∙ Refer to Table 8 and Table 12 for asymmetric Exponentiation (MODP) DH Key verification of the Peer’s DH Public Key cryptography Exchange (KEX) Groups ∙ Support: ∙ Refer to Table 10 for Hash recommendations dedicated to SSH Asymmetric key exchange (DH, ECDH, ECDSA) Hash functions (SHA-256/512) (continued on next page) rity standards, NIST has also developed various measurement, A.3. Industrial standardization organizations testing, and evaluation protocols. Nonetheless, NIST is perhaps best known for its role in creating the AES encryption algo- The production of cryptographic standards is not limited to govern- ments and government-led organizations, as the business community rithm, which is broadly implemented. NIST issues its standards also takes the initiative to establish standards in this field. as Federal Information Processing Standards (FIPS), which are mandated for use in various U.S. government agencies and by (i) Third Generation Partnership Project (3GPP) many private organizations. NIST is currently in the process The 3GPP34 is a collaborative platform that unites multiple of developing standards for Post-Quantum (PQ) cryptography, corporations and standardization organizations in developing third-generation cellular networks. Given that security and pri- which is designed to be resistant to attacks by quantum com- vacy are crucial aspects of these advanced networks, the 3GPP puters [8]. The goal is to ensure that the cryptographic systems used to secure our digital infrastructure remain secure even in 34 the face of quantum computing advances. http://www.3gpp.org 40 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 34 (continued). Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 6239 [269] 2011 Cryptographic Suites for SSH ∙ Incorporates ECDH key agreement, ∙ Refer to Table 12 and Table 13 for asymmetric ECDSA, AES-GCM, SHA-2 family hashes digital signature and key establishment (SHA-256 and SHA-384), and X.509 mechanisms, respectively certificates ∙ Refer to Table 6 for symmetric encryption ∙ Support: ∙ Refer to Table 10 and Table 11 for Hash and Asymmetric key agreement (ECDH) and MAC recommendations, respectively digital signature (ECDSA) Symmetric encryption (AES-GCM-128/256) Hash (SHA-256 and SHA-384) and MAC functions 4252 [270] 2006 Define the SSH authentication ∙ Support: ∙ Refer to Table 8 and Table 12 for asymmetric protocol designed for secure Asymmetric cryptography cryptography remote login and network Hash functions ∙ Refer to Table 10 for Hash recommendations services 4432 [271] 2006 RSA Key Exchange for the SSH ∙ Support: Protocol Asymmetric encryption (RSAES-OAEP (1024,2048)) Hash functions (SHA-1,SHA-256) 4344 [272] 2006 SSH Transport Layer Encryption ∙ Provides guidelines for SSH ∙ Refer to Table 6 for symmetric encryption Modes implementation rekeying ∙ Refer to Table 10 and Table 11 for Hash and ∙ Support: MAC recommendations, respectively Symmetric encryption (3DES-CTR, AES-CTR-128/192/256) Hash and MAC functions (HMAC, SHA-1) 4462 [273] 2006 Outlines the usage of the ∙ Support: ∙ Refer to Table 13 for asymmetric key exchange Generic Security Service Asymmetric key exchange (DH) ∙ Refer to Table 10 for Hash recommendations Application Program Interface Hash-function (SHA-1) (GSS-API) Authentication and Key Exchange within the framework of the SSH Protocol SSH-Hybrid draft-kampanakis- 2023 Defines PQ hybrid key exchange ∙ It combines classical ECDH key exchange ∙ Refer to Table 13 for asymmetric key exchange curdle-ssh-pq-ke- methods in the SSH with PQ KEM. This draft Expired in ∙ Refer to Table 10 and Table 11 for Hash and 01[111] October 2023 MAC recommendations, respectively ∙ Support: Asymmetric key exchange: Classical (ECDH (x25519)) and PQ (kyber-512/768/1024) Hash and MAC functions (SHA-256/384/512, HMAC) has played a crucial role in standardizing both network security second major standardization group is the 802 group, which characteristics and cryptographic approaches to ensure the pro- is focused on developing standards for wireless local area net- tection of sensitive information transmitted over these networks. works. This group is responsible for producing the widely used Through this effort, the 3GPP has helped to establish a high 802.11 series of standards, which have revolutionized the way level of security for mobile communications, which has become we connect to the Internet and communicate wirelessly. increasingly essential in our digital age. (iv) Standards for Efficient Cryptography Group (SECG) (ii) European Telecommunications Standard Institute (ETSI) Elliptic Curve Cryptography (ECC) was introduced as a novel ETSI35 is a self-governing entity that consists of organizations type of public-key cryptography based on complex mathematical that have a mutual objective of creating telecommunications structures in the early 1990s. A group of businesses spearheaded standards. It is among the organizational collaborators that par- by Certicom was the first to recognize the potential of this ticipate in coordinating the 3GPP project. innovative cryptographic approach in the corporate world. To (iii) Institute of Electrical and Electronics Engineers (IEEE) facilitate interoperability and tackle practical concerns associ- IEEE36 is a professional organization of engineers that strives to ated with ECC, these businesses established the SECG.37 In the facilitate the exchange of technical knowledge and information year 2000, two standards were released by the SECG. The first, related to electrical and electronic engineering. It also plays a SEC 1, standardized the application of ECC in cryptography. pivotal role in hosting conferences and publishing books and This standard laid out a framework for implementing elliptic journals to promote the dissemination of information in these curve cryptography in various settings such as digital signatures, fields. From a cryptographic standpoint, there are two major key exchange, and encryption. The second standard, SEC 2, standardization groups within the IEEE that are of particular advocated specific parameters, such as curve equations and point interest. The first group, known as the 1363 group, concentrates representations, for utilizing ECC. on developing standards related to asymmetric cryptography. (v) Public-Key Cryptography Standards (PKCSs) These standards cover a broad range of topics, including key RSA Laboratories stands out as one of the few companies that management, digital signatures, and public key encryption. The have independently developed a comprehensive set of standards in addition to collections of businesses producing industrial 35 http://www.etsi.org 36 37 https://standards.ieee.org http://www.secg.org 41 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 35 IETF cryptographic standards/drafts for well-known network protocols (FTP). Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 2228 [274] 1997 FTP Security Extensions ∙ Specify Internet standards and solicit ∙ Refer to Table 8 for asymmetric cryptography feedback for improvement ∙ Refer to Table 10 for Hash recommendations ∙ Support: ∙ Refer to Table 23 for Authentication FTP Asymmetric keys (RSA) Hash functions Authentication 2577 [275] 1999 To address security vulnerabilities ∙ Highlights issues with proxy FTP and ∙ Refer to Table 23 for Authentication in the FTP specification and unlimited password attempts, offering provide recommendations for suggestions for improving security in FTP mitigating associated risks implementations ∙ Support: Authentication 4253 [276] 2006 Describes SSH as a secure protocol ∙ Defines SSH transport layer, encryption, ∙ Refer to Table 12 and Table 13 for asymmetric for remote login and network authentication, and algorithms used for digital signature and Key exchange, respectively services over an insecure network secure network communication ∙ Refer to Table 6 and Table B.37 for symmetric ∙ Support: encryption and recommendations on classical and Asymmetric key exchange (DH) and PQ modes signature (RSASSA-PKCS1-v1_5, DSS) ∙ Refer to Table 10 and Table 11 for Hash and Symmetric encryption (3DES-CBC, MAC recommendations, respectively SFTP AES-CBC-128/192/256) ∙ Refer to Table 23 for Authentication Hash and MAC functions (MD5, SHA-1, ∙ Refer to Table 34 for SSH HMAC) Authentication and SSH 6668 [261] 2012 Defines algorithm names and ∙ Introduces a novel data integrity ∙ Refer to Table 10 and Table 11 for Hash and parameters for SHA-2 family hash algorithm for SSH, updating RFC 4253 MAC recommendations, respectively algorithms for data integrity ∙ Support: ∙ Refer to Table 34 for SSH verification Hash and MAC functions (HMAC, SHA-2-256, SHA-2-512) SSH 4217 [277] 2005 To outline a mechanism for ∙ Specifies the required extensions and ∙ Refer to Table 23 for Authentication FTPS implementing TLS-based security parameters, discusses policy considerations, ∙ Refer to Table 31 for TLS and authentication in FTP clients and promotes interoperability and servers ∙ Support: Authentication and TLS standards. The PKCS began as simple standards for using the groups that define and refine specifications, such as the Security RSA encryption and signature schemes but later expanded to Assertion Markup Language (SAML) and the OpenDocument cover all aspects of asymmetric cryptography, including key Format (ODF), through a transparent and consensus-driven pro- management, cryptographic message syntax, and cryptographic cess. OASIS provides a neutral and collaborative environment token interfaces. The PKCS series has been widely adopted and for stakeholders from diverse industries to collaborate on the has significantly impacted the development of public-key cryp- development of standards that address common challenges and tography. enable the seamless exchange of information and services across (vi) CA/Browser Forum different platforms and systems. Formed in 2005, the CA/Browser Forum38 comprises leading (viii) Post-Quantum Cryptography (PQC) Alliance and Coalition Certificate Authorities (CAs) and browser vendors, aiming to The emergence of the Post-Quantum Cryptography (PQC) Al- enhance the security and trustworthiness of SSL/TLS certificates liance40 and Coalition41 was prompted by the increasing threat used in web encryption. The forum establishes guidelines and best practices for CAs and browser vendors, developing base- posed by quantum computing. These organizations are dedi- line requirements and extended validation guidelines to ensure cated to standardizing and promoting cryptographic algorithms the integrity and authenticity of digital certificates. Its work and protocols resistant to quantum attacks. By collaborating to addresses evolving security threats and industry needs, promot- evaluate and endorse candidate algorithms, they contribute to ing the adoption of cryptographic best practices and standards- the development of future-proof cryptographic standards. Engag- compliant certificate issuance and validation processes. Through ing researchers, cryptographers, industry stakeholders, and stan- collaboration and consensus-building, the CA/Browser Forum dards bodies, they strive to advance the state of cryptography strives to maintain trust in the Public Key Infrastructure (PKI) and ensure long-term security against emerging threats. Their ecosystem and protect users from fraudulent activities and secu- work is crucial in preparing for the transition to quantum-safe rity vulnerabilities. cryptographic algorithms and mitigating risks to information (vii) Organization for the Advancement of Structured Information Stan- security and privacy. dards (OASIS) The landscape of Post-Quantum Cryptography (PQC) has wit- Founded in 1993 as a nonprofit consortium, OASIS39 develops nessed the emergence of two significant entities: the PQC Al- open standards for security, cloud computing, web services, liance and the PQC Coalition. Their shared purpose is to address and other areas to facilitate interoperability and promote in- dustry collaboration. It hosts technical committees and working 40 https://pqca.org 38 41 https://cabforum.org www.mitre.org/news-insights/news-release/post-quantum-cryptography- 39 https://www.oasis-open.org/org coalition-launches 42 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 36 IETF cryptographic standards/drafts for S/MIME. Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 8551 [279] 2019 S/MIME Version 4.0 Message ∙ Outlines how to add cryptographic ∙ Refer to Table 8, Table 12, and Table 13 for Specification signature and encryption services to MIME asymmetric cryptography data, including using the multipart/signed ∙ Refer to Table 6 for symmetric encryption media type for S/MIME signed messages ∙ Refer to Table 10 and Table 11 for Hash and ∙ Support: Asymmetric digital signature MAC recommendations, respectively (RSA, ECDSA), encryption (RSA) and key establishment (DH, ECDH), Symmetric encryption (AES-GCM-128/256, ChaCha20), Hash and MAC functions (MD5, SHA-1, SHA-2, Poly1305, HMAC) 2634 [280] 1999 Enhanced Security Services for ∙ Support: Asymmetric digital signature ∙ Refer to Table 12 for asymmetric digital signature S/MIME (RSA,DSS), Hash function (SHA-1) ∙ Refer to Table 10 for Hash recommendations 6210 [281] 2011 Hash Functions with Parameters ∙ Support: Asymmetric digital signature ∙ Refer to Table 12 for asymmetric digital signature S/MIME in the CMS and S/MIME (RSA), Hash and Mac functions (MD5, ∙ Refer to Table 10 and Table 11 for Hash and SHA-1, HMAC) MAC recommendations, respectively 3657 [282] 2004 Utilizing the Camellia ∙ Support: Symmetric encryption ∙ Refer to Table 6 for symmetric encryption encryption algorithm with CMS (Camellia-cbc-128/192/256, AES-128/192/256) 9216 [283] 2022 S/MIME Example Keys and ∙ Defining a small set of X.509v3 ∙ Refer to Table 8, Table 12, Table 13 for Certificates certificates and keys asymmetric cryptography ∙ Support: Asymmetric cryptography (RSA, ∙ Refer to Table 6 for symmetric encryption Ed25519, ECDH), symmetric encryption ∙ Refer to Table 10 and Table 11 for Hash and (AES-128), Hash and MAC functions MAC recommendations, respectively (SHA-256, HMAC), PKI (X.509) ∙ Refer to Table 24 for PKI recommendations 9219 [284] 2022 Signature Verification ∙ Specifies an extension to ‘‘The JSON ∙ Refer to Table 12 for asymmetric digital signature Meta Application Protocol (JMAP) for Mail’’ (RFC 8621) for returning the S/MIME signature verification status ∙ Support: Digital Signature 8823[285] 2021 Automatic Certificate ∙ The ACME process for issuing S/MIME ∙ Refer to Table 10 for Hash recommendations Management Environment certificates to email users requires specific ∙ Refer to Table 24 for PKI recommendations identifiers and challenges ∙ Support: Hash functions (SHA-256), PKI (X.509) 8550 [286] 2019 (S/MIME) Version 4.0 ∙ Support: Asymmetric Encryption and ∙ Refer to Table 8 and Table 12 for asymmetric Certificate Handling signatures (RSA, ECDSA, DSA), Hash cryptography functions (SHA-1, SHA-256), PKI (X.509, ∙ Refer to Table 10 for Hash recommendations PKIX) ∙ Refer to Table 24 for PKI recommendations (continued on next page) the threat posed by quantum computing to cryptographic sys- various technical projects, such as software development for new tems. Focusing on standardization and promotion of quantum- post-quantum algorithms and hosting initiatives like the Open resistant cryptographic algorithms, they collaborate to evalu- Quantum Safe project and the PQ Code Package Project, the ate and endorse candidate algorithms, contributing to the es- PQCA welcomes organizations and individuals to participate and tablishment of future-proof cryptographic standards. Their re- contribute to the advancement of post-quantum cryptography. sponsibility involves engaging various stakeholders to advance cryptography and ensure long-term security against emerging Appendix B. Standards for modes of operation threats. Comprised of members such as IBM Quantum, Microsoft, MITRE, As shown in Table B.37, each operational mode is analyzed for its PQShield, SandboxAQ, and the University of Waterloo, the PQC intended purpose (confidentiality, authentication, or both), standard- Coalition is dedicated to facilitating global adoption of PQC. ization body, and year of publication. The ‘Mode’ column confirms Their efforts include advancing standards relevant to PQC mi- support for all listed modes in their respective rows, while the ‘Algo- gration, creating educational materials, producing open-source, rithm’ column indicates support for corresponding modes listed in their production-quality code, and ensuring cryptographic agility. The respective rows. Furthermore, the ‘Note’ column provides specific infor- Coalition aims to streamline organizational migration to PQC mation about each standard. For detailed guidelines on cryptographic and provide comprehensive guidance for the community. recommendations, including the basic criteria we follow, please refer In February 2024, the Linux Foundation introduced the Post- to Section 3.2. Quantum Cryptography Alliance (PQCA) to drive the advance- ment and adoption of post-quantum cryptography. Supported B.1. Recommendations by founding members like Amazon Web Services (AWS), Cisco, Google, and IBM, the PQCA aims to secure sensitive data and Based on our recommendations presented in Table B.37, we con- communications in the post-quantum era. Their objective in- clude CBC, CFB, OFB, and CTR are post-quantum resistant if they come cludes providing production-ready libraries and packages and with a block cipher that is post-quantum safe such as AES-256, which enabling cryptographic agility across the ecosystem. Engaging in means the security of these modes depends on the security of the block 43 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table 36 (continued). Protocol RFC Year Purpose Note Recommendations Classical (till 2030 & beyond) PQ 8591 [287] 2019 SIP-Based Messaging with ∙ Support: Asymmetric encryption (RSA) ∙ Refer to Table 8 and Table 13 for asymmetric S/MIME and key agreement (ECDH-curve25519), cryptography Symmetric encryption (AES-128), Hash ∙ Refer to Table 6 for symmetric encryption function (SHA-256), PKI ∙ Refer to Table 10 for Hash recommendations ∙ Refer to Table 24 for PKI recommendations 8162 [288] 2017 Using Secure DNS to Associate ∙ Defines how to associate an S/MIME ∙ Refer to Table 10 for Hash recommendations Certificates with Domain Names user’s certificate with a domain name ∙ Refer to Table 31 for TLS for S/MIME using secure DNS ∙ Refer to Table 24 for PKI recommendations ∙ Support: Hash functions (SHA-256, SHA-512), TLS, PKI 7508 [289] 2015 Securing Header Fields with ∙ Explains how the S/MIME protocol can ∙ Refer to Table 31 for TLS S/MIME secure message headers, known as ‘Secure Headers’, defined in RFC 5322 ∙ Support: TLS 6318 [290] 2011 Suite B in S/MIME ∙ Support: Asymmetric signature ∙ Refer to Table 12 and Table 13 for asymmetric (ECDSA-P-256/384) and key agreement cryptography (ECDH-P-256/384), symmetric encryption ∙ Refer to Table 6 for symmetric encryption (AES-CBC-128/256), Hash function ∙ Refer to Table 10 for Hash recommendations (SHA-256/384) 6664 [291] 2012 S/MIME Capabilities for Public ∙ Support: Asymmetric signature ∙ Refer to Table 8, Table 12, and Table 13 for Key Definitions (RSASSA-PSS), key transport (RSAES-OAEP) asymmetric cryptography and key agreement (DH), Hash function ∙ Refer to Table 10 for Hash recommendations (MD5, SHA-1, SHA-256) 7107[292] 2014 Object Identifier Registry for the ∙ Support: Asymmetric cryptography (RSA, ∙ Refer to Table 8 for asymmetric cryptography S/MIME Mail Security Working ECC), symmetric encryption (AES), Hash ∙ Refer to Table 6 for symmetric encryption Group and Mac functions (MD5, HMAC) ∙ Refer to Table 10 and Table 11 for Hash and MAC recommendations, respectively 4262 [293] 2005 X.509 Certificate Extension for ∙ Support: PKI ∙ Refer to Table 24 for PKI recommendations S/MIME Capabilities 7281 [294] 2014 Authentication-Results Registration for S/MIME Signature Verification 3853 [295] 2004 S/MIME AES Requirement for ∙ Require the AES for S/MIME ∙ Refer to Table 12 for asymmetric signature the Session Initiation Protocol ∙ Support: Asymmetric signature (RSA), ∙ Refer to Table 6 for symmetric encryption (SIP) Symmetric encryption (AES), Hash function ∙ Refer to Table 10 for Hash recommendations (SHA-1), TLS ∙ Refer to Table 31 for TLS 3854 [296] 2004 Securing X.400 Content with ∙ Describes a protocol for adding ∙ Refer to Table 12 for asymmetric signature S/MIME cryptographic signature and encryption ∙ Refer to Table 6 for symmetric encryption services to X.400 content with S/MIME ∙ Refer to Table 10 for Hash recommendations ∙ Support: Asymmetric signature (RSA, DSA), Symmetric encryption (AES), HASH function (SHA-1) cipher. In addition, chosen block cipher should be PRF, and finally, (i) ChaCha20: ChaCha20 is a reliable and versatile stream cipher each mode should be IND-qCPA qPRF to be post-quantum resistant. algorithm widely used for secure encryption. It has gained pop- We also provide recommendations for each mode regarding classical ularity due to its simplicity, efficiency, and high level of security. and post-quantum cryptography. CBC, CFB, OFB, CTR, CMAC, CCM, The IETF has standardized ChaCha20, and various RFCs are GCM, KW, KWP, and TKW modes are considered post-quantum safe available in Table 7 to cover different aspects of it. under certain conditions. However, it is essential to note that using Based on the evaluation presented by Bathe et al. [40], ChaCha20- 3DES block cipher in any mode will be prohibited42 after 2023 (By 256, in its current configuration of 20 rounds, cannot be con- NIST [32]). In contrast, encrypting confidential information using ECB, sidered quantum-resistant to a degree comparable to AES-256. as indicated in the NIST National Vulnerability Database (NVD), is considered a severe security vulnerability. The analysis demonstrates that ChaCha20 falls short of meeting the quantum security criteria established by NIST, primarily due Appendix C. Stream ciphers to its lower complexity when subjected to Grover’s quantum search algorithm. Specifically, ChaCha20-256 would require sig- nificantly fewer quantum resources to break compared to AES- C.1. Stream ciphers standards 256. According to the authors’ estimations, ChaCha would need approximately 166 rounds (far beyond its standard implementa- We thoroughly examined the Stream Ciphers Standards and have tion) to attain a quantum security level equivalent to AES-256. summarized them in Table 7, detailing several key columns. For de- For clarity and ease of reference, this recommended configura- tailed guidelines on table columns and cryptographic recommenda- tions, please refer to Section 3.2. tion can be denoted as ChaCha166-256, indicating a version of ChaCha with a 256-bit key and 166 rounds. ChaCha20-256 can be considered tentatively quantum-safe and is recommended for 42 https://csrc.nist.gov/news/2023/nist-to-withdraw-sp-800-67-rev-2 non-critical applications [308]. 44 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table B.37 Standards for modes of operation. Mode Standards Year Purpose Algorithm Note Recommendations Classical PQ (till 2030 & beyond) (Available) ECB Consider disallowing ECB to encrypt NIST proposes limiting ECB approval to instances secrets. (March 2023) explicitly allowed by other NIST standards or guidance. CBC Security of CBC depends on the CBC-128/192/256 CBC-256 (IND-qCPA NIST SP security of AES (as a PRP) qPRF) 2010 Confidentiality Modes AES 800-38E [300] CFB Camellia-256 CFB-128/192/256 CFB-256 (IND-qCPA qPRF) OFB OFB-128/192/256 OFB-256 (IND-qCPA qPRF) CTR CTR-128/192/256 CTR-256 (IND-qCPA qPRF) XTS NIST SP 2010 The key size for XTS is twice the 128, 192, 256 bit None 800-38E [300] security strength FF1 NIST SP 2013 None None 800-38G [301] FF3 CMAC NIST SP 2005 Authentication mode CMAC is a variant of CBC-MAC, the 128, 256 bit CMAC-256 800-38B security properties of CMAC are similar (IND-qCPA qPRF) [302] to those of CBC CCM NIST SP 2004 It is considered to be secure when used 128, 192, 256 bit 800-38C with a secure block cipher, such as [303] AES. The size of the MAC also affects the security of CCM mode. A larger 256 bits MAC size provides greater security Combined modes for GCM NIST SP 2007 confidentiality and Suitable for files less than 64 GiB The 128, 192, 256 bit 800-38D authentication size of the MAC is fixed at 128 bits. [304] The recommended authentication tag IEEE 802.11 size for GCM mode is 128 bits, which [305] provides a high level of security against known attacks KW NIST SP To wrap a 256-bit key using AES Key 128, 192, 256 bit 2013 800-38G Wrap, you would need to use AES-256 KWP [301] for the encryption steps TKW TECB-I NIST SP 2012 Confidentiality Modes 3DES (ANSI 800-20∗ [306] X9.52) Disallowed after 2023 KW Combined modes for NIST SP confidentiality and TKW 800-38F [307] authentication (∗) Withdrawn on September 26, 2018. Table D.38 Public-key algorithms broken by Shor’s algorithm. Algorithm Function Security based on Specification RSA (PKCS#1, OAEP, PSS) Key Establishment, Digital Signatures Integer Factorization PKCS#1, FIPS 186 Diffie–Hellman (DH) Key Establishment Discrete Logarithm (finite field) NIST SP 800-56A/B/C, RFC 3526 Elliptic Curve Diffie–Hellman (ECDH) Key Establishment Discrete Logarithm (elliptic curve) NIST SP 800-56A, FIPS 186 MQV, ECMQV Key Establishment Discrete Logarithm (elliptic curve) NIST SP 800-56A X25519, X448 Key Establishment Discrete Logarithm (elliptic curve) RFC 7748 DSA Digital Signatures Discrete Logarithm (finite field) FIPS 186 ElGamal Encryption Discrete Logarithm (finite field) IEEE P1363 ECDSA Digital Signatures Discrete Logarithm (elliptic curve) FIPS 186-5 Ed25519, Ed448 (EdDSA) Digital Signatures Discrete Logarithm (elliptic curve) RFC 8032 BLS Signatures Digital Signatures Discrete Logarithm (pairing-friendly curves) draft-irtf-cfrg-bls-signature ECIES, EC-ElGamal Encryption/Key Encapsulation Discrete Logarithm (elliptic curve) ISO/IEC 18033-2 (ii) RC4: The RC4 algorithm is a popular symmetric stream cipher longer considered secure for most applications due to vulnera- used to encrypt data in many cryptographic systems and pro- bilities in its design that have been discovered over time [309]. tocols. However, it is important to be aware that RC4 is no Table 7 provides details on the standardization of RC4 by 45 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 Table D.39 Symmetric algorithms affected by Grover’s algorithm. Category Examples Mitigation/Recommendation Block Ciphers AES-128, SM4, SEED Use AES-256 to restore ≥128-bit post-quantum security Stream Ciphers ChaCha20, Salsa20 Use AES-256 in CTR, OFB or CFB mode, with a recommendation to use CTR mode Hash Functions SHA-256, SHA-384, SHA-512, SHA3-256, Use SHA-512 or SHA3-512 to maintain (collision resistance) SHA3-512, SM3 ≥128-bit post-quantum collision resistance Hash Functions SHA-256, SHA-512, SHA3-family SHA-256 provides 128-bit PQ security; (preimage resistance) SHA-512 provides 256-bit PQ security Message Authentication HMAC-SHA256, HMAC-SHA512, Poly1305 Use HMAC-SHA512 or 256-bit keys to maintain ≥128-bit post-quantum security Authenticated AES-128-GCM, AES-256-GCM, Use AES-256-GCM or ChaCha20–Poly1305 Encryption ChaCha20–Poly1305 with 256-bit keys; 128-bit tags remain secure Table D.40 Recommended post-quantum replacements for vulnerable classical algorithms. Replace this With (PQC algorithm) Notes/Remarks RSA, DH, ECDH, MQV, X25519 ML-KEM-768/1024 (Kyber) NIST FIPS 203; lattice-based KEM; hybrid mode (e.g., X25519+ML-KEM-768) recommended during transition RSA, ECDSA, EdDSA, DSA ML-DSA-65/87 (Dilithium), NIST FIPS 204, 205; ML-DSA balances SLH-DSA-128/256 (SPHINCS+) size/speed; SLH-DSA is stateless hash-based; FN-DSA (Falcon) under consideration IETF, NIST, IEEE, and ISO. However, it is no longer recom- AES-CTR is a stream cipher mode that is easy to implement, mended by any of these organizations. For encryption purposes, parallelize, and pipelined. It also supports key stream precompu- it is recommended to use more secure alternatives, such as the tation and has a smaller implementation size compared to other AES. AES modes. (iii) SNOW 2.0: The Snow stream cipher was first created for cellular communication standards like 3G and 4G. Its purpose is to Appendix D. Algorithms vulnerable to quantum attacks offer efficient and secure encryption for wireless communication. ISO/IEC 18033 includes SNOW 2.0 stream cipher algorithms Shor’s algorithm efficiently solves two mathematical problems that standards and recommendations [310]. are fundamental to modern public-key cryptography: integer factor- (iv) Trivium: Trivium is a stream cipher method that is able to ization and the discrete logarithm problem (in both finite fields and balance speed and hardware usage, while still being efficient elliptic curve groups). As a result, any cryptographic scheme that when implemented in software. Trivium is a hardware-efficient depends on these computational hardness assumptions will become cipher that is easy to use and performs well. However, it has completely insecure once large-scale, fault-tolerant quantum computers been analyzed and found to have weaknesses. To ensure secure are realized. Table D.38 summarizes the major affected algorithms and communication and data protection, it is recommended to use their underlying security foundations. other modern and thoroughly tested stream ciphers, such as Once a sufficiently powerful quantum computer becomes available, those found in the eSTREAM portfolio or the AES [311]. As a the above schemes will provide no security guarantees whatsoever. lightweight stream cipher, ISO has some standardization and Past ciphertexts and signatures generated using these algorithms can recommendations for it in ISO/IEC 29192-3:2012 [48]. be retrospectively compromised under a harvest-now, decrypt-later (v) Enocoro: Enocoro is a family of pseudorandom number genera- (HNDL) threat model, in which adversaries collect encrypted data today tors (stream ciphers). It comprises two algorithms, Enocoro-80 to decrypt once quantum capabilities mature. Organizations managing and Enocoro-128v1.1, which have key lengths of 80 bits and 128 long-lived sensitive data, such as medical records, financial transac- bits, respectively [312]. ISO/IEC 29192-3:2012 [48] provides tions, or classified government communications, should prioritize the standardization and recommendations for Enocoro. immediate transition away from these algorithms. (vi) Grain: There are two types of Grain ciphers: an 80-bit and a While Shor’s algorithm completely compromises public-key cryp- 128-bit variant labeled as Grain and Grain-128, respectively. tosystems, Grover’s algorithm provides a quadratic speedup for exhaus- These designs utilize two shift registers and a nonlinear output tive key search, effectively reducing the security strength of symmetric function, and are intended for hardware environments with primitives by up to half in the worst case. For example, a 128-bit limited gate count, power consumption, and memory. Addi- key provides at most 64-bit quantum security against Grover’s attack, tionally, expanding the hardware can make the ciphers faster, whereas a 256-bit key retains up to 128-bit post-quantum security. but this comes at a cost [313]. Grain-128AEAD is a highly Table D.39 summarizes the effects on symmetric algorithms and the compatible choice for the Internet of Things (IoT) and em- corresponding recommended countermeasures. bedded systems due to its significant advantages. Its previous versions have also proven to be relevant in industrial appli- D.1. PQC replacements cations. NIST and ISO provide recommendations for handling Grain in their respective publications, NISTIR 8369 and ISO/IEC To mitigate quantum threats, NIST has standardized PQC algorithms 29167-13:2015 [50]. specifically designed to resist both classical and quantum attacks. These (vii) AES-CTR: AES-CTR is a stream cipher that utilizes the AES block algorithms are based on mathematical problems believed to be hard for cipher. It XORs the key stream generated by AES encryption of quantum computers, including lattice problems, hash-based signatures sequential counter block values to encrypt and decrypt data. and code-based cryptography. During the transition period, hybrid 46 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 modes that combine classical and PQC algorithms are strongly rec- [22] UK National Cyber Security Centre, Post-quantum cryptography migration ommended to ensure security against both current and future threats. timelines and guidance, 2024, URL https://www.ncsc.gov.uk/guidance/pqc- migration-timelines. Table D.40 provides a practical migration roadmap from vulnerable [23] Z. Huang, S. Sun, Synthesizing quantum circuits of AES with lower t-depth classical schemes to their quantum-resistant counterparts. and less qubits, in: International Conference on the Theory and Application of Cryptology and Information Security, Springer, 2022, pp. 614–644. Data availability [24] M. Grassl, B. Langenberg, M. Roetteler, R. Steinwandt, Applying Grover’s algorithm to AES: quantum resource estimates, in: Post-Quantum Cryptography, Springer, 2016, pp. 29–43. No data was used for the research described in the article. [25] NIST, Post-Quantum Cryptography (PQC): Security (Evaluation Criteria), 2021, https://csrc.nist.gov/projects/post-quantum-cryptography/post- quantum-cryptography-standardization/evaluation-criteria/security-(evaluation- References criteria)#FN5. (Online; Accessed 10 February 2022). [26] T.M. Fernandez-Carames, P. Fraga-Lamas, Towards post-quantum blockchain: [1] H.-Y. Kwon, I. Bajuna, M.-K. Lee, Compact hybrid signature for secure transition A review on blockchain cryptography resistant to quantum computing attacks, to post-quantum era, IEEE Access (2024). IEEE Access 8 (2020) 21091–21116. [2] P.W. Shor, Polynomial-time algorithms for prime factorization and discrete [27] T.M. Fernández-Caramés, From pre-quantum to post-quantum IoT security: A logarithms on a quantum computer, SIAM Rev. 41 (2) (1999) 303–332. survey on quantum-resistant cryptosystems for the Internet of Things, IEEE [3] I. Kong, M. Janssen, N. Bharosa, Realizing quantum-safe information sharing: Internet Things J. 7 (7) (2019) 6457–6480. Implementation and adoption challenges and policy recommendations for [28] M. Amy, M. Grassl, B. Langenberg, M. Roetteler, Estimating the cost of generic quantum-safe transitions, Gov. Inf. Q. 41 (1) (2024) 101884, http://dx.doi. quantum pre-image attacks on SHA-2 and SHA-3, in: Advances in Cryptology – org/10.1016/j.giq.2023.101884, URL https://www.sciencedirect.com/science/ ASIACRYPT 2016, in: Lecture Notes in Computer Science, Springer, 2016, pp. article/pii/S0740624X23000849. 317–337, http://dx.doi.org/10.1007/978-3-662-53890-6_12. [4] NIST, Post-quantum cryptography standardization, 2024, NIST, Available: https: [29] NIST, Advanced Encryption Standard (AES), NIST Special Publication, 2001, //csrc.nist.gov/pqc-standardization. URL https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197-upd1.pdf. [5] NIST, Post-quantum cryptography round 4 submissions, 2024, NIST, Available: [30] ISO Central Secretary, Information Technology-Security Techniques-Encryption https://csrc.nist.gov/projects/post-quantum-cryptography/round-4-submissions. Algorithms-Part 3: Block Ciphers, Standard ISO/IEC 18033-3:2010, International [6] C. Boutin, NIST announces first four quantum-resistant cryptographic Organization for Standardization, 2010, URL https://www.iso.org/standard/ algorithms, Natl. Inst. Stand. Technol. (2022). 54531.html. [7] M. Mosca, Cybersecurity in an era with quantum computers: Will we be [31] ISO Central Secretary, Banking and Related Financial Services-Key Wrap ready? IEEE Secur. Priv. 16 (5) (2018) 38–41. Using AES, Standard ISO/IEC 20038:2017, International Organization for [8] Post-quantum cryptography, 2017, https://csrc.nist.gov/projects/post-quantum- Standardization, 2017, URL https://www.iso.org/standard/64400.html. cryptography. [32] N.M. Elaine Barker, Recommendation for the Triple Data Encryption Algorithm [9] National Institute of Standards and Technology (NIST), Mappings of Migration (TDEA) block Cipher, NIST Spec. Publ. 800 (2012) 67. to PQC Project Capabilities to Risk Framework Documents, Tech. Rep. NIST [33] ISO Central Secretary, Information Technology-Security Techniques-Security CSWP 48 (Initial Public Draft), NIST, 2025, URL https://nvlpubs.nist.gov/ Requirements for Cryptographic Modules, Standard ISO/IEC 19790:2012, In- nistpubs/CSWP/NIST.CSWP.48.ipd.pdf. ternational Organization for Standardization, 2012, URL https://www.iso.org/ [10] Executive Office of the President, Strengthening and promoting innovation standard/52906.html. in the Nation’s Cybersecurity, 2025, URL https://www.federalregister.gov/ [34] M. Matsui, S. Moriai, J. Nakajima, A Description of the Camellia Encryption documents/2025/01/17/2025-01470/strengthening-and-promoting-innovation- Algorithm, Request for Comments RFC 3713, RFC Editor, 2004, http://dx.doi. in-the-nations-cybersecurity, Published Jan 17, 2025, Executive Order 14144, org/10.17487/RFC3713, URL https://www.rfc-editor.org/info/rfc3713. Federal Register 90(12):6755–6771. [35] A. Kato, M. Kanda, S. Kanno, Modes of Operation for Camellia for Use with [11] E. Barker, Recommendation for Key Management: Part 1 (Revised)(May 2020 IPsec, RFC 5529 Request for Comments, RFC Editor, 2009, http://dx.doi.org/ edition) – General, vol. 800, NIST Special Publication, 2020, URL https://csrc. 10.17487/RFC5529, URL https://www.rfc-editor.org/info/rfc5529. nist.gov/publications/detail/sp/800-57-part-1/rev-5/final. [36] A. Kato, S. Moriai, M. Kanda, The Camellia Cipher Algorithm and Its Use With [12] National Institute of Standards and Technology, Post-quantum cryptography IPsec, RFC 4312 Request for Comments, RFC Editor, 2005, http://dx.doi.org/ security (evaluation criteria), 2017, https://csrc.nist.gov/projects/post- 10.17487/RFC4312, URL https://www.rfc-editor.org/info/rfc4312. quantum-cryptography/post-quantum-cryptography-standardization/evaluation- [37] N. Mouha, M. Dworkin, Report on the Block Cipher Modes of Operation in criteria/security-(evaluation-criteria). the NIST SP 800-38 Series, Tech. Rep., National Institute of Standards and [13] NIST, FIPS 203: Cryptographic Algorithms and Key Sizes for Post-Quantum Technology, 2023. Cryptography, 2024, URL https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS. 203.pdf, (Online; Accessed 30 October 2025). [38] P. Rogaway, Evaluation of some blockcipher modes of operation, 630, 2011, Cryptography Research and Evaluation Committees (CRYPTREC) for the [14] NIST, FIPS 204: CRYSTALS-Dilithium, 2024, URL https://nvlpubs.nist.gov/ Government of Japan. nistpubs/FIPS/NIST.FIPS.204.pdf, (Online; Accessed 30 October 2025). [15] NIST, FIPS 205: Falcon, 2024, URL https://nvlpubs.nist.gov/nistpubs/FIPS/ [39] M.V. Anand, E.E. Targhi, G.N. Tabia, D. Unruh, Post-quantum security of NIST.FIPS.205.pdf. (Online; Accessed 30 October 2025). the CBC, CFB, OFB, CTR, and XTS modes of operation, in: Post-Quantum [16] evolutionQ Inc. and Global Risk Institute, Quantum Threat Timeline Report Cryptography: 7th International Workshop, PQCrypto 2016, Fukuoka, Japan, 2024, Tech. Rep., evolutionQ Inc. under license by Global Risk Institute, February 24-26, 2016, Proceedings 7, Springer, 2016, pp. 44–63. Toronto, Ontario, Canada, 2024, URL https://www.globalriskinstitute.org/ [40] B. Bathe, R. Anand, S. Dutta, Evaluation of Grover’s algorithm toward quantum publication/2024-quantum-threat-timeline-report/. cryptanalysis on ChaCha: B. Bathe et al., Quantum Inf. Process. 20 (12) (2021) [17] Australian Signals Directorate, Cryptographic roadmap – Preparing for post- 394. quantum cryptography, 2025, Version 1.0, URL https://www.cyber.gov.au/ [41] Y. Nir, A. Langley, ChaCha20 and Poly1305 for IETF Protocols, RFC 8439 Re- resources-business-and-government/essential-cybersecurity/ism/cybersecurity- quest for Comments, RFC Editor, 2018, http://dx.doi.org/10.17487/RFC8439, guidelines/guidelines-cryptography. URL https://www.rfc-editor.org/info/rfc8439. [18] National Security Agency, Commercial National Security Algorithm (CNSA) [42] R. Housley, Using ChaCha20-Poly1305 Authenticated Encryption in the Crypto- suite 2.0 and quantum-resistant algorithm transition strategy, 2022, Tech. graphic Message Syntax (CMS), RFC 8103 Request for Comments, RFC Editor, guidance memo, URL https://media.defense.gov/2022/Sep/07/2003075988/- 2017, http://dx.doi.org/10.17487/RFC8103, URL https://www.rfc-editor.org/ 1/-1/0/CSA_CNSA-2.0_FACT_SHEET.PDF. info/rfc8103. [19] EU NIS Cooperation Group, Joint statement on the transition to quantum- [43] A. Langley, W.-T. Chang, N. Mavrogiannopoulos, J. Strombergson, S. Josefsson, resistant cryptography, 2024, URL https://www.bsi.bund.de/SharedDocs/ ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS), RFC Downloads/EN/BSI/Crypto/PQC-joint-statement.pdf?__blob=publicationFile&v= 7905 Request for Comments, RFC Editor, 2016, http://dx.doi.org/10.17487/ 3. RFC7905, URL https://www.rfc-editor.org/info/rfc7905. [20] D. Moody, et al., Status Report on the Second Round of the NIST Post-Quantum [44] Y. Nir, ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Cryptography Standardization Process, Nist interagency/internal report (ir) Protocol (IKE) and IPsec, RFC 7634 Request for Comments, RFC Editor, 8547, National Institute of Standards and Technology (NIST), 2020, http: 2015, http://dx.doi.org/10.17487/RFC7634, URL https://www.rfc-editor.org/ //dx.doi.org/10.6028/NIST.IR.8547. info/rfc7634. [21] Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI), ANSSI [45] J. Strombergson, S. Josefsson, Test Vectors for the Stream Cipher RC4, RFC views on the post-quantum cryptography transition: 2023 follow-up, 2023, URL 6229 Request for Comments, RFC Editor, 2011, http://dx.doi.org/10.17487/ https://www.ssi.gouv.fr/uploads/2023/11/anssi-pqc-transition-2023.pdf. RFC6229, URL https://www.rfc-editor.org/info/rfc6229. 47 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 [46] ISO Central Secretary, Information Technology-Security Techniques-Encryption [68] ISO Central Secretary, Information Technology-Security Techniques-Hash- Algorithms-Part 4: Stream Ciphers, Standard ISO/IEC 18033-4:2011, Inter- Functions-Part 4: Hash-Functions Using Modular Arithmetic, Standard ISO/IEC national Organization for Standardization, 2011, URL https://www.iso.org/ 10118-4:1998, International Organization for Standardization, 1998, URL https: standard/54532.html. //www.iso.org/standard/25429.html. [47] IEEE standard for information technology-telecommunications and informa- [69] ISO Central Secretary, IT Security Techniques-Hash-Functions-Part 3: Dedicated tion exchange between systems-local and metropolitan area networks-specific Hash-Functions, Standard ISO/IEC 10118-3:2018, International Organization for requirements-part 11: Wireless LAN medium access control (MAC) and phys- Standardization, 2018, URL https://www.iso.org/standard/67116.html. ical layer (PHY) specifications: Amendment 6: Medium access control (MAC) [70] E.B. Barker, A.L. Roginsky, SP 800-131a. Transitions: Recommendation for security enhancements, 2004, pp. 1–190, http://dx.doi.org/10.1109/IEEESTD. Transitioning the Use of Cryptographic Algorithms and Key Lengths, National 2004.94585, IEEE Std 802.11i-2004. Institute of Standards & Technology, 2011. [48] ISO Central Secretary, Information Technology-Security Techniques-Lightweight [71] ISO Central Secretary, Information Security-Cryptographic Techniques Based Cryptography-Part 3: Stream Ciphers, Standard ISO/IEC 29192-3:2012, Inter- on Elliptic Curves-Part 5: Elliptic Curve Generation, Standard ISO/IEC 15946- national Organization for Standardization, 2012, URL https://www.iso.org/ 5:2017, International Organization for Standardization, 2017, URL https:// standard/56426.html. www.iso.org/standard/80241.html. [49] K. McKay, L. Bassham, M. Sönmez Turan, N. Mouha, Report on Lightweight [72] ISO Central Secretary, Information Technology-Security Techniques-Security Cryptography, Tech. Rep., National Institute of Standards and Technology, Requirements for Cryptographic Modules, Standard ISO/IEC 19790:2012, In- 2017, URL https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8114.pdf. ternational Organization for Standardization, 2012, URL https://www.iso.org/ [50] ISO Central Secretary, Information Technology-Automatic Identification and standard/52906.html. Data Capture Techniques-Part 13: Crypto Suite Grain-128A Security Services for [73] ISO Central Secretary, Identification Cards-Integrated Circuit Card Programming Air Interface Communications, Standard ISO/IEC 29167-13:2015, International Interfaces-Part 3: Application Interface, Standard ISO/IEC 24727-3:2008, In- Organization for Standardization, 2015, URL https://www.iso.org/standard/ ternational Organization for Standardization, 2008, URL https://www.iso.org/ 60682.html. standard/43809.html. [51] M.S. Turan, K. McKay, D. Chang, C. Calik, L. Bassham, J. Kang, J. Kelsey, [74] ISO Central Secretary, Standard ISO/IEC 29192-6:2019, International Organi- et al., Status report on the second round of the NIST lightweight cryptography zation for Standardization, 2019, URL https://https://www.iso.org/standard/ standardization process, Natl. Inst. Stand. Technol. Intern. Rep. 8369 (10.6028) 71116.html. (2021). [75] ISO Central Secretary, Information Security-Message Authentication Codes [52] M. Boesgaard, M. Vesterager, E. Zenner, A Description of the Rabbit Stream (Macs)-Part 2: Mechanisms Using a Dedicated Hash-Function, Standard ISO/IEC Cipher Algorithm, RFC 4503 Request for Comments, RFC Editor, 2006, http:// 9797-2:2021, International Organization for Standardization, 2021, URL https: dx.doi.org/10.17487/RFC4503, URL https://www.rfc-editor.org/info/rfc4503. //www.iso.org/standard/75296.html. [53] R. Housley, Using Advanced Encryption Standard (AES) Counter Mode With [76] ISO Central Secretary, Information Technology-Security Techniques-Message IPsec Encapsulating Security Payload (ESP), RFC 3686 Request for Comments, Authentication Codes (Macs)-Part 1: Mechanisms Using a Block Cipher, Stan- RFC Editor, 2004, http://dx.doi.org/10.17487/RFC3686, URL https://www.rfc- dard ISO/IEC 9797-1:2011, International Organization for Standardization, editor.org/info/rfc3686. 2011, URL https://www.iso.org/standard/50375.html. [54] K. Moriarty, B. Kaliski, J. Jonsson, A. Rusch, PKCS #1: RSA Cryptography Spec- [77] K.R. Glenn, P.-C. Cheng, Test Cases for HMAC-MD5 and HMAC-SHA-1, RFC ifications Version 2.2, RFC Editor, 2016, http://dx.doi.org/10.17487/RFC8017, 2202 Request for Comments, RFC Editor, 1997, http://dx.doi.org/10.17487/ URL https://www.rfc-editor.org/info/rfc8017. RFC2202, URL https://www.rfc-editor.org/info/rfc2202. [78] D.S.E. Deering, J. McCann, J. Mogul, Path MTU Discovery for IP Version 6, RFC [55] ISO Central Secretary, IT Security Techniques-Digital Signatures with Appendix- 1981 Request for Comments, RFC Editor, 1996, http://dx.doi.org/10.17487/ Part 3: Discrete Logarithm Based Mechanisms, Standard ISO/IEC 14888-3:2018, RFC1981, URL https://www.rfc-editor.org/info/rfc1981. International Organization for Standardization, 2018, URL https://www.iso.org/ [79] S. Turner, Updated Security Considerations for the MD5 Message-Digest and standard/76382.html. the HMAC-MD5 Algorithms, RFC 6151 Request for Comments, RFC Editor, [56] NIST, PQC standardization process: Announcing four candidates to be standard- 2011, http://dx.doi.org/10.17487/RFC6151, URL https://www.rfc-editor.org/ ized, plus fourth round candidates, 2022, https://csrc.nist.gov/News/2022/pqc- info/rfc6151. candidates-to-be-standardized-and-round-4. [80] J. Kelsey, S.-j. Chang, R. Perlner, Nist Special Publication 800-185: Sha-3 [57] E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.3, Tech. Derived Functions: Cshake, KMAC, Tuplehash and Parallelhash, Tech. Rep, Rep., 2018. National Institute of Standards and Technology, Gaithersburg, MD, 2016. [58] S. Sadeghi, V. Chouhan, M. Aldarwbi, A. Ghorbani, A. Chow, R. Burko, Securing [81] ANSIx9.62 public key cryptography for the financial services industry: the financial sector applications in the quantum era: A comprehensive evaluation of elliptic curve digital signature algorithm (ECDSA), 2005, ANSI. NIST’s recommended algorithms through use-case analysis, Expert Syst. Appl. [82] IEEE standard specifications for public-key cryptography-amendment 1: Addi- (2025) 128243. tional techniques, 2004, pp. 1–167, http://dx.doi.org/10.1109/IEEESTD.2004. [59] D. Adrian, B. Beck, D. Benjamin, D. O’Brien, Advancing our amazing bet 94612, IEEE Std 1363a-2004 (Amendment To IEEE Std 1363-2000). on asymmetric cryptography, 2024, Reports ∼4% median handshake latency [83] NIST, Digital Signature Standard (DSS), NIST Special Publication, 2023, URL increase on desktop due to ClientHello split, https://blog.chromium.org/2024/ https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf. 05/advancing-our-amazing-bet-on-asymmetric.html. [84] ISO Central Secretary, Information Technology-Security Techniques-Digital Sig- [60] P. Kampanakis, W. Childs-Klein, The impact of data-heavy, post-quantum TLS nature Schemes Giving Message Recovery-Part 3: discrete Logarithm Based 1.3 on the time-to-last-byte of real-world connections, in: MADWeb 2024 Mechanisms, Standard ISO/IEC 9796-3:2006, International Organization for (Co-Located with NDSS), 2024, URL https://csrc.nist.gov/csrc/media/Events/ Standardization, 2006, URL https://www.iso.org/standard/42228.html. 2024/fifth-pqc-standardization-conference/documents/papers/the-impact-of- [85] ISO Central Secretary, Information Technology-Security Techniques-Digital data-heavy-post-quantum.pdf, TTLB increase < 5% on stable high-bw; < 15% Signatures with Appendix-Part 1: General, Standard ISO/IEC 14888-1:2008, In- on low-bw with 50 KiB+ payload. ternational Organization for Standardization, and International Electrotechnical [61] M. Sosnowski, et al., The performance of post-quantum TLS 1.3, in: ACM CCS, Commission, 2008, URL https://www.iso.org/standard/44226.html. 2023, URL https://dl.acm.org/doi/10.1145/3624354.3630585. [86] T. Polk, S. Turner, R. Housley, D.R.L. Brown, K. Yiu, Updates for RSAES- [62] D.E.E. 3rd, P. Jones, US Secure Hash Algorithm 1 (SHA1), RFC 3174 Request OAEP and RSASSA-PSS Algorithm Parameters, RFC 5756 Request for Comments, for Comments, RFC Editor, 2001, http://dx.doi.org/10.17487/RFC3174, URL RFC Editor, 2010, http://dx.doi.org/10.17487/RFC5756, URL https://www.rfc- https://www.rfc-editor.org/info/rfc3174. editor.org/info/rfc5756. [63] T. Hansen, D.E.E. 3rd, US Secure Hash Algorithms (SHA and SHA-based HMAC [87] E. Barker, A. Roginsky, NIST special publication 800–131a revision 2: and HKDF), RFC 6234 Request for Comments, RFC Editor, 2011, http://dx.doi. Transitioning the use of cryptographic algorithms and key lengths, 2019. org/10.17487/RFC6234, URL https://www.rfc-editor.org/info/rfc6234. [88] ANSI X9.30.1 public key cryptography for the financial services industry: Part [64] NIST, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Func- 1: the Digital Signature Algorithm (DSA), 1997, ANSI. tions, NIST Special Publication, 2015, URL https://nvlpubs.nist.gov/nistpubs/ [89] IEEE standard specifications for public-key cryptography, 2000, pp. 1–228, fips/nist.fips.180-4.pdf. http://dx.doi.org/10.1109/IEEESTD.2000.92292, IEEE Std 1363-2000. [65] NIST, Secure Hash Standard (SHS), NIST Special Publication, 2015, URL https: [90] ISO Central Secretary, Information Technology, Standard ISO/IEC JTC1, Inter- //nvlpubs.nist.gov/nistpubs/fips/nist.fips.202.pdf. national Organization for Standardization, URL https://www.iec.ch/dyn/www/ [66] M.-J.O. Saarinen, J.-P. Aumasson, The BLAKE2 Cryptographic Hash and Mes- f?p=103:7:411214269599852::::FSP_ORG_ID,FSP_LANG_ID:3387,25. sage Authentication Code (MAC), RFC 7693 Request for Comments, RFC Editor, [91] NIST, Digital signature standard (DSS), 2013, NIST Special Publication, URL 2015, http://dx.doi.org/10.17487/RFC7693, URL https://www.rfc-editor.org/ https://csrc.nist.gov/pubs/fips/186-4/final. info/rfc7693. [92] S. Blake, ANSIx9. 63 overview: Key agreement and key transport using elliptic [67] S. Shen, X. Lee, R.H. Tse, W.W. Kit, P. Yang, The SM3 Cryptographic curve cryptography, 2013, ANSI. Hash Function, Internet-Draft draft-sca-cfrg-sm3-01, Internet Engineering Task [93] ANSIx9.42 public key cryptography for the financial services industry: Force, 2018, URL https://datatracker.ietf.org/doc/draft-sca-cfrg-sm3/01/, Work Agreement of symmetric keys using discrete logarithm cryptography, 2013, in Progress. ANSI. 48 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 [94] E. Rescorla, Diffie-Hellman Key Agreement Method, RFC 2631 Request for [118] B. Mennink, Elephant v2, 2021. Comments, RFC Editor, 1999, http://dx.doi.org/10.17487/RFC2631, URL https: [119] S. Banik, S.K. Pandey, T. Peyrin, Y. Sasaki, S.M. Sim, Y. Todo, GIFT: A small //www.rfc-editor.org/info/rfc2631. present: Towards reaching the limit of lightweight encryption, in: Cryptographic [95] E. Barker, L. Chen, S. Keller, A. Roginsky, A. Vassilev, R. Davis, Recom- Hardware and Embedded Systems–CHES 2017: 19th International Conference, mendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Taipei, Taiwan, September 25-28, 2017, Proceedings, Springer, 2017, pp. Cryptography, Tech. Rep., National Institute of Standards and Technology, 321–345. 2018. [120] M. Hell, T. Johansson, A. Maximov, W. Meier, J. Sönnerup, H. Yoshida, Grain- [96] A. Langley, M. Hamburg, S. Turner, Elliptic Curves for Security, RFC 7748 Re- 128aeadv2-a lightweight AEAD stream cipher, 2021, Submission to NIST LWC quest for Comments, RFC Editor, 2016, http://dx.doi.org/10.17487/RFC7748, Project. URL https://www.rfc-editor.org/info/rfc7748. [121] C. Dobraunig, M. Eichlseder, S. Mangard, F. Mendel, B. Mennink, R. Primas, T. [97] J. Herzog, R. Khazan, Use of Static-Static Elliptic Curve Diffie-Hellman Key Unterluggauer, ISAP v2. 0, 2020. Agreement in Cryptographic Message Syntax, RFC 6278 Request for Comments, [122] J. Guo, T. Peyrin, A. Poschmann, The PHOTON family of lightweight hash RFC Editor, 2011, http://dx.doi.org/10.17487/RFC6278, URL https://www.rfc- functions, in: Advances in Cryptology–CRYPTO 2011: 31st Annual Cryptology editor.org/info/rfc6278. Conference, Santa Barbara, CA, USA, August 14-18, 2011. Proceedings 31, [98] ISO/IEC 18033-1:2021 information security-encryption algorithms-part 1: Springer, 2011, pp. 222–239. General, 2021, ISO. [123] C. Beierle, J. Jean, S. Kölbl, G. Leander, A. Moradi, T. Peyrin, Y. Sasaki, P. [99] IEEE standard specifications for public-key cryptography-amendment 1: Addi- Sasdrich, S.M. Sim, The SKINNY family of block ciphers and its low-latency tional techniques, 2004, pp. 1–167, http://dx.doi.org/10.1109/IEEESTD.2004. variant MANTIS, in: Advances in Cryptology–CRYPTO 2016: 36th Annual 94612, IEEE Std 1363a-2004 (Amendment To IEEE Std 1363-2000). International Cryptology Conference, Santa Barbara, CA, USA, August 14-18, [100] E. Barker, L. Chen, A. Roginsky, A. Vassilev, R. Davis, S. Simon, SP 800- 2016, Proceedings, Part II 36, Springer, 2016, pp. 123–153. 56B Rev. 1: Recommendation for Pair-Wise Key-Establishment Using Integer [124] C. Beierle, A. Biryukov, L.C. dos Santos, J. Großschädl, L. Perrin, A. Udovenko, Factorization Cryptography, Tech. Rep., National Institute of Standards and V. Velichkov, Q. Wang, A. Biryukov, Schwaemm and esch: lightweight authen- Technology, 2018. ticated encryption and hashing using the sparkle permutation family, 2, 2019, [101] E. Barker, A. Roginsky, SP 800-131A Rev.2 Transitioning the Use of Crypto- NIST Round. graphic Algorithms and Key Lengths, Tech. Rep., National Institute of Standards [125] H. Wu, T. Huang, JAMBU lightweight authenticated encryption mode and and Technology, 2018. AES-JAMBU, 2014, CAESAR competition proposal. [102] F. NIST, 171: Key Management Using ANSI X9. 17, Apr. 27, 1992, Retrieved [126] J. Daemen, S. Hoffert, M. Peeters, G.V. Assche, R.V. Keer, Xoodyak, a from Internet: http://securityv.isu.edu/isl/fips171.html, pp. 1–26. lightweight cryptographic scheme, 2020. [103] ANSI X9.24-1-2017 retail financial services symmetric key management Part 1: [127] K. Jang, G. Song, H. Kim, H. Kwon, H. Kim, H. Seo, Efficient implementation Using symmetric techniques (contains corrigendum), 2017, ANSI. of PRESENT and GIFT on quantum computers, Appl. Sci. 11 (11) (2021) 4776, [104] E.B. Barker, L. Chen, A.R. Regenscheid, M.E. Smid, Sp 800-56b. recommen- http://dx.doi.org/10.3390/app11114776. dation for pair-wise key establishment schemes using integer factorization [128] R. Anand, A. Maitra, S. Maitra, C.S. Mukherjee, S. Mukhopadhyay, Quantum cryptography, 2009, National Institute of Standards & Technology. resource estimation for FSR based symmetric ciphers and related Grover’s [105] E.B. Barker, A.L. Roginsky, Sp 800-131a. transitions: Recommendation for attacks, in: Progress in Cryptology – INDOCRYPT 2021, Lecture Notes in transitioning the use of cryptographic algorithms and key lengths, 2011, Computer Science, vol. 13143, Springer, Cham, 2021, pp. 179–198, http://dx. National Institute of Standards & Technology. doi.org/10.1007/978-3-030-92518-5_9. [106] W. Castryck, T. Decru, An efficient key recovery attack on SIDH, in: Annual [129] C. Dobraunig, M. Eichlseder, F. Mendel, M. Schläffer, Ascon v1.2: Lightweight International Conference on the Theory and Applications of Cryptographic authenticated encryption and hashing, J. Cryptology 34 (3) (2021) 33, http: Techniques, Springer, 2023, pp. 423–447. //dx.doi.org/10.1007/s00145-021-09398-9. [107] M. Ounsworth, A. Wussler, S. Kousidis, Combiner Function for Hybrid Key [130] A. Jagielski, K. Kanciak, Grover on SPARKLE: Quantum resource estimation for Encapsulation Mechanisms (Hybrid KEMs), Internet-Draft draft-ounsworth- a NIST LWC call finalist, Quantum Inf. Comput. 22 (13–14) (2022) 1132–1143, cfrg-kem-combiners-04, Internet Engineering Task Force, 2023, URL https: http://dx.doi.org/10.26421/QIC22.13-14-3. //datatracker.ietf.org/doc/draft-ounsworth-cfrg-kem-combiners/04/, Work in [131] National Institute of Standards and Technology, Status Report on the Fi- Progress. nal Round of the NIST Lightweight Cryptography Standardization Process, [108] R. Barnes, K. Bhargavan, B. Lipp, C.A. Wood, Hybrid Public Key Encryption, Tech. Rep. NIST IR 8454, National Institute of Standards and Technology, RFC 9180 Request for Comments, RFC Editor, 2022, http://dx.doi.org/10. Gaithersburg, MD, 2023. 17487/RFC9180, URL https://www.rfc-editor.org/info/rfc9180. [132] W.-K. Lee, K. Jang, J. Han, J. Park, J.H. Roh, H. Kim, J. Seo, Efficient implemen- [109] B. Westerbaan, C.A. Wood, X25519Kyber768Draft00 Hybrid Post-Quantum tation of lightweight hash functions on GPU and quantum computers for IoT KEM for HPKE, Internet-Draft draft-westerbaan-cfrg-hpke-xyber768d00-02, In- applications, IEEE Access 10 (2022) 59655–59674, http://dx.doi.org/10.1109/ ternet Engineering Task Force, 2023, URL https://datatracker.ietf.org/doc/ ACCESS.2022.3179755, URL https://ieeexplore.ieee.org/document/9799864. draft-westerbaan-cfrg-hpke-xyber768d00/02/, Work in Progress. [133] G. Brassard, P. Høyer, An exact quantum polynomial-time algorithm for Simon’s [110] D. Harkins, Deterministic Nonce-less Hybrid Public Key Encryption, Internet- problem, in: Proceedings of the Fifth Israeli Symposium on Theory of Computing Draft draft-irtf-cfrg-dnhpke-04, Internet Engineering Task Force, 2024, URL and Systems, ISTCS’97, IEEE, 1997, pp. 12–23, http://dx.doi.org/10.1109/ https://datatracker.ietf.org/doc/draft-irtf-cfrg-dnhpke/04/, Work in Progress. ISTCS.1997.595153. [111] P. Kampanakis, D. Stebila, T. Hansen, Post-quantum Hybrid Key Exchange [134] S. Aaronson, D. Gottesman, Improved simulation of stabilizer circuits, Phys. in SSH, Internet-Draft draft-kampanakis-curdle-ssh-pq-ke-01, Internet Engineer- Rev. A 70 (5) (2004) 052328, http://dx.doi.org/10.1103/PhysRevA.70.052328. ing Task Force, 2023, URL https://datatracker.ietf.org/doc/draft-kampanakis- [135] ISO Central Secretary, Information Technology-Security Techniques-Entity curdle-ssh-pq-ke/01/, Work in Progress. Authentication-Part 1: General, Standard ISO/IEC 9798-1:2010, International [112] B. Westerbaan, D. Stebila, X25519Kyber768Draft00 Hybrid Post-Quantum Organization for Standardization, 2010, URL https://www.iso.org/standard/ Key Agreement, Internet-Draft draft-tls-westerbaan-xyber768d00-03, Internet 53634.html. Engineering Task Force, 2023, URL https://datatracker.ietf.org/doc/draft-tls- [136] ISO Central Secretary, IT Security Techniques-Entity Authentication-Part 2: westerbaan-xyber768d00/03/, Work in Progress. Mechanisms Using Authenticated Encryption, Standard ISO/IEC 9798-2:2019, [113] D. Stebila, S. Fluhrer, S. Gueron, Hybrid Key Exchange in TLS 1.3, (Internet- International Organization for Standardization, 2019, URL https://www.iso.org/ Draft draft-ietf-tls-hybrid-design-10) Internet Engineering Task Force, 2024, standard/67114.html. URL https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/10/, Work in [137] ISO Central Secretary, IT Security Techniques-Entity Authentication-Part 3: Progress. Mechanisms Using Digital Signature Techniques, Standard ISO/IEC 9798- [114] M.S. Turan, M.S. Turan, K. McKay, D. Chang, L.E. Bassham, J. Kang, N.D. 3:2019, International Organization for Standardization, 2019, URL https:// Waller, J.M. Kelsey, D. Hong, Status Report on the Final Round of the www.iso.org/standard/67115.html. NIST Lightweight Cryptography Standardization Process, US Department of [138] ISO Central Secretary, Information Technology-Security Techniques-Entity Commerce, National Institute of Standards and Technology, 2023. Authentication-Part 4: Mechanisms Using a Cryptographic Check Function, [115] M.S. Turan, K.A. McKay, J. Kang, J. Kelsey, D. Chang, Ascon-Based Lightweight Standard ISO/IEC 9798-4:1999, International Organization for Standardization, Cryptography Standards for Constrained Devices: Authenticated Encryption, 1999, URL https://www.iso.org/standard/31488.html. Hash, and Extendable Output Functions, NIST Special Publication 800-232, [139] ISO Central Secretary, Information technology-Security techniques-Entity National Institute of Standards and Technology (NIST), U.S. Department of authentication-Part 5: Mechanisms Using Zero-Knowledge Techniques, Standard Commerce, 2025, http://dx.doi.org/10.6028/NIST.SP.800-232, URL https:// ISO/IEC 9798-5:2009, International Organization for Standardization, 2009, nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-232.pdf. URL https://www.iso.org/standard/50456.html. [116] C. Dobraunig, M. Eichlseder, F. Mendel, M. Schläffer, Ascon v1. 2, 5 (6), 2016, [140] ISO Central Secretary, Information Technology-Security Techniques-Entity p. 7, Submission to the CAESAR Competition. Authentication-Part 6: mechanisms Using Manual Data Transfer, Standard [117] NIST, Lightweight cryptography, 2022, https://csrc.nist.gov/Projects/ ISO/IEC 9798-6:2010, International Organization for Standardization, 2010, lightweight-cryptography/finalists. URL https://www.iso.org/standard/54529.html. 49 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 [141] NIST, Entity Authentication Using Public Key Cryptography, NIST Special [163] P. Kampanakis, Q. Dang, Use of the SHAKE One-Way Hash Functions in Publication, 1997, URL https://csrc.nist.gov/pubs/fips/196/final. the Cryptographic Message Syntax (CMS), RFC 8702 Request for Comments, [142] C.W. Kaufman, DASS-Distributed Authentication Security Service, RFC 1507 Re- RFC Editor, 2020, http://dx.doi.org/10.17487/RFC8702, URL https://www.rfc- quest for Comments, RFC Editor, 1993, http://dx.doi.org/10.17487/RFC1507, editor.org/info/rfc8702. URL https://www.rfc-editor.org/info/rfc1507. [164] A. Medvinsky, M. Hur, Addition of Kerberos Cipher Suites to Transport Layer [143] R. Atkinson, N.M. Haller, On Internet Authentication, RFC 1704 Request for Security (TLS), RFC 2712 Request for Comments, RFC Editor, 1999, http://dx. Comments, RFC Editor, 1994, http://dx.doi.org/10.17487/RFC1704, URL https: doi.org/10.17487/RFC2712, URL https://www.rfc-editor.org/info/rfc2712. //www.rfc-editor.org/info/rfc1704. [165] K. Raeburn, Advanced Encryption Standard (AES) Encryption for Kerberos 5, RFC 3962 Request for Comments, RFC Editor, 2005, http://dx.doi.org/10. [144] N.M. Haller, The S/KEY One-Time Password System, RFC 1760 Request for 17487/RFC3962, URL https://www.rfc-editor.org/info/rfc3962. Comments, RFC Editor, 1995, http://dx.doi.org/10.17487/RFC1760, URL https: [166] M.J. Jenkins, M. Peck, K.W. Burgin, AES Encryption with HMAC-SHA2 for //www.rfc-editor.org/info/rfc1760. Kerberos 5, RFC 8009 Request for Comments, RFC Editor, 2016, http://dx. [145] D.C. Neuman, S. Hartman, K. Raeburn, T. Yu, The Kerberos Network Authenti- doi.org/10.17487/RFC8009, URL https://www.rfc-editor.org/info/rfc8009. cation Service (V5), RFC 4120 Request for Comments, RFC Editor, 2005, http:// [167] K. Jaganathan, K. Lauter, L. Zhu, Elliptic Curve Cryptography (ECC) Support for dx.doi.org/10.17487/RFC4120, URL https://www.rfc-editor.org/info/rfc4120. Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), RFC [146] ISO Central Secretary, Information Technology – Open Systems Interconnection 5349 Request for Comments, RFC Editor, 2008, http://dx.doi.org/10.17487/ – the Directory: Public-Key and Attribute Certificate Frameworks, Standard RFC5349, URL https://www.rfc-editor.org/info/rfc5349. ISO/IEC 9594-8, International Organization for Standardization, 2020, URL [168] S. Josefsson, Using Kerberos Version 5 over the Transport Layer Security (TLS) https://www.iso.org/standard/80325.html. Protocol, RFC 6251 Request for Comments, RFC Editor, 2011, http://dx.doi. [147] ISO Central Secretary, Information Technology-Security Techniques- org/10.17487/RFC6251, URL https://www.rfc-editor.org/info/rfc6251. Specification of TTP Services to Support the Application of Digital Signatures, [169] G. Hudson, Camellia Encryption for Kerberos 5, RFC 6803 Request for Com- Standard ISO/IEC 15945:2002, International Organization for Standardization, ments, RFC Editor, 2012, http://dx.doi.org/10.17487/RFC6803, URL https:// 2002, URL https://www.iso.org/standard/29578.html. www.rfc-editor.org/info/rfc6803. [148] ISO Central Secretary, Public Key Infrastructure for Financial Services-Practices [170] S. Sorce, T. Yu, Kerberos Authorization Data Container Authenticated by Mul- and Policy Framework, Standard ISO/IEC 21188:2018, International Organi- tiple Message Authentication Codes (MACs), RFC 7751 Request for Comments, zation for Standardization, 2018, URL https://www.iso.org/standard/63134. RFC Editor, 2016, http://dx.doi.org/10.17487/RFC7751, URL https://www.rfc- html. editor.org/info/rfc7751. [149] American Bankers Association, et al., ANSI X9. 62: The Elliptic Curve Dig- [171] L. Astrand, L. Zhu, M. Cullen, M. Cullen, G. Hudson, Public Key Cryptography ital Signature Algorithm, Tech. Rep., Technical report. American Bankers for Initial Authentication in Kerberos (PKINIT) Algorithm Agility, RFC 8636 Re- Association, 1999. quest for Comments, RFC Editor, 2019, http://dx.doi.org/10.17487/RFC8636, [150] American Bankers Association, et al., ANSI X9. 63 elliptic curve key agreement URL https://www.rfc-editor.org/info/rfc8636. and key transport protocols.[on-line], 1999. [172] S. Rose, M. Larson, D. Massey, R. Austein, R. Arends, DNS Security Introduction and Requirements, RFC 4033 Request for Comments, RFC Editor, 2005, http:// [151] B. Kaliski, PKCS #7: Cryptographic Message Syntax Version 1.5, RFC 2315 Re- dx.doi.org/10.17487/RFC4033, URL https://www.rfc-editor.org/info/rfc4033. quest for Comments, RFC Editor, 1998, http://dx.doi.org/10.17487/RFC2315, [173] S. Josefsson, Storing Certificates in the Domain Name System (DNS), RFC URL https://www.rfc-editor.org/info/rfc2315. 4398 Request for Comments, RFC Editor, 2006, http://dx.doi.org/10.17487/ [152] R. Housley, J. Schaad, B. Kaliski, Additional Algorithms and Identifiers for RFC4398, URL https://www.rfc-editor.org/info/rfc4398. RSA Cryptography for use in the Internet X.509 Public Key Infrastructure [174] R. Arends, G. Sisson, D. Blacka, B. Laurie, DNS Security (DNSSEC) Hashed Certificate and Certificate Revocation List (CRL) Profile, RFC 4055 Request Authenticated Denial of Existence, RFC 5155 Request for Comments, RFC Ed- for Comments, RFC Editor, 2005, http://dx.doi.org/10.17487/RFC4055, URL itor, 2008, http://dx.doi.org/10.17487/RFC5155, URL https://www.rfc-editor. https://www.rfc-editor.org/info/rfc4055. org/info/rfc5155. [153] K. Moriarty, B. Kaliski, A. Rusch, PKCS #5: Password-Based Cryptography [175] O. Kolkman, M. Mekking, R.M. Gieben, DNSSEC Operational Practices, Version Specification Version 2.1, RFC 8018 Request for Comments, RFC Editor, 2, RFC 6781 Request for Comments, RFC Editor, 2012, http://dx.doi.org/10. 2017, http://dx.doi.org/10.17487/RFC8018, URL https://www.rfc-editor.org/ 17487/RFC6781, URL https://www.rfc-editor.org/info/rfc6781. info/rfc8018. [176] V. Dolmatov, A. Degtyarev, GOST R 34.10-2012: Digital Signature Algorithm, [154] S. Turner, D.R.L. Brown, Use of Elliptic Curve Cryptography (ECC) Algorithms RFC 7091 Request for Comments, RFC Editor, 2013, http://dx.doi.org/10. in Cryptographic Message Syntax (CMS), RFC 5753 Request for Comments, 17487/RFC7091, URL https://www.rfc-editor.org/info/rfc7091. RFC Editor, 2010, http://dx.doi.org/10.17487/RFC5753, URL https://www.rfc- [177] O. Surý, R. Edmonds, Edwards-Curve Digital Security Algorithm (EdDSA) for editor.org/info/rfc5753. DNSSEC, RFC 8080 Request for Comments, RFC Editor, 2017, http://dx.doi. [155] T. Polk, R. Housley, S. Turner, D.R.L. Brown, K. Yiu, Elliptic Curve Cryptogra- org/10.17487/RFC8080, URL https://www.rfc-editor.org/info/rfc8080. phy Subject Public Key Information, Request for Comments, (5480) RFC Editor, [178] P.E. Hoffman, W. Wijngaards, Elliptic Curve Digital Signature Algorithm (DSA) 2009, http://dx.doi.org/10.17487/RFC5480, URL https://www.rfc-editor.org/ for DNSSEC, RFC 6605 Request for Comments, RFC Editor, 2012, http://dx. info/rfc5480. doi.org/10.17487/RFC6605, URL https://www.rfc-editor.org/info/rfc6605. [156] P. Kampanakis, Q. Dang, Internet X.509 Public Key Infrastructure: Additional [179] V. Dolmatov, I. Ustinov, A. Chuprina, Use of GOST Signature Algorithms Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs, RFC 8692 Re- in DNSKEY and RRSIG Resource Records for DNSSEC, RFC 5933 Request quest for Comments, RFC Editor, 2019, http://dx.doi.org/10.17487/RFC8692, for Comments, RFC Editor, 2010, http://dx.doi.org/10.17487/RFC5933, URL URL https://www.rfc-editor.org/info/rfc8692. https://www.rfc-editor.org/info/rfc5933. [157] D.R.L. Brown, Q. Dang, T. Polk, S. Santesson, K. Moriarty, Internet X.509 [180] J. Jansen, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and Records for DNSSEC, RFC 5702 Request for Comments, (5702) RFC Editor, ECDSA, RFC 5758 Request for Comments, RFC Editor, 2010, http://dx.doi.org/ 2009, http://dx.doi.org/10.17487/RFC5702, URL https://www.rfc-editor.org/ 10.17487/RFC5758, URL https://www.rfc-editor.org/info/rfc5758. info/rfc5702. [181] D.E.E. 3rd, RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System [158] R. Housley, T. Polk, L.E.B. III, Algorithms and Identifiers for the Internet (DNS), RFC 3110 Request for Comments, RFC Editor, 2001, http://dx.doi.org/ X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) 10.17487/RFC3110, URL https://www.rfc-editor.org/info/rfc3110. Profile, RFC 3279 Request for Comments, (3279) RFC Editor, 2002, http://dx. [182] B. Makarenko, V. Dolmatov, Use of GOST 2012 Signature Algorithms in doi.org/10.17487/RFC3279, URL https://www.rfc-editor.org/info/rfc3279. DNSKEY and RRSIG Resource Records for DNSSEC, Internet-Draft draft- [159] D. Shefanovski, S. Leontiev, Using the GOST R 34.10-94, GOST R 34.10- makarenko-gost2012-dnssec-05, Internet Engineering Task Force, 2024, URL 2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key https://datatracker.ietf.org/doc/draft-makarenko-gost2012-dnssec/05/, Work in Infrastructure Certificate and CRL Profile, RFC 4491 Request for Comments, Progress. RFC Editor, 2006, http://dx.doi.org/10.17487/RFC4491, URL https://www.rfc- [183] H. Lee, T. Kwon, DNSSEC Extension by Using PKIX Certificates, Internet- editor.org/info/rfc4491. Draft draft-dnsop-dnssec-extension-pkix-01, Internet Engineering Task Force, [160] J. Schaad, H. Prafullchandra, Diffie-Hellman Proof-of-Possession Algorithms, 2023, URL https://datatracker.ietf.org/doc/draft-dnsop-dnssec-extension-pkix/ RFC 6955 Request for Comments, RFC Editor, 2013, http://dx.doi.org/10. 01/, Work in Progress. 17487/RFC6955, URL https://www.rfc-editor.org/info/rfc6955. [184] C. Zhang, Y. Liu, F. Leng, Q. Zhao, Z. He, SM2 Digital Signature Algorithm [161] R. Housley, Algorithm Requirements Update to the Internet X.509 Public Key for DNSSEC, Internet-Draft draft-cuiling-dnsop-sm2-alg-05, Internet Engineering Infrastructure Certificate Request Message Format (CRMF), RFC 9045 Request Task Force, 2023, URL https://datatracker.ietf.org/doc/draft-cuiling-dnsop-sm2- for Comments, RFC Editor, 2021, http://dx.doi.org/10.17487/RFC9045, URL alg/05/, Work in Progress. https://www.rfc-editor.org/info/rfc9045. [185] I. Young, L. Johansson, S. Cantor, The Entity Category Security Assertion [162] S. Turner, Using SHA2 Algorithms with Cryptographic Message Syntax, RFC Markup Language (SAML) Attribute Types, RFC 8409 Request for Comments, 5754 Request for Comments, RFC Editor, 2010, http://dx.doi.org/10.17487/ RFC Editor, 2018, http://dx.doi.org/10.17487/RFC8409, URL https://www.rfc- RFC5754, URL https://www.rfc-editor.org/info/rfc5754. editor.org/info/rfc8409. 50 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 [186] J. Howlett, S. Hartman, A. Pérez-Méndez, A RADIUS Attribute, Binding, Profiles, [209] W. Denniss, J. Bradley, OAuth 2.0 for Native Apps, RFC 8252 Request for Name Identifier Format, and Confirmation Methods for the Security Assertion Comments, RFC Editor, 2017, http://dx.doi.org/10.17487/RFC8252, URL https: Markup Language (SAML), RFC 7833 Request for Comments, RFC Editor, //www.rfc-editor.org/info/rfc8252. 2016, http://dx.doi.org/10.17487/RFC7833, URL https://www.rfc-editor.org/ [210] M.B. Jones, N. Sakimura, J. Bradley, OAuth 2.0 Authorization Server Metadata, info/rfc7833. RFC Editor Request for Comments, RFC Editor, 2018, http://dx.doi.org/10. [187] B. Campbell, C. Mortimore, M.B. Jones, Security Assertion Markup Language 17487/RFC8414, URL https://www.rfc-editor.org/info/rfc8414. (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization [211] W. Denniss, J. Bradley, M.B. Jones, H. Tschofenig, OAuth 2.0 Device Autho- Grants, RFC 7522 Request for Comments, RFC Editor, 2015, http://dx.doi.org/ rization Grant, RFC 8628 Request for Comments, RFC Editor, 2019, http://dx. 10.17487/RFC7522, URL https://www.rfc-editor.org/info/rfc7522. doi.org/10.17487/RFC8628, URL https://www.rfc-editor.org/info/rfc8628. [188] K. Wierenga, E. Lear, S. Josefsson, A Simple Authentication and Security Layer [212] M.B. Jones, A. Nadalin, B. Campbell, J. Bradley, C. Mortimore, OAuth 2.0 Token (SASL) and GSS-API Mechanism for the Security Assertion Markup Language Exchange, RFC 8693 Request for Comments, RFC Editor, 2020, http://dx.doi. (SAML), RFC 6595 Request for Comments, RFC Editor, 2012, http://dx.doi. org/10.17487/RFC8693, URL https://www.rfc-editor.org/info/rfc8693. org/10.17487/RFC6595, URL https://www.rfc-editor.org/info/rfc6595. [213] Y. Wilson, A. Hingnikar, SAML 2, in: Solving Identity Management in Modern [189] G. Whitehead, et al., Metadata Profile for the OASIS Security Assertion Markup Applications: Demystifying OAuth 2, OpenID Connect, and SAML 2, Springer, Language (SAML) V1.x. OASIS SSTC, 2005, URL http://www.oasis-open.org/ 2022, pp. 127–141. committees/security/. [214] D. Hardt, The Oauth 2.0 Authorization Framework, Tech. Rep., 2012. [190] S. Cantor, et al., Assertions and Protocols for the OASIS Security Assertion [215] A.A. Giron, Migrating applications to post-quantum cryptography: Beyond Markup Language (SAML) V2.0. OASIS SSTC, 2005, URL http://docs.oasis- algorithm replacement, 2023, Cryptology ePrint Archive. open.org/security/saml/v2.0/saml-core-2.0-os.pdf. [216] J.A. Salowey, D. McGrew, A. Choudhury, AES Galois Counter Mode (GCM) Ci- [191] OASIS Committee Specification 01, SAML v2.0 Metadata Profile for Algo- pher Suites for TLS, RFC 5288 Request for Comments, RFC Editor, 2008, http:// rithm Support Version 1.0,, 2011, URL http://docs.oasis-open.org/security/ dx.doi.org/10.17487/RFC5288, URL https://www.rfc-editor.org/info/rfc5288. saml/Post2.0/sstc-saml-metadata-algsupport-v1.0-cs01.odt. [217] M. Badra, Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and [192] W. Draft, SAML V2. 0 holder-of-key web browser SSO profile version 1.0, 2008. AES Galois Counter Mode, RFC 5487 Request for Comments, RFC Editor, [193] L. Seitz, Additional OAuth Parameters for Authentication and Authorization for 2009, http://dx.doi.org/10.17487/RFC5487, URL https://www.rfc-editor.org/ Constrained Environments (ACE), RFC 9201 Request for Comments, RFC Editor, info/rfc5487. 2022, http://dx.doi.org/10.17487/RFC9201, URL https://www.rfc-editor.org/ [218] I. Hajjeh, M. Badra, ECDHE_PSK Cipher Suites for Transport Layer Security info/rfc9201. (TLS), RFC 5489 Request for Comments, RFC Editor, 2009, http://dx.doi.org/ [194] B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt, OAuth 2.0 Mutual-TLS 10.17487/RFC5489, URL https://www.rfc-editor.org/info/rfc5489. Client Authentication and Certificate-Bound Access Tokens, RFC 8705 Request [219] M.K. A. Kato, S. Kanno, Camellia Cipher Suites for TLS, RFC 5932 Request for Comments, (8705) RFC Editor, 2020, http://dx.doi.org/10.17487/RFC8705, for Comments, RFC Editor, 2010, http://dx.doi.org/10.17487/RFC5932, URL URL https://www.rfc-editor.org/info/rfc8705. https://www.rfc-editor.org/info/rfc5932. [195] J. Richer, OAuth 2.0 Token Introspection, RFC 7662 Request for Comments, [220] D. McGrew, D. Bailey, AES-CCM Cipher Suites for Transport Layer Security RFC Editor, 2015, http://dx.doi.org/10.17487/RFC7662, URL https://www.rfc- (TLS), RFC 6655 Request for Comments, RFC Editor, 2012, http://dx.doi.org/ editor.org/info/rfc7662. 10.17487/RFC6655, URL https://www.rfc-editor.org/info/rfc6655. [196] M.B. Jones, B. Campbell, C. Mortimore, JSON Web Token (JWT) Profile for [221] D. McGrew, D. Bailey, M. Campagna, R. Dugal, AES-CCM Elliptic Curve OAuth 2.0 Client Authentication and Authorization Grants, RFC 7523 Request Cryptography (ECC) Cipher Suites for TLS, RFC 7251 Request for Comments, for Comments, RFC Editor, 2015, http://dx.doi.org/10.17487/RFC7523, URL RFC Editor, 2014, http://dx.doi.org/10.17487/RFC7251, URL https://www.rfc- https://www.rfc-editor.org/info/rfc7523. editor.org/info/rfc7251. [197] W. Mills, T. Showalter, H. Tschofenig, A Set of Simple Authentication and [222] E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.3, RFC Security Layer (SASL) Mechanisms for OAuth, RFC 7628 Request for Comments, 8446 Request for Comments, RFC Editor, 2018, http://dx.doi.org/10.17487/ RFC Editor, 2015, http://dx.doi.org/10.17487/RFC7628, URL https://www.rfc- RFC8446, URL https://www.rfc-editor.org/info/rfc8446. editor.org/info/rfc7628. [223] E. Rescorla, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES [198] N. Sakimura, J. Bradley, N. Agarwal, Proof Key for Code Exchange by OAuth Galois Counter Mode (GCM), RFC 5289 Request for Comments, RFC Editor, Public Clients, RFC 7636 Request for Comments, RFC Editor, 2015, http://dx. 2008, http://dx.doi.org/10.17487/RFC5289, URL https://www.rfc-editor.org/ doi.org/10.17487/RFC7636, URL https://www.rfc-editor.org/info/rfc7636. info/rfc5289. [199] B. Campbell, C. Mortimore, M.B. Jones, Y.Y. Goland, Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, RFC 7521 Request [224] A.O. Freier, P. Karlton, P.C. Kocher, The Secure Sockets Layer (SSL) Protocol for Comments, RFC Editor, 2015, http://dx.doi.org/10.17487/RFC7521, URL Version 3.0, RFC 6101 Request for Comments, RFC Editor, 2011, http://dx.doi. https://www.rfc-editor.org/info/rfc7521. org/10.17487/RFC6101, URL https://www.rfc-editor.org/info/rfc6101. [200] N. Sakimura, J. Bradley, M.B. Jones, The OAuth 2.0 Authorization Framework: [225] Y. Sheffer, P. Saint-Andre, T. Fossati, Recommendations for Secure Use of JWT-Secured Authorization Request (JAR), RFC 9101 Request for Comments, Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), RFC Editor, 2021, http://dx.doi.org/10.17487/RFC9101, URL https://www.rfc- RFC 9325 Request for Comments, RFC Editor, 2022, http://dx.doi.org/10. editor.org/info/rfc9101. 17487/RFC9325, URL https://www.rfc-editor.org/info/rfc9325. [201] L. Seitz, G. Selander, E. Wahlstroem, S. Erdtman, H. Tschofenig, Authentication [226] Y. Nir, S. Josefsson, M. Pégourié-Gonnard, Elliptic Curve Cryptography (ECC) and Authorization for Constrained Environments Using the OAuth 2.0 Frame- Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier, RFC work (ACE-OAuth), RFC 9200 Request for Comments, RFC Editor, 2022, http:// 8422 Request for Comments, RFC Editor, 2018, http://dx.doi.org/10.17487/ dx.doi.org/10.17487/RFC9200, URL https://www.rfc-editor.org/info/rfc9200. RFC8422, URL https://www.rfc-editor.org/info/rfc8422. [202] T. Lodderstedt, M. McGloin, P. Hunt, OAuth 2.0 Threat Model and Security [227] S.V. Smyshlyaev, E. Alekseev, E. Griboedova, A. Babueva, L. Nikiforova, GOST Considerations, RFC 6819 Request for Comments, RFC Editor, 2013, http://dx. Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3, RFC doi.org/10.17487/RFC6819, URL https://www.rfc-editor.org/info/rfc6819. 9367 Request for Comments, RFC Editor, 2023, http://dx.doi.org/10.17487/ [203] J. Richer, M.B. Jones, J. Bradley, M. Machulak, P. Hunt, OAuth 2.0 Dynamic RFC9367, URL https://www.rfc-editor.org/info/rfc9367. Client Registration Protocol, RFC 7591 Request for Comments, RFC Editor, [228] L. Bruckert, J. Merkle, M. Lochter, Elliptic Curve Cryptography (ECC) Brainpool 2015, http://dx.doi.org/10.17487/RFC7591, URL https://www.rfc-editor.org/ Curves for Transport Layer Security (TLS) Version 1.3, RFC 8734 Request info/rfc7591. for Comments, RFC Editor, 2020, http://dx.doi.org/10.17487/RFC8734, URL [204] M.B. Jones, D. Hardt, The OAuth 2.0 Authorization Framework: Bearer Token https://www.rfc-editor.org/info/rfc8734. Usage, RFC 6750 Request for Comments, RFC Editor, 2012, http://dx.doi.org/ [229] J. Merkle, M. Lochter, Elliptic Curve Cryptography (ECC) Brainpool Curves for 10.17487/RFC6750, URL https://www.rfc-editor.org/info/rfc6750. Transport Layer Security (TLS), RFC 7027 Request for Comments, RFC Editor, [205] V. Bertocci, JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens, RFC 2013, http://dx.doi.org/10.17487/RFC7027, URL https://www.rfc-editor.org/ 9068 Request for Comments, RFC Editor, 2021, http://dx.doi.org/10.17487/ info/rfc7027. RFC9068, URL https://www.rfc-editor.org/info/rfc9068. [230] N. Mavrogiannopoulos, D.K. Gillmor, Using OpenPGP Keys for Transport Layer [206] D. Hardt, The OAuth 2.0 Authorization Framework, RFC 6749 Request for Security (TLS) Authentication, RFC 6091 Request for Comments, RFC Editor, Comments, RFC Editor, 2012, http://dx.doi.org/10.17487/RFC6749, URL https: 2011, http://dx.doi.org/10.17487/RFC6091, URL https://www.rfc-editor.org/ //www.rfc-editor.org/info/rfc6749. info/rfc6091. [207] T. Lodderstedt, S. Dronia, M. Scurtescu, OAuth 2.0 Token Revocation, RFC [231] P. Gutmann, Encrypt-then-MAC for Transport Layer Security (TLS) and Data- 7009 Request for Comments, RFC Editor, 2013, http://dx.doi.org/10.17487/ gram Transport Layer Security (DTLS), (7366) RFC Editor, 2014, http://dx.doi. RFC7009, URL https://www.rfc-editor.org/info/rfc7009. org/10.17487/RFC7366, URL https://www.rfc-editor.org/info/rfc7366. [208] J. Richer, M.B. Jones, J. Bradley, M. Machulak, OAuth 2.0 Dynamic Client [232] E. Rescorla, H. Tschofenig, N. Modadugu, The Datagram Transport Layer Registration Management Protocol, RFC 7592 Request for Comments, RFC Ed- Security (DTLS) Protocol Version 1.3, RFC 9147 Request for Comments, itor, 2015, http://dx.doi.org/10.17487/RFC7592, URL https://www.rfc-editor. RFC Editor, 2022, http://dx.doi.org/10.17487/RFC9147, URL https://www.rfc- org/info/rfc7592. editor.org/info/rfc9147. 51 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 [233] V. Smyslov, Announcing Supported Authentication Methods in IKEv2, Internet- [256] K.R. Glenn, C.R. Madson, The Use of HMAC-SHA-1-96 within ESP and AH, RFC Draft Draft-Ietf-Ipsecme-Ikev2-Auth-Announce-03, Internet Engineering Task 2404 Request for Comments, RFC Editor, 1998, http://dx.doi.org/10.17487/ Force, 2023, URL https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth- RFC2404, URL https://www.rfc-editor.org/info/rfc2404. announce/03/, Work in Progress. [257] A.D. Keromytis, N. Provos, The Use of HMAC-RIPEMD-160-96 within ESP and [234] C. Kaufman, P.E. Hoffman, Y. Nir, P. Eronen, T. Kivinen, Internet Key Exchange AH, RFC 2857 Request for Comments, RFC Editor, 2000, http://dx.doi.org/10. Protocol Version 2 (IKEv2), RFC 7296 Request for Comments, RFC Editor, 17487/RFC2857, URL https://www.rfc-editor.org/info/rfc2857. 2014, http://dx.doi.org/10.17487/RFC7296, URL https://www.rfc-editor.org/ [258] S. Frankel, S.G. Kelly, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA- info/rfc7296. 512 with IPsec, RFC 4868 Request for Comments, RFC Editor, 2007, http://dx. [235] C. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D.V. Geest, O. Garcia-Morchon, doi.org/10.17487/RFC4868, URL https://www.rfc-editor.org/info/rfc4868. V. Smyslov, Multiple Key Exchanges in the Internet Key Exchange Protocol [259] K. Burgin, M. Peck, Suite B Profile for Internet Protocol Security (IPsec), RFC Version 2 (IKEv2), RFC 9370 Request for Comments, RFC Editor, 2023, http:// 6380 Request for Comments, RFC Editor, 2011, http://dx.doi.org/10.17487/ dx.doi.org/10.17487/RFC9370, URL https://www.rfc-editor.org/info/rfc9370. RFC6380, URL https://www.rfc-editor.org/info/rfc6380. [236] T. Kivinen, J. Snyder, Signature Authentication in the Internet Key Exchange [260] C.M. Lonvick, T. Ylonen, The Secure Shell (SSH) Protocol Architecture, RFC Version 2 (IKEv2), RFC 7427 Request for Comments, (7427) RFC Editor, 4251 Request for Comments, RFC Editor, 2006, http://dx.doi.org/10.17487/ 2015, http://dx.doi.org/10.17487/RFC7427, URL https://www.rfc-editor.org/ RFC4251, URL https://www.rfc-editor.org/info/rfc4251. info/rfc7427. [261] M.D. Baushke, d. bider, SHA-2 Data Integrity Verification for the Secure Shell [237] Y. Sheffer, S. Fluhrer, Additional Diffie-Hellman Tests for the Internet Key (SSH) Transport Layer Protocol, RFC 6668 Request for Comments, RFC Editor, Exchange Protocol Version 2 (IKEv2), RFC 6989 Request for Comments, 2012, http://dx.doi.org/10.17487/RFC6668, URL https://www.rfc-editor.org/ RFC Editor, 2013, http://dx.doi.org/10.17487/RFC6989, URL https://www.rfc- info/rfc6668. editor.org/info/rfc6989. [262] P. Gutmann, A Pre-Authentication Mechanism for SSH, Internet-Draft draft- [238] D.E. Fu, J. Solinas, IKE and IKEv2 Authentication Using the Elliptic Curve gutmann-ssh-preauth-00, Internet Engineering Task Force, 2022, URL https: Digital Signature Algorithm (ECDSA), RFC 4754 Request for Comments, (4754) //datatracker.ietf.org/doc/draft-gutmann-ssh-preauth/00/, Work in Progress. RFC Editor, 2007, http://dx.doi.org/10.17487/RFC4754, URL https://www.rfc- [263] M.D. Baushke, Key Exchange (KEX) Method Updates and Recommendations for editor.org/info/rfc4754. Secure Shell (SSH), RFC 9142 Request for Comments, RFC Editor, 2022, http:// [239] J.I. Schiller, Cryptographic Algorithms for Use in the Internet Key Exchange dx.doi.org/10.17487/RFC9142, URL https://www.rfc-editor.org/info/rfc9142. Version 2 (IKEv2), RFC 4307 Request for Comments, RFC Editor, 2005, http:// dx.doi.org/10.17487/RFC4307, URL https://www.rfc-editor.org/info/rfc4307. [264] O. Surý, Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm [240] P.E. Hoffman, The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records, RFC Protocol (IKE), RFC 4434 Request for Comments, RFC Editor, 2006, http://dx. 6594 Request for Comments, RFC Editor, 2012, http://dx.doi.org/10.17487/ doi.org/10.17487/RFC4434, URL https://www.rfc-editor.org/info/rfc4434. RFC6594, URL https://www.rfc-editor.org/info/rfc6594. [241] S. murthy, S. Shen, Y. Mao, Using Advanced Encryption Standard Counter Mode [265] d. bider, Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol, RFC (SSH) Protocol, RFC 8332 Request for Comments, RFC Editor, 2018, http://dx. 5930 Request for Comments, RFC Editor, 2010, http://dx.doi.org/10.17487/ doi.org/10.17487/RFC8332, URL https://www.rfc-editor.org/info/rfc8332. RFC5930, URL https://www.rfc-editor.org/info/rfc5930. [266] B. Harris, L. Velvindron, Ed25519 and Ed448 Public Key Algorithms for the [242] Y. Nir, Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Secure Shell (SSH) Protocol, RFC 8709 Request for Comments, RFC Editor, Internet Key Exchange Protocol Version 2 (IKEv2), RFC 8420 Request for 2020, http://dx.doi.org/10.17487/RFC8709, URL https://www.rfc-editor.org/ Comments, RFC Editor, 2018, http://dx.doi.org/10.17487/RFC8420, URL https: info/rfc8709. //www.rfc-editor.org/info/rfc8420. [267] A. Adamantiadis, S. Josefsson, M.D. Baushke, Secure Shell (SSH) Key Exchange [243] S. Fluhrer, P. Kampanakis, D. McGrew, V. Smyslov, Mixing Preshared Keys Method Using Curve25519 and Curve448, RFC 8731 Request for Comments, in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum RFC Editor, 2020, http://dx.doi.org/10.17487/RFC8731, URL https://www.rfc- Security, RFC 8784 Request for Comments, RFC Editor, 2020, http://dx.doi. editor.org/info/rfc8731. org/10.17487/RFC8784, URL https://www.rfc-editor.org/info/rfc8784. [268] M.D. Baushke, More Modular Exponentiation (MODP) Diffie-Hellman (DH) [244] V. Smyslov, Alternative Approach for Mixing Preshared Keys in IKEv2 for Key Exchange (KEX) Groups for Secure Shell (SSH), RFC 8268 Request for Post-quantum Security, Internet-Draft draft-smyslov-ipsecme-ikev2-qr-alt-08, In- Comments, RFC Editor, 2017, http://dx.doi.org/10.17487/RFC8268, URL https: ternet Engineering Task Force, 2023, URL https://datatracker.ietf.org/doc/ //www.rfc-editor.org/info/rfc8268. draft-smyslov-ipsecme-ikev2-qr-alt/08/, Work in Progress. [269] K. Igoe, Suite B Cryptographic Suites for Secure Shell (SSH), RFC 6239 Request [245] S. Frankel, K.R. Glenn, S.G. Kelly, The AES-CBC Cipher Algorithm and Its Use for Comments, RFC Editor, 2011, http://dx.doi.org/10.17487/RFC6239, URL with IPsec, RFC 3602 Request for Comments, RFC Editor, 2003, http://dx.doi. https://www.rfc-editor.org/info/rfc6239. org/10.17487/RFC3602, URL https://www.rfc-editor.org/info/rfc3602. [270] C.M. Lonvick, T. Ylonen, The Secure Shell (SSH) Authentication Protocol, RFC [246] S. Frankel, H.C. Herbert, The AES-XCBC-MAC-96 Algorithm and Its Use With 4252 Request for Comments, RFC Editor, 2006, http://dx.doi.org/10.17487/ IPsec, RFC 3566 Request for Comments, RFC Editor, 2003, http://dx.doi.org/ RFC4252, URL https://www.rfc-editor.org/info/rfc4252. 10.17487/RFC3566, URL https://www.rfc-editor.org/info/rfc3566. [271] B. Harris, RSA Key Exchange for the Secure Shell (SSH) Transport Layer [247] R. Poovendran, J. Song, J. Lee, The AES-CMAC-96 Algorithm and Its Use with Protocol, RFC 4252 Request for Comments, RFC Editor, 2006, http://dx.doi. IPsec, RFC 4494 Request for Comments, RFC Editor, 2006, http://dx.doi.org/ org/10.17487/RFC4432, URL https://www.rfc-editor.org/info/rfc4432. 10.17487/RFC4494, URL https://www.rfc-editor.org/info/rfc4494. [272] C. Namprempre, T. Kohno, M. Bellare, The Secure Shell (SSH) Transport Layer [248] P.E. Hoffman, Use of Hash Algorithms in Internet Key Exchange (IKE) and Encryption Modes, RFC 4344 Request for Comments, RFC Editor, 2006, http:// IPsec, RFC 4894 Request for Comments, RFC Editor, 2007, http://dx.doi.org/ dx.doi.org/10.17487/RFC4344, URL https://www.rfc-editor.org/info/rfc4344. 10.17487/RFC4894, URL https://www.rfc-editor.org/info/rfc4894. [273] J.A. Salowey, V. Welch, J. Hutzelman, J. Galbraith, Generic Security Service [249] P.E. Hoffman, Cryptographic Suites for IPsec, RFC 4308 Request for Comments, Application Program Interface (GSS-API) Authentication and Key Exchange for RFC Editor, 2005, http://dx.doi.org/10.17487/RFC4308, URL https://www.rfc- the Secure Shell (SSH) Protocol, RFC 4462 Request for Comments, RFC Editor, editor.org/info/rfc4308. 2006, http://dx.doi.org/10.17487/RFC4462, URL https://www.rfc-editor.org/ [250] L. Law, J. Solinas, Suite B Cryptographic Suites for IPsec, RFC 6379 Request info/rfc4462. for Comments, RFC Editor, 2011, http://dx.doi.org/10.17487/RFC6379, URL [274] S.J. Lunt, FTP Security Extensions, RFC 2228 Request for Comments, RFC Ed- https://www.rfc-editor.org/info/rfc6379. itor, 1997, http://dx.doi.org/10.17487/RFC2228, URL https://www.rfc-editor. [251] J. Viega, D. McGrew, The Use of Galois/Counter Mode (GCM) in IPsec org/info/rfc2228. Encapsulating Security Payload (ESP), Request for Comments, RFC Editor, 2005, http://dx.doi.org/10.17487/RFC4106, URL https://www.rfc-editor.org/ [275] M. Allman, S. Ostermann, FTP Security Considerations, Request for Comments, info/rfc4106. RFC Editor, 1999, http://dx.doi.org/10.17487/RFC2577, URL https://www.rfc- [252] M. Kojo, T. Kivinen, More Modular Exponential (MODP) Diffie-Hellman groups editor.org/info/rfc2577. for Internet Key Exchange (IKE), RFC 3526 Request for Comments, RFC Editor, [276] C.M. Lonvick, T. Ylonen, The Secure Shell (SSH) Transport Layer Protocol, RFC 2003, http://dx.doi.org/10.17487/RFC3526, URL https://www.rfc-editor.org/ 4253 Request for Comments, RFC Editor, 2006, http://dx.doi.org/10.17487/ info/rfc3526. RFC4253, URL https://www.rfc-editor.org/info/rfc4253. [253] P.E. Metzger, W.A. Simpson, IP Authentication Using Keyed MD5, RFC 1828 Re- [277] P. Ford-Hutchinson, Securing FTP with TLS, RFC 4217 Request for Comments, quest for Comments, RFC Editor, 1995, http://dx.doi.org/10.17487/RFC1828, RFC Editor, 2005, http://dx.doi.org/10.17487/RFC4217, URL https://www.rfc- URL https://www.rfc-editor.org/info/rfc1828. editor.org/info/rfc4217. [254] M. Oehler, K.R. Glenn, HMAC-MD5 IP Authentication with Replay Prevention, [278] J. Schaad, B. Ramsdell, S. Turner, Secure/multipurpose Internet Mail Extensions RFC 2085 Request for Comments, RFC Editor, 1997, http://dx.doi.org/10. (S/MIME) Version 4.0 Message Specification, Tech. Rep., 2019. 17487/RFC2085, URL https://www.rfc-editor.org/info/rfc2085. [279] J. Schaad, B.C. Ramsdell, S. Turner, Secure/Multipurpose Internet Mail Ex- [255] K.R. Glenn, C.R. Madson, The Use of HMAC-MD5-96 within ESP and AH, RFC tensions (S/MIME) Version 4.0 Message Specification, RFC 8551 Request for 2403 Request for Comments, RFC Editor, 1998, http://dx.doi.org/10.17487/ Comments, RFC Editor, 2019, http://dx.doi.org/10.17487/RFC8551, URL https: RFC2403, URL https://www.rfc-editor.org/info/rfc2403. //www.rfc-editor.org/info/rfc8551. 52 V. Chouhan et al. Computer Standards & Interfaces 97 (2026) 104114 [280] J. Schaad, Enhanced Security Services for S/MIME, Internet-Draft draft-ietf- [296] P.E. Hoffman, C. Bonatti, A. Eggen, Securing X.400 Content with Secure/Multi- smime-rfc2634-update-00, Internet Engineering Task Force, 2004, URL https:// purpose Internet Mail Extensions (S/MIME), RFC 3854 Request for Comments, datatracker.ietf.org/doc/draft-ietf-smime-rfc2634-update/00/, Work in Progress. RFC Editor, 2004, http://dx.doi.org/10.17487/RFC3854, URL https://www.rfc- [281] J. Schaad, Experiment: Hash Functions with Parameters in the Cryptographic editor.org/info/rfc3854. Message Syntax (CMS) and S/MIME, RFC 6210 Request for Comments, RFC Ed- [297] European Telecommunications Standards Institute, Quantum safe cryptography itor, 2011, http://dx.doi.org/10.17487/RFC6210, URL https://www.rfc-editor. and security, 2015, URL https://www.etsi.org/images/files/ETSIWhitePapers/ org/info/rfc6210. QuantumSafeWhitepaper.pdf. [282] A. Kato, S. Moriai, Use of the Camellia Encryption Algorithm in Crypto- [298] N. Bindel, U. Herath, M. McKague, D. Stebila, Transitioning to a quantum- graphic Message Syntax (CMS), RFC 3657 Request for Comments, RFC Editor, resistant public key infrastructure, in: International Workshop on Post-Quantum 2004, http://dx.doi.org/10.17487/RFC3657, URL https://www.rfc-editor.org/ Cryptography, Springer, 2017, pp. 384–405. info/rfc3657. [299] N. Alnahawi, N. Schmitt, A. Wiesmaier, A. Heinemann, T. Grasmeyer, On [283] D.K. Gillmor, S/MIME Example Keys and Certificates, RFC 9216 Request for the state of crypto-agility, 2023, URL https://eprint.iacr.org/2023/487, https: Comments, RFC Editor, 2022, http://dx.doi.org/10.17487/RFC9216, URL https: //eprint.iacr.org/2023/487, Cryptology ePrint Archive, Paper 2023/487. //www.rfc-editor.org/info/rfc9216. [300] M.J. Dworkin, SP 800-38e. Recommendation for Block Cipher Modes of [284] A. Melnikov, S/MIME Signature Verification Extension to the JSON Meta Operation: The XTS-AES Mode for Confidentiality on Storage Devices, National Application Protocol (JMAP), RFC 9219 Request for Comments, RFC Editor, Institute of Standards & Technology, 2010. 2022, http://dx.doi.org/10.17487/RFC9219, URL https://www.rfc-editor.org/ [301] M. Dworkin, et al., Recommendation for Block Cipher Modes of Operation: info/rfc9219. Methods for Format-Preserving Encryption, vol. 800, NIST Special Publication, [285] A. Melnikov, Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates, RFC 8823 Request for Comments, RFC Editor, 2016, p. 38G. 2021, http://dx.doi.org/10.17487/RFC8823, URL https://www.rfc-editor.org/ [302] M.J. Dworkin, SP 800-38B. Recommendation For Block Cipher Modes of info/rfc8823. Operation: The CMAC Mode for Authentication, National Institute of Standards [286] J. Schaad, B.C. Ramsdell, S. Turner, Secure/Multipurpose Internet Mail Ex- & Technology, 2005. tensions (S/MIME) Version 4.0 Certificate Handling, RFC 8550 Request for [303] M.J. Dworkin, SP 800-38c. Recommendation for Block Cipher Modes of Opera- Comments, RFC Editor, 2019, http://dx.doi.org/10.17487/RFC8550, URL https: tion: The CCM Mode for Authentication and Confidentiality, National Institute //www.rfc-editor.org/info/rfc8550. of Standards & Technology, 2004. [287] B. Campbell, R. Housley, SIP-Based Messaging with S/MIME, RFC 8591 Request [304] M.J. Dworkin, SP 800-38d. Recommendation for Block Cipher Modes of Oper- for Comments, RFC Editor, 2019, http://dx.doi.org/10.17487/RFC8591, URL ation: Galois/counter Mode (GCM) and GMAC, National Institute of Standards https://www.rfc-editor.org/info/rfc8591. & Technology, 2007. [288] P.E. Hoffman, J. Schlyter, Using Secure DNS to Associate Certificates with [305] B. Crow, I. Widjaja, J. Kim, P. Sakai, IEEE 802.11 Wireless Local Area networks, Domain Names for S/MIME, RFC 8162 Request for Comments, RFC Editor, IEEE Commun. Mag. 35 (9) (1997) 116–126, http://dx.doi.org/10.1109/35. 2017, http://dx.doi.org/10.17487/RFC8162, URL https://www.rfc-editor.org/ 620533. info/rfc8162. [306] S.K. (NIST), Modes of Operation Validation System for the Triple Data Encryp- [289] L. Cailleux, C. Bonatti, Securing Header Fields with S/MIME, RFC 7508 Request tion Algorithm (TMOVS): Requirements and Procedures, vol. 800, NIST Special for Comments, RFC Editor, 2015, http://dx.doi.org/10.17487/RFC7508, URL Publication, 2012, p. 20. https://www.rfc-editor.org/info/rfc7508. [307] M. Dworkin, NIST Special Publication 800-38F December 2012, vol. 800, NIST [290] J. Solinas, R. Housley, Suite B in Secure/Multipurpose Internet Mail Extensions Special Publication, 2012, p. 38F. (S/MIME), RFC 6318 Request for Comments, RFC Editor, 2011, http://dx.doi. [308] NCC Group, Post-Quantum Cryptography Overview, Tech. Rep., NCC org/10.17487/RFC6318, URL https://www.rfc-editor.org/info/rfc6318. Group, 2016, URL https://www.nccgroup.com/media/swdbffg3/_ncc-group- [291] J. Schaad, S/MIME Capabilities for Public Key Definitions, RFC 6664 Request cryptographic-services.pdf, Section: Post-quantum algorithm overview. States for Comments, RFC Editor, 2012, http://dx.doi.org/10.17487/RFC6664, URL that current symmetric ciphers with 256-bit keys, such as AES-256 and https://www.rfc-editor.org/info/rfc6664. ChaCha20, are believed to be quantum-resistant. [292] R. Housley, Object Identifier Registry for the S/MIME Mail Security Working [309] G. Paul, S. Maitra, RC4 Stream Cipher and Its Variants, CRC Press, 2011. Group, RFC 7107 Request for Comments, RFC Editor, 2014, http://dx.doi.org/ [310] P. Ekdahl, T. Johansson, A new version of the stream cipher SNOW, in: Selected 10.17487/RFC7107, URL https://www.rfc-editor.org/info/rfc7107. Areas in Cryptography: 9th Annual International Workshop, SAC 2002 St. [293] S. Santesson, X.509 Certificate Extension for Secure/Multipurpose Internet Mail John’s, Newfoundland, Canada, August 15–16, 2002 Revised Papers 9, Springer, Extensions (S/MIME) Capabilities, RFC 4262 Request for Comments, RFC Editor, 2003, pp. 47–61. 2005, http://dx.doi.org/10.17487/RFC4262, URL https://www.rfc-editor.org/ [311] C. De Canniere, B. Preneel, Trivium, in: New Stream Cipher Designs: The info/rfc4262. [294] A. Melnikov, Authentication-Results Registration for S/MIME Signature Verifi- ESTREAM Finalists, Springer, 2008, pp. 244–266. cation, RFC 7281 Request for Comments, RFC Editor, 2014, http://dx.doi.org/ [312] L. Jiao, Y. Hao, D. Feng, Stream cipher designs: a review, Sci. China Inf. Sci. 10.17487/RFC7281, URL https://www.rfc-editor.org/info/rfc7281. 63 (2020) 1–25. [295] J. Peterson, S/MIME Advanced Encryption Standard (AES) Requirement for the [313] M. Hell, T. Johansson, W. Meier, J. Sönnerup, H. Yoshida, An AEAD variant Session Initiation Protocol (SIP), RFC 3853 Request for Comments, RFC Editor, of the grain stream cipher, in: International Conference on Codes, Cryptology, 2004, http://dx.doi.org/10.17487/RFC3853, URL https://www.rfc-editor.org/ and Information Security, Springer, 2019, pp. 55–71. info/rfc3853. 53