(AGENPARL) – Mon 29 September 2025 Mercati, infrastrutture, sistemi di pagamento
(Markets, Infrastructures, Payment Systems)
A practical implementation of a quantum-safe PKI
in a payment systems environment
Number
September 2025
by Luca Buccella and Stefano Massi
Mercati, infrastrutture, sistemi di pagamento
(Markets, Infrastructures, Payment Systems)
A practical implementation of a quantum-safe PKI
in a payment systems environment
by Luca Buccella and Stefano Massi
Number 64 – September 2025
The papers published in the ‘Markets, Infrastructures, Payment Systems’ series provide
information and analysis on aspects regarding the institutional duties of the Bank of
Italy in relation to the monitoring of financial markets and payment systems and the
development and management of the corresponding infrastructures in order to foster
a better understanding of these issues and stimulate discussion among institutions,
economic actors and citizens.
The views expressed in the papers are those of the authors and do not necessarily reflect
those of the Bank of Italy.
The series is available online at http://www.bancaditalia.it.
Printed copies can be requested from the Paolo Baffi Library:
Editorial Board: Stefano Siviero, Paolo Del Giovane, Massimo Doria,
Giuseppe Zingrillo, Paolo Libri, Guerino Ardizzi, Paolo Bramini, Francesco Columba,
Luca Filidi, Tiziana Pietraforte, Alfonso Puorro, Antonio Sparacino.
Secretariat: Yi Teresa Wu.
ISSN 2724-6418 (online)
ISSN 2724-640X (print)
Banca d’Italia
Via Nazionale, 91 – 00184 Rome – Italy
Designed and printing by the Printing and Publishing Division of the Bank of Italy
A PRACTICAL IMPLEMENTATION
OF A QUANTUM-SAFE PKI
IN A PAYMENT SYSTEMS ENVIRONMENT
by Luca Buccella* and Stefano Massi*
Abstract
The security of the digital certification services provided by Public Key Infrastructures (PKIs) is
essential to ensure the proper functioning of payment systems and financial market infrastructures.
This work aims to identify the main challenges and critical issues involved in the transition towards
a quantum-resistant PKI architecture, capable of withstanding attacks carried out by quantum
computers with sufficient computational capabilities to break into the classical cryptographic
schemes currently used. To this end, a Proof of Concept (PoC) is presented, based on quantumsafe cryptographic algorithms designed to ensure the long-term security and resilience of payment
systems in a post-quantum era.
The results of the PoC indicate that, although the performance of the new algorithms proved
satisfactory and may facilitate the transition process, current PKI software solutions have not yet
achieved full compatibility with the quantum-safe algorithms available on the market. Further efforts
are therefore required to adapt existing solutions to the emerging standards, in order to promote the
widespread adoption of robust cryptographic algorithms.
Keywords: Quantum computing, Quantum security, PKI, Target Services.
Sintesi
La sicurezza dei servizi di certificazione digitale erogati dalle Public Key Infrastructure (PKI) è
fondamentale per garantire il corretto funzionamento dei sistemi di pagamento e delle infrastrutture
dei mercati finanziari.
L’obiettivo del lavoro è identificare le principali sfide e criticità nella transizione verso un’architettura
PKI quantum-resistant, in grado di resistere ad attacchi condotti mediante calcolatori quantistici
dotati di capacità computazionali sufficienti a violare gli schemi crittografici classici attualmente in
uso. Viene a tal fine presentata una Proof of Concept (PoC) di una PKI basata su algoritmi crittografici
quantum-safe, disegnati per garantire la sicurezza e la resilienza a lungo termine dei sistemi di
pagamento in un’era post quantistica.
I risultati della PoC indicano che, sebbene le prestazioni dei nuovi algoritmi si siano dimostrati
soddisfacenti e potranno quindi facilitare il processo di transizione, le soluzioni software per PKI
non hanno ancora raggiunto un livello di compatibilità pienamente soddisfacente con gli algoritmi
quantum safe al momento disponibili sul mercato. È pertanto necessario intensificare gli sforzi per
l’adeguamento delle soluzioni ai nuovi standard, al fine di promuovere la pervasiva adozione di
algoritmi crittografici robusti.
Banca d’Italia, IT Development Directorate.
CONTENTS
1. Introduction
2. Quantum Threats and Quantum Safe Cryptographic Algorithms
Threats
Risk mitigation
Algorithms, size and efficiency
3. Public Key Infrastructures and Payment Systems
Description of certificates usage in ESMIG
Certificates automation with ACME protocol in T2
PKI Security Threats
4. The Proof-of-Concept conducted in the Bank of Italy
Hybrid Certificates
Certification Authorities
Testing the use of certificates
5. Performance Tests
Dimensions
Execution time
6. Conclusions
Crypto-agility of payment systems
7. Developments in the short and medium term
8. Definitions
Index of figures
Bibliography
1. Introduction1
European payment system infrastructures such as TARGET2 (T2), TARGET2-Securities
(T2S), and TARGET Instant Payment Settlement (TIPS) rely on advanced cryptographic mechanisms
as the foundation of their IT security. These mechanisms are primarily built upon secure
communication protocols, which are currently considered robust. However, the advent of quantum
technologies – capable of implementing processors with dramatically increased computational power
– poses a significant threat to their long-term security.
T2, T2S, and TIPS are core components of the European financial infrastructure, supporting
the processing and settlement of financial transactions across the continent. Encryption is central to
safeguarding sensitive information and preventing unauthorized access. These platforms
predominantly employ public key infrastructures (PKIs) for authentication and symmetric
cryptography for data confidentiality during transmission.
TARGET2-Securities (T2S) leverages end-to-end encryption and implements the Data
Exchange Protocol (DEP), which offers advanced mechanisms to secure communication between
settlement systems and participants. DEP ensures that data are encrypted and accessible only to
authorized recipients, effectively mitigating the risks of eavesdropping and tampering.
TARGET2 (T2) employs protocols such as Transport Layer Security (TLS) to protect
communications between central banks and participants. It also utilizes digital signatures based on
RSA and SHA-256 algorithms to ensure message integrity and data security during transmission.
Additionally, T2 incorporates DEP to further enhance confidentiality by ensuring that encrypted data
can only be accessed by designated entities.
TARGET Instant Payment Settlement (TIPS) relies on advanced cryptographic algorithms such
as AES-256 for symmetric encryption, enabling secure real-time transaction processing. This ensures
that exchanged data remain protected against unauthorized access and manipulation.
The adoption of these cryptographic technologies is essential for maintaining the trust, integrity,
and stability of the European financial system. However, the emergence of quantum computing
technologies necessitates the evolution of existing cryptographic protocols to preserve high security
standards in a rapidly changing threat landscape.
Numerous studies have highlighted the vulnerabilities of conventional cryptographic
algorithms in the face of quantum computing and have proposed strategies to mitigate these risks in
operational settings. In this paper, we adopt a pragmatic approach by implementing a Public Key
Infrastructure (PKI) that supports quantum-safe algorithms. We evaluate its practical applicability
through a real-world proof-of-concept (PoC), assessing both effectiveness and performance.
Our PoC reveals that compatibility with quantum-safe algorithms remains limited in most
current software environments, with the notable exception of hybrid certificates – which are available
but not yet widely or properly utilized. Nonetheless, the performance metrics of quantum-safe
algorithms indicate a high degree of computational efficiency. Among the algorithms analyzed,
Dilithium emerges as the most balanced solution, offering an optimal trade-off between memory
usage and computational cost.
The remainder of this paper is structured as follows. Section 2 introduces the quantum threat
landscape and provides an overview of quantum-safe cryptographic algorithms and their evolution.
We are grateful to Andrea Billet, Alessandro Casale, Damiano Diego De Felice, Simone Dutto, Sergio Polese
and Giordano Santilli of the Italian National Cybersecurity Agency.
Section 3 discusses the role of PKIs in payment systems. Section 4 presents the implementation and
architecture of the PoC. Section 5 details the performance evaluation results. Section 6 draws the
main conclusions. Section 7 outlines potential directions for further development, and Section 8
provides a glossary of technical definitions.
2. Quantum Threats and Quantum Safe Cryptographic Algorithms
From a technical standpoint, the security of communication protocols – specifically with regard
to confidentiality and data integrity – relies fundamentally on three core functionalities: encryption,
key exchange, and digital signatures. In particular, asymmetric cryptographic schemes, in which two
parties communicate using a pair of keys (a public key and a corresponding private key), derive their
security from the computational hardness of mathematical problems such as integer factorization and
the discrete logarithm problem.
These problems are considered intractable with classical computing, as no known algorithms
can solve them efficiently – i.e., in polynomial time – on conventional hardware. However, this
security assumption is fundamentally challenged by the advent of quantum computing. Quantum
computers, which leverage the quantum mechanical properties of matter for data representation and
computation, are capable of executing algorithms that outperform classical approaches for specific
problem classes.
A notable example is Shor’s algorithm, which can efficiently factor large integers and compute
discrete logarithms in polynomial time [1], thereby undermining the foundational security
assumptions of widely used asymmetric cryptographic schemes such as RSA and ECC.
Consequently, any encrypted communication that relies on these schemes could be decrypted if
intercepted and later processed by a sufficiently powerful quantum computer.
Similarly, symmetric encryption is also affected by quantum computing, albeit to a lesser
extent. Grover’s algorithm offers a quadratic speed-up for searching an unstructured space, which
effectively reduces the security strength of symmetric key cryptosystems by half (e.g., AES-256
would provide a quantum equivalent of 128-bit security).
Recognizing these threats, the National Institute of Standards and Technology (NIST)
highlighted as early as 2016 [2] that most commonly used cryptographic mechanisms – including
those for encryption, key exchange, and digital signatures – will no longer be considered secure once
large-scale quantum computers become available. This recognition has since led to a global initiative
to develop and standardize post-quantum cryptography capable of resisting attacks from quantum
adversaries.
Table 1 – Cryptographic algorithms and impacts of Quantum Computing
Cryptographic algorithm
SHA-2, SHA-3
ECDSA, ECDH
(ELLIPTIC CURVE
CRYPTOGRAPHY)
(FINITE FIELD
CRYPTOGRAPHY)
Purpose
Impacts of Quantum
Computing on a large scale
Symmetric key
Encryption
Larger key sizes needed
Hash functions
Larger output needed
Public key
Signature
Key establishment
No longer secure
Public key
Signature
Key exchange
No longer secure
Public key
Signature
Key exchange
No longer secure
Given the progress made in recent years in the area of research on quantum computers, there has been
an impetus for studies in the area of so-called Post Quantum Cryptography (PQC), in order to identify
algorithms that are robust and resistant, and to this end, NIST has initiated a process of evaluating
and selecting new algorithms, defined as quantum safe or quantum resistant, with the aim of
standardizing their use.
To normalize the concept of security and define a yardstick to compare the robustness of
cryptographic algorithms, including quantum safe ones, NIST defined five levels of security [3].
Table 2 – Description of NIST security levels [4]
Level
Security Description
At least as hard to break as AES128 (exhaustive key search)
At least as hard to break as SHA256 (collision search)
At least as hard to break as AES192 (exhaustive key search)
At least as hard to break as SHA384 (collision search)
At least as hard to break as AES256 (exhaustive key search)
2.1. Threats
One of the significant threats posed by the advent of quantum computers is the so-called harvest
now, decrypt later strategy. Also known as store now, decrypt later (see Figure 1), this approach
involves the acquisition and long-term storage of encrypted data that is currently unreadable, with the
anticipation that future advancements in decryption techniques will render it accessible.
Figure 1 – Harvest now, decrypt later
This threat manifests in two primary forms: Grover’s algorithm and Shor’s algorithm.
Grover’s algorithm [4] significantly reduces the time required to attack symmetric encryption
systems, thereby lowering their security level. On the other hand, Shor’s algorithm compromises the
security of modern asymmetric cryptographic algorithms, such as the factoring of large prime
numbers and the discrete logarithm problem, by reducing the computational complexity from
exponential to polynomial time. This reduction in complexity simplifies the decryption of messages
encrypted with these asymmetric schemes.
As described by Grover [5] and Brassard [6], substantial performance improvements can be
achieved in solving problems related to ‘Searching’ and ‘Collision Finding and Element Distinctness’
respectively:
𝒪(√𝑛) for search algorithms,2 where n is the size of admissible inputs; classical
algorithms take a time of 𝒪(𝑛);
𝒪( √𝑛) for collision search algorithms, where n is the domain size.
Table 3 – Asymptotic notation for evaluating algorithms
Space
Grover
𝒪(√𝑛)
𝒪(log 𝑛)
Brassard et al.
𝒪( √𝑛)
𝒪( √𝑛)
This leads to a significant reduction in the security level of current symmetric encryption
algorithms. The impact of quantum computing on these algorithms is depicted in the table below.
Table 4 – Robustness comparison between classical algorithms
SECURITY BITS
128 (KEY-SEARCH)
128 (COLLISIONS)
192 (KEY SEARCH)
192 (COLLISIONS)
SYMMETRICKEY
2TDEA
3TDEA
AES -128
HASHING
FUNCTION
INTEGER
FACTORIZATION
(i.e. RSA)
k=1024
k=2048
k=3072
DISCRETE
LOGARITHM
(i.e. DH)
L=1024, N=160
L=2048, N=224
L=3072, N=256
ELLIPTIC
CURVE
k=7680
L=7680, N=384
f=384-511
k=15360
L=15360, N=511
f=512+
(I.E. X25519)
f=160-2233
f=224-2554
f=256-383
SHA3-256
AES -192
SHA3-384
AES -256
Table 5 – Robustness scaling using quantum computer
SECURITY BITS
SYMMETRIC-KEY
128 (KEY SEARCH)
AES-128
HASHING FUNCTION
128 (COLLISIONS)
192 (KEY SEARCH)
SHA3-256
AES-192
192 (COLLISIONS)
SHA3-384
QUBIT SECURITY
𝒪 ( 2 ) = 𝒪(264 )
𝒪( √2256 ) ≈ 𝒪(285 )
𝒪 (√2 ) = 𝒪(296 )
𝒪 ( √2384 ) = 𝒪(2128 )
𝒪 (√2256 ) = 𝒪(2128 )
AES-256
2.2. Risk mitigation
To protect communications, such as those on the Internet that use ‘secure’ connections via the
HTTPS – TLS protocol, it is possible to maintain the same level of security by doubling the length of
the key used, thereby increasing the robustness of the symmetric encryption algorithm. However, it
should be noted that the preparatory phase of exchanging the aforementioned encryption keys remains
See Definitions section.
Unsecure.
Security not guaranteed in the long term.
vulnerable (see Figure 2), whether using typical asymmetric encryption such as RSA or the DiffieHellman5, which is a key exchange algorithm that still employs asymmetric encryption.
Therefore, post-quantitative algorithms must also be considered in this context.
Figure 2 – TSL protocol and its vulnerabilities
Several mathematical techniques have been proposed to build quantum-secure cryptosystems,
including:
hash functions and zero-knowledge tests;
error-corrected codes;
lattice-based cryptography (including Learning with Errors – LWE – and NTRU)6;
multivariate equations;
isogenies of supersingular elliptic curves.
Indeed, the new algorithms, standardized by NIST, relate to lattice and hash function problems.
The aim of this paper is to examine and evaluate some of these new algorithms, specifically
designed to withstand quantum computers. In particular, the key signing and encapsulation algorithms
chosen for study are all lattice-based algorithms:
Dilithium signature scheme (in versions 3 and 5);
FALCON signature scheme (in versions 512 and 1024);
KYBER key encapsulation mechanism (in versions 768 and 1024);
SPHINCS+ signature scheme, based on hash functions (will only be mentioned but not
covered in detail in this document).
On August 13, 2024, NIST standardized the first three post-Quantum algorithms [7]:
FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard: ML-KEM is the
name given to the standardized algorithm derived from CRYSTALS-KYBER [8];
FIPS 204, Module-Lattice-Based Digital Signature Standard: ML-DSA is a digital signature
scheme derived from the CRYSTALS-DILITHIUM algorithm, with its three main functions:
ML-DSA.KeyGen, ML-DSA.Sign (Algorithm 2) and ML-DSA.Verify [9];
FIPS 205, Stateless Hash-Based Digital Signature Standard: SLH-DSA based on version 3.1
of the SPHINCS+ specification [10];
FIPS 206, the future schema FN-DSA derived from FALCON.
It should be noted that the TLS protocol covers a multitude of different cipher suites, which define the algorithms used
for key exchange and subsequent data encryption.
See Definitions section.
The PoC described in this paper was performed before the standardization of algorithms by
NIST, so we will also use the Kyber, Dilithium and Sphincs+ nomenclature.
2.3. Algorithms, size and efficiency
The implementation of quantum-safe cryptographic algorithms is essential to ensure the
security of digital communications in the face of emerging quantum technologies. This section
provides an overview of the key algorithms considered in this study, focusing on their size and
efficiency.
In the following sections, we will briefly present the winning algorithms of NIST competition
and verify their performance with laboratory tests, as anticipated by Vidaković/Miličević [11, 12].
We will compare the various cryptographic functions (Key pair generation, signature, verify, etc.) of
the various quantum-safe algorithms, also comparing them with those currently in common use in
digital signature or encryption scenarios.
The Dilithium signature scheme is a lattice-based cryptographic algorithm (based on the RingLWE, Ring Learning with Errors problem) designed to provide robust security against quantum
attacks. As described in [13], Dilithium gives an option of producing either deterministic or
randomized signatures. In the deterministic approach, the randomness used in the signing process is
derived from a deterministic function (e.g., a hash) of the message and the secret key. In contrast, the
randomized version uses a random seed making each signature unique even for the same message
and secret key. The deterministic version is simpler to implement and faster but is more susceptible
to attacks that exploit the deterministic nature of signature generation, such as fault attacks (especially
in hardware implementations). The randomized version offers better resistance against fault attacks
and other attacks that leverage the deterministic nature of the deterministic version, but it can be more
complex to implement.
Leaving aside the two implementation versions just described, the Dilithium algorithm is
available in three different security versions, Dilithium2, Dilithium3 and Dilithium5, each offering
varying levels of security and performance. The algorithm’s efficiency is measured in terms of key
generation, signature creation, and verification times, as well as the size of the keys and signatures
produced (see Figure 3).
This pattern was used by NIST to standardize ML-DSA, a digital signature scheme consisting
of three algorithms: ML-DSA.KeyGen, ML-DSA.Sign and ML-DSA.Verify.
Table 6 – Key and Signature Dimensions – Dilithium
Dilithium 2
Dilithium 3
Dilithium 5
NIST Security Level
Public Key Size (bytes)
Private Key Size (bytes)
Signature Size (bytes)
6000
Public Key Size Private Key Size Signature Size
(bytes)
(bytes)
(bytes)
rsa 2048
Dilithium2
Dilithium 3
Dilithium 5
Figure 3 – Key and Signature Size Chart – Dilithium
The main advantages of this algorithm are:
fast and not memory-hungry algorithm, compared to hash-based schemes such as Sphincs+;
simple implementation; does not require complex calculations such as Gaussian sampling;
it’s easy to detect implementation errors.
On the other hand, the size of the signature and public key is approximately 2.3 times larger
(privateKey + signature) than the Falcon algorithm.
Falcon (‘FAst-Fourier Lattice-based COmpact signatures over NTRU’) is another lattice-based
signature scheme known for its compact key and signature sizes (see Figure 4). It is available in two
versions, Falcon 512 and Falcon 1024, which differ in their security levels and computational
requirements. Falcon’s efficiency is evaluated based on the same criteria as Dilithium, with a
particular emphasis on its suitability for resource-constrained environments.
Table 7 – Key size and signature – Falcon
FALCON-512
FALCON-1024
NIST Security Level
Public Key Size (bytes)
Private Key Size (bytes)
Signature Size (bytes)
Maximum Signature Size (bytes)
FALCON may have variable signature sizes.
2500
Public Key Size
(bytes)
rsa 2048
Private Key Size
(bytes)
Falcon-512
Signature Size
(bytes)
Falcon-1024
Figure 4 – Key and Signature Size Chart – Falcon
The main advantages of this algorithm are:
more efficient in terms of bandwidth;
fast in signature verification;
On the other hand, the disadvantages are:
difficult to detect implementation errors;
complex key creation and signing process (floating point arithmetic);
not secure against side-channel attacks (masking).
Let us now introduce another algorithm that emerged from the NIST competition: Sphincs+.
This is a digital signature algorithm designed to withstand attacks from quantum computers based on
a different technology than Dilithium and Falcon: hash and not lattice; as Vidaković/Miličević
elaborated in detail [11, 14], it turns out to be the most computationally demanding signature
algorithm: the signatures are large (although the keys are the smallest). Although it is less efficient,
compared to others that similarly implement digital signature schemes, it has nevertheless been
standardized by NIST. The main reason is the mitigation of the risks associated with the use of lattice
technology for signature schemes: should this technology be compromised, there would be no
alternative; in addition, of course, to the low space requirements for key storage, which is
advantageous in specific contexts.
This algorithm was used by NIST to standardize the Stateless Hash-Based Digital Signature
Standard ‘SLH-DSA’, based on version 3.1 of the SPHINCS+ specification.
Kyber is a lattice-based key encapsulation mechanism (KEM)8 designed to provide secure key
exchange in a quantum-safe manner. This scheme (see Figure 5) is used to securely establish a shared
secret between two parties that cannot be deciphered by a malicious attacker. It is an asymmetric
encryption mechanism based on the learning-with-error (LWE) problem in lattice theory, which is
assumed to be NP-hard. It is available in three versions, Kyber 512, Kyber 768 and Kyber 1024, each
offering various levels of security and performance. Kyber’s efficiency is assessed based on key
See Definitions section for more details – KEM (key encapsulation mechanism).
generation, encapsulation, and decapsulation times, as well as the size of the keys and ciphertexts
produced.
This algorithm has been used by NIST to standardize Module-Lattice-Based KeyEncapsulation Mechanism Standard – ML-KEM – derived from CRYSTALS-KYBER specifications.
KEYGEN requires no input and
generates a private key and a public
ENCAPSULATE takes a public key
as input and produces a cipher text
and a shared secret as output;
DECAPSULATE takes a cipher text
and a private key as input and
produces a shared secret.
Figure 5 – Overview of the KEM protocol – Source: [15]
Compared to the traditional Diffie-Hellman key exchange mechanism, in its version on elliptic
curves (which is not resistant to quantum attacks), Kyber is about 2-3 times slower and requires a
data overhead of about 70 times [16].
Table 8 – Key size and cipher text – Kyber
KYBER512
KYBER768
KYBER1024
NIST Security Level
Public Key Size (bytes)
Private Key Size (bytes)
Ciphertext Size
Shared Secret Size
Kyber-512 aims for security roughly equivalent to AES-128, Kyber-768 equivalent to AES192 and Kyber-1024 equivalent to AES-256 [16].
3. Public Key Infrastructures and Payment Systems
Public Key Infrastructures (PKIs) play a crucial role in ensuring the security and integrity of
payment systems, such as T2, T2 Securities and TIPS. They provide a framework for managing digital
certificates and public-key encryption, which are essential for secure communication and
authentication in financial transactions. This section delves into the application of PKIs in payment
systems, highlighting their significance and the challenges they face in the context of quantum
computing.
In this section we will focus on the Eurosystem Single Market Infrastructure Gateway
(ESMIG) and describe how PKI services are implemented [17].
3.1. Description of certificates usage in ESMIG
The Eurosystem Single Market Infrastructure Gateway (ESMIG) is a critical component of the
European financial infrastructure, facilitating secure and efficient communication between market
participants and the Eurosystem.
The ESMIG infrastructure provides a set of features shared among all the TARGET Services,
common components and applications beyond representing a single point of contact with the external
networks [18]. These features belong to two main areas:
Security, for example authentication of the sender and authorisation against a Closed
Group of Users.
Message management, for example message technical validation and forwarding.
The ESMIG provides business continuity measures (e.g. multiple sites, path diversification,
etc.) and PKI services.
Digital Certificates, issued by PKI services, are used both by individuals, interacting with
ESMIG in U2A mode, and applications, interacting with ESMIG in A2A mode.
The authentication of the “technical sender” (that is, the actor submitting an A2A or U2A
request to TARGET services) is performed at network infrastructure level and is based on the
certificate used by the actor to establish the technical connection with the network infrastructure itself.
In case of successful authentication of the technical sender, the TARGET Services, common
components or applications get the certificate Distinguished Name (DN) of the technical sender.
The A2A interaction is achieved through two different protocols: Data Exchange Protocol
(DEP), used by the TARGET Services (excluding TIPS), and the Message Exchange Processing for
TIPS (MEPT).
In order to guarantee the non-repudiation of emission, A2A messages are signed (see Figure 6)
by the Network Service Provider (NSP)’s gateways using private keys stored in a HSM and signed
by the CA. The NSP’s network gateways of the receiver must check the validity of the certificate and
verify the signature, using the public key certificate of the sender.
Figure 6 – Message signature
In the ESMIG environment, several types of certificates are used:
A2A certificates used for digital signature, with the non-repudiation bit set in the ‘Key
usage’ extension.
U2A certificates used for digital signature and authentication, with the Non-Repudiation
and the Digital Signature bit set in the ‘Key usage’ extension.
TLS certificates for traffic data flow protection.
In case of compromised certificate, the NSP ensures its immediate revocation. Revocation
information is published in the Certificate Revocation List (CRL) and made available in the OCSP
services.
As described above, digital certificates issued by the PKI are used to enhance the security of
payment systems in several ways:
ensure message integrity (digital signature and non-repudiation);
perform authentication of users (U2A) and applications (A2A);
ensure confidentiality of data across networks (TLS protocol).
In our PoC we will explore all three kinds of certificate usage: digital signature, authentication
and cryptography.
3.2. Certificates automation with ACME protocol in T2
In the TARGET2 (T2) payment system, the Automated Certificate Management Environment
(ACME – RFC 8555) protocol is employed to streamline the issuance and renewal of digital
certificates. ACME automates the process of obtaining and managing certificates, reducing the
administrative burden on system operators, and enhancing the overall security of the T2
infrastructure. By leveraging ACME, T2 can ensure that certificates are always up-to-date and
compliant with the latest security standard. This Protocol brings the following improvements:
Efficiency: Automated management implies a reduction in wasted time and resources attached.
Improved Security: Automation improves security, ensuring well-issued and managed
certificates, with the opportunity to introduce stronger algorithms and big key lengths in a simple
Fewer Errors: Human errors will be avoided when automation will be integrated into place.
For example, there are no chances for several human errors, even by a man attacker, during the manual
issuance of certificates.
Compliance: Automation can become a way to systematically issue and manage certificates in
accordance with the latest standards, regulations, and best practices.
Scalability: New server or application certificates may easily be issued and rolled out in parallel
with the organisation growing in size.
Cost Reduction: Reduced manual intervention will ensure less cost and less time spent on
certificate management.
3.3. PKI Security Threats
Quantum weakness is not the only security threat with PKIs. Indeed, one major issue of PKIs
is that most of them are built on a centralised model (Certification Authority, CA), which is a single
point of failure. The revocation of keys (certificates) relies on a centralised list (Certificate Revocation
Lists, CRL). Certificates are issued by CAs which are assumed to be fully trusted organisations in the
PKI system. CAs are expected to operate according to some rules which are announced as Certificate
Policy (CP) and Certificate Practice Statement (CPS) documents [19]. Certificate revocation and
validation processes can have serious security issues. Certificate owners must rely on CAs which
have the full responsibility to revoke the certificates and give accurate revocation services and
furthermore, many clients, including web browsers, rarely check whether the certificates are revoked
or not [20].
The blockchain technology is being widely adopted in trade and finance systems [21].
Blockchain was originally designed to support the implementation of Bitcoin, but now this
technology has been successfully applied to many sectors; in the financial area, blockchain
technology has great potential due to its decentralisation, safety, and traceability nature.
Moreover, Blockchain technology has recently been proposed by many authors for
decentralised key management in the context of PKIs [22]. Instead of relying on trusted centralised
validation authorities, the confirmation and revocation of keys is distributed over a multitude of
participants. This paradigm may successfully address the above-described security threats.
However, blockchains are affected by other security issues; managing the replacement of
cryptographic primitives through crypto-agility9 may not be very effective for payment systems [23].
In Bitcoin, for example, replacing the ECDSA digital signature scheme with a post-quantum scheme
would almost certainly involve making hard forks10 in the transaction chain [24].
In this study, we will focus only on traditional PKIs, as blockchain ones should still be
considered as experimental.
Crypto-Agility is the ability of a security system to switch from a cryptography method to another and is focused on
visibility and the dynamic movement of cryptography resources of an organization. A crypto-agile company is able to
substitute obsolete cryptography resources without significant interruptions to the infrastructure.
A hard fork, as it relates to blockchain technology, is a radical change to a network’s protocol that makes previously
invalid blocks and transactions valid, or vice-versa. A hard fork requires all nodes or users to upgrade to the latest version
of the protocol software.
4. The Proof-of-Concept conducted in the Bank of Italy
The Bank of Italy is a Qualified Trusted Service Provider (QTSP) under the eIDAS Regulation
for the issuance of qualified electronic signature certificates. It is registered in the list of Qualified
Service Providers in Italy, maintained by AgID11 and valid at European level. The certificates are
issued to employees of the Bank or to representatives of institutional stakeholders and are used
exclusively in relations with the Bank. The Bank also issues ‘auxiliary’ certificates (authentication
and encryption, TLS, etc.). The Bank’s PKI infrastructure is entirely on-premises.
In the test environment of the PKI infrastructure, a Proof-of-Concept (PoC) was realised
consisting of various Certification Authorities instances hosted on a virtual machine equipped with
the software packages shown in the following table.
Table 9 – Software components used in the PoC
Component
CERTIFICATION AUTHORITY
Software
EJBCA Community Edition, v. 8
APPLICATION SERVER
Operating System: Red Hat Enterprise Linux v. 8.8
Amount of RAM: 4 GB
jboss-eap-7.4
COMPILER TOOL
CRYPTOGRAPHIC API
Bouncy Castle library v1.73
VIRTUAL MACHINE
JAVA VIRTUAL MACHINE
The Certification Authority software was customised appropriately in order to also support
hybrid certificates, as detailed in the next section.
4.1. Hybrid Certificates
The term hybrid refers to various methods of combining classical and post-quantum (PQ)
cryptographic algorithms, particularly in the context of digital certificates. The main hybridization
strategies can be classified into three categories: composite, multiple (or chameleon) and “real”
hybrid.
In this scheme, two public keys (one classical, such as RSA, and one post-quantum) belonging
to the subscriber are combined and included in a single certificate. This ensures that as long as at least
one of the cryptographic algorithms remains secure (i.e., unbroken), the overall security is preserved.
However, this approach requires that the software processing the certificates be capable of
understanding and handling the new post-quantum algorithms, making it unsuitable for transitional
environments or legacy systems.
The Agenzia per l’Italia Digitale – Agency for Digital Italy (AgID) – is the technical agency of the Presidency of the
Council of Ministers that guarantees the achievement of the objectives of the Italian digital agenda, coordinating all Italian
public administrations.
This approach uses two distinct but closely linked certificates, one based on a classical
algorithm (e.g., RSA) and the other on a PQ algorithm. In a typical TLS connection, for instance, two
separate authentication phases would occur: one using the legacy certificate and one using the postquantum certificate. Although conceptually elegant and flexible, this solution introduces additional
operational complexity and may impact performance and connection management.
In the PoC, so-called ‘real hybrid’ certificates were used, i.e. certificates with two public keys
(one traditional and one quantum-safe) appropriately defined within them (see Figure 7). There are
currently no standards for this type of certificate, only draft implementations. The IETF (Internet
Engineering Task Force) versions were evaluated in the study [25] and the Technical University of
Darmstadt (CROSSINGTUD) [26] which exploits the hybrid using extension approach.
Figure 7 – Representation and comparison of different types of certificates (Source: Sectigo)
➢ IETF coding
In the IETF implementation [25] some non-critical attributes were added in order to define the
In the example (see Figure 8), the representation of a certificate in ASN.1 encoding is shown,
in which the three attributes with reference to the Dilithium5 scheme is highlighted.
Figure 8 – ASN.1 representation of the certificate with evidence on PQ attributes – IETF implementation
➢ CROSSINGTUD coding
In the CROSSINGTUD implementation [26] the non-critical attributes defining the algorithm
In the example (see Figure 9), a certificate displayed in its ASN.1 encoding shows the 2
attributed with reference to the Dilithium3 for the secondary public key and Dilithium5 scheme for
its signature by the CA.
Figure 9 – ASN.1 representation of the certificate with evidence on PQ attributes – Crossingtud implementation
4.2. Certification Authorities
In the Proof-of-Concept (PoC) conducted by the Bank of Italy, several Certification Authority
(CAs) instances were created, including quantum-ready versions. Due to the unavailability of
Hardware Secure Modules (HSMs) implementing post-quantum algorithms12 on the European market
at the time of the tests, software tokens were utilized for storing the root keys of the CAs and for
signing the Certificate Revocation Lists (CRLs). The Online Certificate Status Protocol (OCSP)
service was not included within the scope of the PoC, as the only impacted aspects would have been
the signing times of the individual OCSP responses, a topic discussed in detail in the specific section
comparing execution times.
As can be seen from the table below, the following CAs were created:
Table 10 – CA generated in the PoC
ROOTCA_RSA
ROOTCA_HYBRID_RSA_DIL5
ROOTCA_HYBRID2_RSA_DIL5
ROOTCA_DILITHIUM5
Description
Certification Authority with classic key algorithm RSA-4096
Hybrid Certification Authority, according to the crossingtud formalism, with
primary key RSA-4096 and secondary key Dilithium5
Hybrid Certification Authority, according to IETF formalism, with primary key
RSA-4096 and secondary key Dilithium5
Certification Authority with quantum-safe key algorithm Dilithium5.
In the execution of the Proof of Concept (PoC), a variety of sophisticated tools were employed;
it was necessary to use third-party libraries and create ad hoc tools for the concrete use of quantum
At the time the tests were carried out, some manufacturers had already produced devices with support for post-quantum
algorithms (e.g. Thales Luna T-Series), but they were not yet available on the European market or did not yet have the
required certifications for use in qualified production environments.
safe algorithms in the various phases of the certificate lifecycle and in typical usage scenarios. The
use of Bouncy Castle13 libraries was mandatory, as they are the only ones that implement the
specifications of the new post-quantum algorithms.
During the PoC, various types of certificates were issued according to possible combinations
of algorithms and keys (hybrid or Quantum-safe for each CA); in addition, for simplicity, all
certificates were configured with Key Usage extensions (Digital Signature, Non-repudiation, Key
encipherment) and Extended Key Usage (Client Authentication, Email protection).
4.3. Testing the use of certificates
The evaluation of certificate usage was conducted through a series of rigorous tests designed
to assess the functionality and security of the implemented cryptographic algorithms. These tests were
essential in verifying the robustness of the quantum-safe Public Key Infrastructure (PKI) within the
context of the Proof of Concept (PoC). In the following sections, we will describe the tests for using
the certificates produced in commonly used scenarios, such as the encryption of the communication
channel in an SSL connection, digital signature scenarios, both for PAdES and CAdES, and finally
we will report the outcome of the compatibility tests of file encryption with the Kyber algorithm.
The Transport Layer Security (TLS) connection test was performed to ensure the secure
transmission of data between clients and servers. This test involved the establishment of TLS
connections using certificates that incorporated quantum-safe cryptographic algorithms. The primary
objective was to validate the compatibility and performance of these algorithms in real-world
scenarios, ensuring that they could effectively replace classical cryptographic methods without
compromising security or efficiency.
We assumed the use of certificates with a typical web server; for this purpose, one of the most popular
CA certificates created in the PoC as trusted root certificates in the operating system’s certificate
store.
Table 11 – Hybrid certificate with crossingtud coding and DILITHIUM5 secondary key issued by hybrid CA
Certificate
Condition
Issued by
CA_HYBRID_RSA_DIL5
RSA 2048 primary public key
DILITHIUM5 secondary public
SSL server keystore PKCS12 with
only Dilithium5 private key
SSL server keystore PKCS12 with
only RSA private key
https://www.bouncycastle.org/
Result
The SSL connection fails due
to a server-side exception.
The SSL connection is
established correctly, only
showing
backward
compatibility in the use of the
hybrid certificate.
Table 12 – Dilithium5 PQ key certificate, issued by CA Dilithium5
Certificate
Condition
Issued by
DILITHIUM5
DILITHIUM5
primary
public key
SSL server keystore
PKCS12
with Dilithium5
private key
Result
In this test, the application server failed to interpret the
quantum key algorithm and thus raised an exception at startup.
The signature and verification test aimed to evaluate the integrity and authenticity of digital
signatures generated using quantum-safe algorithms. This test involved the creation of digital
signatures for various data sets, followed by the verification of these signatures to ensure their
validity. To set up a signature scenario, we used the tools commonly available on Bank of Italy’s
workstations, such as Acrobat Reader DC, Actalis FileProtector and DSS (Digital Signature
Service)14 for the verification phase.
Table 13 – Signature with Dilithium5 certificate, issued by CA Dilithium5
Certificate
Issued by
CA_ DILITHIUM5
DILITHIUM5
primary public key
Condition
Result
Configuring
digital ID in
PKCS#12 format
The test ended even before reaching the signature application
phase: when attempting to configure a software digital ID in
PKCS#12 format, an exception was raised, showing that the
algorithm used was not recognised as valid
(“The Windows Cryptographic Service Provider reported an
Table 14 – Signature with hybrid certificate with RSA and Dilithium5 keys, issued by CA DILITHIUM5
Certificate
Condition
Issued by
CA_HYBRID_RSA_DIL5
RSA 2048 primary public key
DILITHIUM5 secondary
public key
Configuring digital ID
in PKCS#12 format
Result
In this scenario, the configuration of the certificate
on a PKCS#12 file as a digital ID occurs correctly.
The signing process was successfully completed,
demonstrating backward compatibility of hybrid
certificates in this context.
Table 15 – CAdES Verification with Dilithium5 certificate, issued by CA DILITHIUM5
Certificate
Issued by
CA_ DILITHIUM5
with Dilithium5
primary public key
Condition
Result
Verifying File
signed with PQ
certificate with
standalone tool
The verification application File Protector, while recognising
the cryptographic envelope, was unable to interpret the hashing
algorithm used. As described in [12], SHAKE version 128/25615
can be used as the hashing algorithm in the signature. Each
version is a function of the level of security to be achieved.
DSS – Digital Signature Service .
Verifying File
signed with PQ
certificate with
online tool
Using the DSS web application, we get the message
In this case, the exception raised is on the signing algorithm used,
which turns out not to be supported.
Table 16 – PAdES Verification with Dilithium5 certificate, issued by CA DILITHIUM5
Certificate
Issued by
CA_ DILITHIUM5
Dilithium5 public key
Condition
Validation signed
file with adobe
Result
Using the tools implemented in the Proof of Concept (PoC)
perimeter, we successfully generate PAdES signatures
employing post-quantum algorithms. However, while the PDF
file is recognised by Adobe software, the signature verification
fails. The signature is deemed ‘invalid’ and the signer’s
information is not accurately extracted from the certificate.
Repeating the same exercise with File Protector, the result did
not change.
For this test, a certificate with a Kyber1024 key issued by a classic RSA-4096 CA was used.
Certificate
Issued by
CA_RSA
Kyber1024 public
Condition
A certificate with
a Kyber1024 key
issued by a classic
RSA-4096 CA
Result
To decrypt the encrypted file, we tried installing the PKCS#12
file on a smart card, but each time we got import errors.
Decryption with the customised tool, on the other hand, was
successful.
The following table summarises the various tests carried out during the PoC.
Table 17 – summary of tests performed
CA ISSUER
Certificate
Certificate
primary
secondary
DILITHIUM5
Dilithium5
DILITHIUM5
RSA-2048
DILITHIUM5
DILITHIUM5
RSA4096
HYBRID_RSA_DI
DILITHIUM5
Dilithium5
Test scene
Dilithium5
PAdES
Signing with
Adobe
PAdES
Kyber 1024
encryption
RSA-2048
connection
with hybrid
certificate
Dilithium5
Dilithium5
format
Signing with
Adobe
Signature
verification
with software
verifier
Signature
verification
with web
software
verifier
Signature
verification
with Adobe
Signature
verification
with software
verifier
Dilithium5
Signature
connection
with PQ
certificate
CAdES
Outcome
Digital
configuration failed.
Successful
configuration and
signing.
The verifier did not
recognise
hashing algorithm
CAdES
The tool did not
recognise
algorithm
Dilithium signature.
PAdES
Adobe fails to verify
the signature and
defines it as invalid.
PAdES
The verifier failed to
interpret
certificate
PKCS#12 could not
be imported on
device.
Using the secondary
key in PKCS#12 the
handshake of the
SSL connection does
not complete
With the RSA key,
hybrid
certificate
compatibility
maintained, and the
connection
correctly established
application
server
recognize the key
algorithm
PKCS#12
crashed on start-up.
5. Performance Tests
The following section describes the evaluation of the various algorithms, both from a
computational and memory occupation point of view, and where possible we will make comparisons
with classical algorithms.
All evidence was calculated by evaluating the average times over a reasonable number of
repetitions, using a virtual server with the following configuration:
RAM: 7.64 GB
CPU(s): 4
▪ model name: Intel(R) Xeon(R) Gold 6238R CPU @ 2.20GHz
▪ cpu family: 6
▪ model: 85
▪ cpu MHz: 2194.843
▪ cache size: 39424 KB
5.1. Dimensions
In the tables below, it is evident that the size of the objects generated with the Dilithium
algorithm, encompassing both key-pair and signature cryptographic objects, are 2-3 times larger
compared to Falcon, as corroborated by [11, 14]. Classical algorithms demand significantly less
memory resources than quantum-safe algorithms; however, this was to be expected as robustness to
quantum computers is paid for in terms of space and/or computational time (see Figure 10).
Table 18 – Size of cryptographic objects across algorithms
Dilithium2
Dilithium3
Dilithium5
Falcon-512
Falcon-1024
Public Key Size (bytes)
Private Key Size (bytes)
Signature Size (bytes)
Dimensions
Public Key Size
(bytes)
Private Key Size
(bytes)
rsa 2048
Dilithium2
Dilithium 3
Dilithium 5
Signature Size (bytes)
Falcon-512
Falcon-1024
Figure 10 – Size of cryptographic objects across algorithms
The size of cryptographic objects grows as the level of security increases; moreover, for each
type, there is at least an order of magnitude more than the current asymmetric encryption algorithm
used today (RSA-2048). It is immediately apparent that Falcon is the most parsimonious of the
quantum safe algorithms.
5.2. Execution time
We will now analyze the performance of the various classical and quantum safe algorithms,
in the various scenarios of key creation, digital signature creation (signature – CAdES) and
verification.
An initial analysis shows that the time required to define key pairs is much shorter with the
new quantum safe algorithms, especially when compared to classical algorithms such as RSA with
key lengths of 2048, 3072 or 4096 (see Figure 11).
FALCON
DILITHIUM5
DILITHIUM3
30899
15709
81102
40200
FALCON
KYBER768
KYBER1024
RSA 2048
DILITHIUM3
FALCON 1024
RSA 3072
DILITHIUM5
KYBER768
RSA 4096
FALCON 512
KYBER1024
20000
Occurrences
40000
60000
80000
100000
Figure 12 – Sum of times (ms) as the number of occurrences
increases
Figure 11 – Comparison of key creation times (ms)
Let us now compare only the post-quantum algorithms. Falcon turns out to be the least efficient
from the point of view of computing resources, and this evidence is more sensitive when we try to
increase the number of occurrences (see Figure 12).
Most efficient comparison (ms)
KYBER1024
KYBER768
DILITHIUM5
DILITHIUM3
Number of occurrences 10000
Figure 13 – Comparison among the most efficient
Evidence shows that key creation times are longer for classical algorithms. Among quantumsafe algorithms, Falcon proves to be very costly, while Dilithium, even in its most robust version,
remains within acceptable times. Even though Kyber is more efficient, it has different purposes (see
Figure 13).
In this scenario, we tested the various algorithms during the CAdES digital signature of a PDF
test file of approximately 300KB in size. Timeframes were normalized by not considering the phase
of loading the key and reading the document to be signed. The evidence shows that Dilithium is the
most efficient (even comparing algorithms with the same level of security, see Figure 14).
Digital signature (times in ms)
FALCON 1024
FALCON 512
DILITHIUM5
DILITHIUM3
SHA256withRSA (2048)
Number of
occurrences
10000
10000
50214
10072
33064
28398
26201
28432
20000
30000
40000
50000
60000
Lineare (2000)
Figure 14 – Digital signature times (ms)
Please note that the Dilithium signature scheme is always a winner compared to its main
competitor Falcon, even compared to the classic RSA scheme.
Would anything have changed if we had used a 20MB file for the various signatures?
We reported the evidence below: even by increasing the size of the file to be signed, Dilithium
confirms itself as the best performing, among PQ algorithms (see Figure 15).
Digital signature (times in ms)
FALCON 1024
217755
113151
FALCON 512
221846
112160
DILITHIUM5
221382
110829
DILITHIUM3
221317
111191
SHA256withRSA (2048)
Number of
occurrences
793757
167341
88961
10000
200000
400000
600000
Lineare (2000)
Figure 15 – Digital signature times (ms) for a 20 MB file
By comparing the times between the two scenarios, we obtain the graph below (see Figure 16).
Time comparison
SHA256withRSA (2048)
FALCON 1024
DILITHIUM3
Number of
occurrences
FALCON 512
DILITHIUM5
10000
Figure 16 – Digital signature time comparison
It is worth highlighting, however, that Falcon is less susceptible to this aspect, although
Dilithium recovers as the number of occurrences increases.
On the other hand, Falcon performs better in the verification phase, also due to the smaller
signature size when compared to Dilithium. Its efficiency makes it most suitable in massive signature
verification scenarios (see Figure 17).
Signature verification(ms)
FALCON 1024
FALCON 512
DILITHIUM5
DILITHIUM3
SHA256withRSA (2048)
Number of occurrences
10000
Lineare (10000)
Figure 17 – Signature verification times (ms)
The verification phase is not significantly impacted by the size of the signed file: as the
occurrences increase, the timing relationships stabilize (see Figure 18).
Verification of large file signatures
FALCON 1024
FALCON 512
DILITHIUM5
DILITHIUM3
SHA256withRSA (2048)
Number of
10000
Lineare (10000)
Figure 18 – Signature verification times for large files
Even in this verification scenario, the comparison of times shows us that the verification phase
is not impacted by the size of the signed file (see Figure 19).
Time comparison
FALCON 1024
SHA256withRSA (2048)
FALCON 512
Number of
occurrences
DILITHIUM3
DILITHIUM5
10000
Figure 19 – Signature verification time comparison
This evidence is also reflected in the metrics published by the PQSHIELD portal16 (see Figure 20).
https://pqshield.github.io/nist-sigs-zoo/#performance.
Figure 20 – Performance of signature algorithms17
Empirically, one might anticipate that the generation times for Certificate Signing Requests
(CSRs) would be shorter for classical algorithms due to the smaller key and signature sizes. However,
experimental data indicate the contrary, as illustrated in the accompanying table. Actually,
considering PQ algorithms alone, Dilithium proves to be more effective than Falcon even in this
scenario (see Figure 21).
FALCON-1024
FALCON-512
DILITHIUM5
DILITHIUM3
FALCON-1024
FALCON-512
RSA-4096
RSA-3072
RSA-2048
Times in ms
DILITHIUM5
DILITHIUM3
Times in ms
Figure 21 – Comparison of execution times in the creation of a CSR
it is clarified that the ‘signing’ phase also includes the part of generating the relevant key pair.
6. Conclusions
Dilithium and Falcon are both lattice-based digital signature algorithms designed to be resistant
to quantum attacks. In contrast, SPHINCS+ employs a fundamentally different approach, relying on
hash-based cryptographic constructions. These algorithms are leading candidates in the NIST PostQuantum Cryptography (PQC) standardization process, with differing performance characteristics
that make them suitable for distinct application contexts.
Performance evaluations indicate that Dilithium consistently demonstrates superior
computational efficiency, particularly in key generation and signature creation, making it well-suited
for environments with limited processing capabilities. Falcon, on the other hand, stands out for its
fast signature verification, although it requires more computational resources for key generation and
signing.
In terms of key and signature size, Falcon benefits from a compact design, offering a smaller
public key and signature size compared to other post-quantum algorithms. This makes it
advantageous in constrained environments such as embedded systems or networks with limited
bandwidth. While Dilithium is generally efficient, its relatively larger signature size may introduce
performance bottlenecks in bandwidth-restricted scenarios.
The comparative analysis revealed the following insights:
Security and Size Efficiency: Falcon offers the smallest public key size among the
analyzed schemes, which is particularly beneficial for memory-constrained devices.
Computational Performance: Dilithium is efficient in key generation and signing, while
Falcon excels in signature verification speed.
Applicability to Constrained Devices: in systems such as smart cards, which are
characterized by limited memory, slow processors, and low communication bandwidth
(typically