coleleavitt/opaque-lattice
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
12e09718d296379595d6d291974187cad752f2b7
opaque-lattice/papers_txt/Assessing-the-quantum-readiness-of-cryptographic-standa_2026_Computer-Standa.txt
Cole Leavitt dfa968ec7d initial
2026-01-06 12:49:26 -07:00

4716 lines
513 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
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
Reference in New Issue View Git Blame Copy Permalink