An ETSI GS QKD Compliant TLS Implementation

∗

Thomas Pr

evost

1 a

, Bruno Martin

1 b

and Olivier Alibart

2 c

I3S, Universit

e C

ote d’Azur, CNRS, Sophia-Antipolis, France

InPhyNi, Universit

e C

ote d’Azur, CNRS, Nice, France

Keywords:

TLS, Quantum Key Distribution, Rust, ETSI.

Abstract:

A modiﬁcation of the TLS protocol is presented, using our implementation of the Quantum Key Distribution

(QKD) standard ETSI GS QKD 014 v1.1.1. We rely on the Rustls library for this. The TLS protocol is

modiﬁed while maintaining backward compatibility on the client and server side. We thus wish to participate

in the effort to generalize the use of QKD on the Internet. We used our protocol for a video conference

call encrypted by QKD. Finally, we analyze the performance of our protocol, comparing the time needed to

establish a handshake to that of TLS 1.3.

1 INTRODUCTION

Quantum computers threaten current public key cryp-

tosystems like RSA and ECC, which are expected to

be broken once such machines are operational (Bhatia

and Ramkumar, 2020). This has prompted concerns

about “harvest now, decrypt later” attacks, where ad-

versaries store encrypted data to decrypt in the fu-

ture (Paul, 2022).

Post-quantum cryptography offers alternatives

based on quantum-resistant problems, but new at-

tacks continue to emerge (Kaluderovic, 2022), raising

doubts about their long-term viability. While PKC is

still standard for key exchange, we propose replacing

it with Quantum Key Distribution (QKD).

QKD enables theoretically perfect forward se-

crecy by using quantum principles—speciﬁcally the

no-cloning theorem— to detect eavesdropping in real

time (Zygelman, 2018). Keys are exchanged using

qubits (typically single photons), and any interception

alters their state, alerting the participants. Authentica-

tion remains reliant on classical PKC.

Though offering strong security guarantees, QKD

faces practical challenges. Device imperfections may

allow attacks (Huang et al., 2019), and the need

for dedicated infrastructure limits its scalability. It’s

https://orcid.org/0009-0000-2224-8574

https://orcid.org/0000-0002-0048-5197

https://orcid.org/0000-0003-4404-4067

∗

This work has been supported by a government grant

managed by the ANR under the Investissement d’avenir

program, ref. ANR-17-EURE-004.

best suited for high-security environments like inter-

datacenter links or governmental networks.

Due to ﬁber loss and the no-cloning theorem,

QKD is limited to a few hundred kilometers (Huttner

et al., 2022). Multipath QKD protocols address this

with trusted intermediaries (Liu et al., 2024; Pr

evost

et al., 2025). ETSI GS QKD 014 v1.1.1 deﬁnes a stan-

dard interface for managing QKD keys (ETSI, 2019),

which we previously veriﬁed with ProVerif under spe-

ciﬁc assumptions (Pr

evost et al., 2024).

We present a practical implementation of this

standard by integrating QKD into TLS. Our “TLS-

QKD” protocol replaces the handshake’s public key

exchange with a request to a local QKD manager, se-

cured via HTTPS with bilateral authentication. The

ETSI standard assumes local networks can safely use

classical public key cryptosystems. Once a quantum

key is received, symmetric encryption ensures mes-

sage conﬁdentiality.

TLS-QKD is fully backward compatible: it can in-

teroperate with standard TLS clients and servers. We

designed the implementation to align with our formal

proof and developed supporting QKD key manage-

ment tools, including a video conferencing demo us-

ing TLS-QKD.

Related Work. The use of pre-shared keys (PSK)

in TLS is already described in RFCs 9257 and

9258 (Housley et al., 2022; Benjamin and Wood,

2022). However, we do not rely on this standard,

but on a custom protocol that has been formally veri-

ﬁed (Pr

evost et al., 2024).

Prévost, T., Martin, B., Alibart and O.

An ETSI GS QKD Compliant TLS Implementation.

DOI: 10.5220/0013564700003979

In Proceedings of the 22nd International Conference on Security and Cryptography (SECRYPT 2025), pages 705-710

ISBN: 978-989-758-760-3; ISSN: 2184-7711

705

(Tankovic et al., 2024a) tested an implementation

of the ETSI GS QKD 014 standard in real conditions,

to measure latency and transmission rate, as well as a

complete analysis of the standard’s performance in a

multi-user environment (Tankovic et al., 2024b), and

a simulation of the protocol’s use cases, with an esti-

mation of possible key rates depending on the location

of the sites (Dervisevic et al., 2024).

(Martin et al., 2024a) also proposes an implemen-

tation of the ETSI standard on the Madrid QKD net-

work. As many countries develop their QKD network

independently, we cannot exhaustively cite all the im-

plementations of the ETSI standard. The ﬁnal goal

would be to set up large QKD networks, for example

on the scale of the European continent (Martin et al.,

2024b).

Interestingly, the authors of (Buruaga et al., 2025),

who wrote their paper at the same time as us, propose

a modiﬁcation of the TLS protocol based on the ETSI

GS QKD 004 standard

The paper is organized as follow: section 2 intro-

duces the ETSI standard proposal for QKD. Section 3

presents our implementation, explaining the opera-

tion mode of our protocol and the changes to TLS.

We evaluate the performance tests performed on our

protocol, measuring the time for the handshake with

TLS-QKD, compared to that of TLS 1.3. Finally we

suggest avenues for improving and we discuss about

a possible future for Quantum Key Distribution pro-

tocols.

2 ETSI GS QKD 014 V1.1.1

In this section, we brieﬂy recall the operative mode

of the ETSI GS QKD 014 v1.1.1 standard proposal

which is mainly focused around a REST interface,

through which the different actors interact. The stan-

dard deﬁnes two types of communication: commu-

nication within “secure zones” (e.g. inside a LAN),

where PKC is allowed, and outside communication

(e.g. over a WAN), where communications require

QKD.

Two types of actors interact in the this proto-

col: KME: Key Management Entities managing keys

within the LAN and exchanging keys with remote

KMEs using QKD, and SAE: Secure Application En-

tities, applications that request keys to KMEs for

communication.

SAEs make requests to their datacenter’s KME via

a REST API, secured by HTTPS. The KME is there-

https://www.etsi.org/deliver/etsi gs/QKD/001 099/

004/02.01.01 60/gs qkd004v020101p.pdf

Figure 1: This diagram shows a typical quantum key ex-

change between the initiator SAE 1 (“master”) and the

SAE 2 ”slave”, as deﬁned in the standard proposal. SAE 1

makes an authenticated key request to its local KME

(KME 1), which communicates the key enciphered within

a TLS response to the remote KME (KME 2). SAE 1 then

transfers the key identiﬁer to its SAE 2 peer, which requests

the key from its local KME.

Figure 2: Flow of a key exchange using the veriﬁed imple-

mentation of the ETSI protocol.

fore authenticated by the server certiﬁcate. To authen-

ticate itself, the SAE presents a client TLS certiﬁcate.

This certiﬁcate also uniquely identiﬁes the SAE.

Each actor, KME and SAE, is identiﬁed by a

unique identiﬁer in the network. The keys are identi-

ﬁed by their UUID ﬁngerprint, which is also supposed

to be unique. Fig. 1 shows a key exchange between

two SAEs on remote data centers.

The ETSI standard deﬁnes the interface and the

order of communications. It does not go into crypto-

graphic details, e.g. how QKD is performed or key

identiﬁers are transmitted are considered “outside the

scope of the document”.

When we formally veriﬁed the standard using

ProVerif (Pr

evost et al., 2024), we determined that

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

706

the ETSI prototype standard guaranteed the conﬁden-

tiality and authenticity of the key with the following

constraints on the implementation:

• The connection between the two KMEs must be

authenticated (this is already a prerequisite for the

operation of QKD).

• The second SAE (“slave”) must send a crypto-

graphic challenge to the initiating SAE (“master”)

to authenticate the latter by ensuring that it owns

the correct quantum key.

Fig. 2 shows an example protocol following an

implementation compatible with these security re-

quirements.

3 OUR IMPLEMENTATION

Let us present our Key Management software, as well

as our implementation of the custom Rustls library,

and our video conferencing software based on TLS-

QKD.

3.1 KME Key Manager

Key Management Entities (KMEs) are responsible for

managing keys within the data center and exchanging

keys with their remote counterparts by QKD. For our

experiments, we used BBM92 (Bennett et al., 1992b),

based on the entanglement of photons pairs. Any

other QKD protocol, however, would have given sim-

ilar results. After receiving all the photons, the two

remote KMEs share a sequence of random bits. It is

necessary to add a Privacy Ampliﬁcation (PA) step on

both sides in order to extract the maximum entropy

from these shared bits (Bennett et al., 1992a). This

step ensures the uniformity of the random bits of the

symmetric key, and therefore its security. At the end

of the protocol, the protagonists share a secret per-

fectly random bit string.

Our KME software takes as a parameter a folder

in which the key ﬁles are located after Privacy Am-

pliﬁcation and cuts them into sections of 32 bytes

(the keys). If new keys are generated during opera-

tion of the KME server, the latter will add them to

its database. If the KME exchanges keys with several

other KMEs, it takes as parameter the folders contain-

ing the keys exchanged with each of its counterparts.

SAEs are authenticated with their client TLS cer-

tiﬁcate, and identiﬁed with the certiﬁcate serial num-

ber. Indeed, the serial number of the certiﬁcate is cho-

sen by the Certiﬁcate Authority, and can therefore be

unique within the secure zone. The KME associates

the serial number with a unique identiﬁer on the net-

work, a 64-bit integer.

Each KME also has a unique identiﬁer on the net-

work in the form of a 64-bit integer. The addressing of

KMEs is independent of that of SAEs, which means

that a KME can have the same address as a SAE.

The UUID of the keys is generated from their

SHA-1 ﬁngerprint.

We added this route to allow an administrator to

detect a failure or an attack in QKD.

In order to inform its remote counterpart of the

association between a SAE and its key, the KME also

uses the REST protocol, encrypted via HTTPS and

authenticated on both sides, between the two KMEs.

Bilateral authentication between KMEs is done with

client and server X.509 certiﬁcates. Note that we use

a regular HTTPS protocol to notify the KME of the

use of a key, to protect against a “Harvest now, de-

crypt later” attacker. So we assume that at the time

of the exchange, the attacker is not able to break the

public key encryption.

The KME key manager source code can be re-

trieved at: https://github.com/thomasarmel/qkd

kme

server/.

3.2 Our Implementation of TLS with

QKD Keys

Our implementation of TLS with QKD keys is a mod-

iﬁcation of the Rustls library. Our version of Rustls

is designed to be backward compatible in both direc-

tions. Thus, a TLS-QKD client can connect to a clas-

sic TLS server, and a TLS-QKD server can receive

classical TLS connections. We could then fear that a

malicious actor could carry out a “downgrade attack”

to force the protagonists to use classic TLS to weaken

the protocol.We are fully aware of this vulnerability,

and believe this is an acceptable compromise at this

time to facilitate adoption of the protocol. However,

the user who needs strict QKD protection could easily

disable TLS 1.3 backward compatibility.

Our implementation of TLS-QKD is a modiﬁca-

tion of the TLS 1.3 protocol (Rescorla, 2018). Here

are the changes we made to the protocol:

3.2.1 Client and Server Conﬁguration Interface

The TLS client and server are two SAEs in the ETSI

protocol. Client is the initiating (“master”) SAE.

They must collect the keys from their local KME. The

client and the server take the address and port number

of the KME interface as parameters. SAEs authenti-

cate with KMEs using client TLS certiﬁcates.

An ETSI GS QKD Compliant TLS Implementation

707

3.2.2 Protocol Version

TLS messages contain the protocol version number in

two bytes. For example, the code associated with TLS

version 1.3 is 0x0304. For our TLS-QKD implemen-

tation, we arbitrarily chose the number 0x0E00.

3.2.3 Client Request to KME

Equipped with its client TLS certiﬁcate and the SAE

identiﬁer of the TLS server, the client can make a re-

quest to the KME of its “secure zone” to request a

key allowing it to communicate with the remote SAE.

The remote SAE is identiﬁed by its unique identiﬁer,

a 64-bit integer. This number is speciﬁed by the pro-

grammer when establishing the connection with the

KME. The KME then returns the key in base64 for-

mat as well as the UUID of this key.

The TLS clients will also request their SAE iden-

tiﬁer from their KME:

https://{KME hostname}/api/v1/sae/info/me

3.2.4 ClientHello Extension

The TLS client communicates to the server its SAE

identiﬁer as well as the UUID of the key via an exten-

sion of the ClientHello message. We add to the ex-

tension the Initialization Vector (IV) which will sub-

sequently be used for secret key encryption (the IV

could be the output of a key derivation function like

PBKDF2). Each type of extension is associated with a

2-byte number. We arbitrarily chose 0xFEA6 for this

ClientHello extension. If the TLS server detects this

extension in ClientHello, it determines that the client

supports TLS-QKD.

3.2.5 Server Request to KME

The TLS server having detected that the client wishes

to communicate using TLS-QKD, it makes in turn a

request to the KME of its “secure-zone”, to ask for

the key associated with the UUID and the identiﬁer of

the initiating SAE “master”, received in ClientHello.

If the response from the KME is positive, the TLS

client and server then share a secret key. However, it

remains to correctly authenticate the initiating SAE,

which will be done later by a cryptographic challenge.

3.2.6 ServerHello Extension

In order to authenticate the client, the TLS server

must ensure that the latter is in possession of the quan-

tum key. To do this, it will send him a cryptographic

challenge, in the form of a 256 bits random token and

a 256 bits random seed, encrypted with the quantum

key. The TLS client must send back the same token

as well as a different random seed, encrypted with

the same quantum key. The challenge is inserted as

an extension in the ServerHello response. The 2-byte

number we arbitrarily chose for this ServerHello ex-

tension is 0xFEA7. By ﬁnding this extension in the

ServerHello response, the client will have conﬁrma-

tion that the server supports TLS-QKD.

3.2.7 Client Challenge Acknowledgment

After having conﬁrmed that the server supports TLS-

QKD, the client must now send the cryptographic

challenge back to the server in order to authenticate.

After decrypting the ServerHello challenge, the client

encrypts it again after changing the random seed. It

sends the response to the challenge in the form of

a new message type, ChallengeAck. TLS provides

a one-byte code for each message type. For exam-

ple, ApplicationData messages have the code 0x17.

For ChallengeAck messages, we arbitrarily chose the

code 0x50. Once the acknowledgment has been ver-

iﬁed by the server, both participants directly start the

data transfer using the quantum symmetric key.

The client no longer checks the server’s TLS cer-

tiﬁcate, since the TLS-QKD protocol is sufﬁcient to

guarantee its authentication provided that the security

assumptions on the KMEs are respected, as proven by

ProVerif in (Pr

evost et al., 2024). It is also no longer

necessary to send a Finished message to authenticate

the handshake.

3.2.8 Symmetric Encryption

For symmetric encryption, we use AES-AEAD. This

is not, however, a security necessity, as authentication

is already guaranteed by the protocol. The key size is

arbitrarily ﬁxed to 256 bits, a standard to be quantum

safe. The key size is hardcoded in our implementa-

tion. Keys are never regenerated in this implementa-

tion, we are considering this feature in future work.

3.2.9 Implementation

Fig. 3 shows a TLS-QKD handshake. Code is

available at: https://github.com/thomasarmel/rustls/

tree/qkd.

3.3 Proof of Concept: A Video

Conference Call Encrypted by

TLS-QKD

In order to provide a proof of concept of our proto-

col, we created videoconferencing software encrypted

with TLS-QKD. This software is separated into two

parts: a server managing the audio and video display,

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

708

Figure 3: Handshake on TLS-QKD.

and a client, which captures the video stream from the

camera and the audio from the microphone. To make

a videoconference call, it is therefore needed to ﬁrst

launch the server on both machines, then the client.

Code is available at: https://github.com/thomasarmel/

qkd camera streaming client/.

During our tests between the INRIA center, in

Sophia Antipolis (France) and the InPhyNi site, in

Nice (France) at 25km distance, we managed to set

up a videoconference with a resolution of 720 pixels

and 10 fps. The conversation was absolutely not ham-

pered by sound latency. TLS-QKD typically took less

than 1 second to perform the key handshake.

We also tested the operation of backward com-

patibility towards classic TLS, the code is avail-

able at https://github.com/thomasarmel/rustls/blob/

qkd/rustls/tests/qkd.rs.

3.4 Protocol Performance

We tested the performance of our protocol on the

same sites that were used during the videoconference,

25 kilometers apart. These two sites are connected by

a direct optical ﬁber with a particularly low latency

(approximately 1 ms).

We performed 10 measurements of the time re-

quired to perform a handshake between the two SAEs

with our protocol (on the “TLS-QKD” classical link),

it takes on average 38.2 ms, with a minimum of 25

ms and a maximum of 66 ms. For comparison, we

performed 10 measurements of the latency time of

a handshake in TLS 1.3, on the same network: the

average delay is 21.5 ms, with a minimum of 17 ms

and a maximum of 28 ms. The code used to test the

handshake duration is available at https://github.com/

thomasarmel/test https qkd.

It should be noted, however, that our network is

particularly favorable to our protocol, which requires

a lot of message exchanges during the handshake, be-

cause the ping latency between the two sites is about

1 ms. A network with higher latency would show a

much larger gap in delay between the handshake of

our protocol and that of TLS 1.3.

4 FURTHER IMPROVEMENTS

The main problem with TLS-QKD is its relative slow-

ness at the handshake, i.e. to exchange the quantum

symmetric key. In fact, each SAE must start by estab-

lishing a secure connection with its KME.

A total of 29 messages is exchanged between the

different actors (SAEs and KMEs) during handshake,

including TCP SYN and ACK messages. One way

to reduce the number of messages would be to pre-

establish a TLS connection between the SAEs and the

KMEs. However, this would make our library much

less portable, since programs running on SAEs would

have to communicate with a background service re-

sponsible for keeping the connection with the KME

active. Since we are targeting data center use, this

compromise could be acceptable.

Another solution would be to rely on the QUIC

protocol, which uses UDP instead of TCP. Since

SAE-KME communications operate over a LAN,

packet loss should not be too much of a problem. This

solution would at least reduce latency in communica-

tions between SAEs and KMEs.

It would further be possible to pre-establish TLS

connections in advance between KMEs. This would

work at least as long as the overall network of KMEs

is not too large. If the network size becomes too large,

we could ensure that only the most frequent inter-

KME links pre-establish the TLS connection in ad-

vance.

In this implementation, we never regenerate the

symmetric key. Adding this feature would increase

the security of our protocol. The property of forward

secrecy is in fact not assured if an attacker were to dis-

cover the quantum key, which is more vulnerable be-

cause it is shared between four actors (the two KMEs

and the two SAEs).

In our current implementation, the TLS client (ini-

tiating SAE) is required to know the TLS server SAE

identiﬁer in advance. To avoid managing a direc-

tory of correspondence between nodes and their iden-

tiﬁers, we could consider deriving unique identiﬁers

from network addresses. If the IPv6 standard were to

be widely adopted, then we could use it as a unique

identiﬁer, since IPv6 addresses are the same in the

LAN and the WAN.

An ETSI GS QKD Compliant TLS Implementation

709

5 CONCLUSION

In this paper, we presented a modiﬁed TLS proto-

col which uses keys exchanged by QKD, compliant

with the ETSI GS QKD 014 v1.1.1 standard proposal.

Our protocol offers a solution against “harvest now-

decrypt later” attacks.

Our protocol remains vulnerable if the attacker is

able to break QKD authentication between KMEs on

the ﬂy, since she will be able to carry out a MITM

attack. However, this type of scenario seems unlikely

today. Indeed, if we still use PKC or PQC for inter-

KMEs authentication (for QKD and key requests), it

is very unlikely that an attacker would have a quantum

computer capable of breaking such a cryptosystem in

a short time.

It is backward compatible in both directions with

TLS. We have deliberately chosen to leave this back-

ward compatibility despite the risk of “downgrade at-

tack”, in order to facilitate a potential adoption. How-

ever, backward compatibility can easily be disabled in

the future.

The protocol is based on TLS 1.3, but adds ad-

ditional conﬁguration for communication with Key

Management Entities (KME). The information nec-

essary for the protocol to run is sent in extensions that

we added to the ClientHello and ServerHello mes-

sages. Additionally, another message is sent by the

client at the end of the handshake to conﬁrm their

identity, ChallengeAck.

Finally, we showed that our protocol is usable

in real application cases, such as videoconferencing.

However, the time required for the handshake remains

signiﬁcantly longer than a classic TLS handshake,

since many more messages are sent and that the ap-

plication spends a lot of time waiting for the KMEs

stack to return the symmetric keys.

REFERENCES

Benjamin, D. and Wood, C. (2022). RFC 9258: Importing

external pre-shared keys (PSKs) for TLS 1.3.

Bennett, C., Bessette, F., Brassard, G., Salvail, L., and

Smolin, J. (1992a). Experimental quantum cryptog-

raphy. Journal of cryptology.

Bennett, C., Brassard, G., and Mermin, N. (1992b). Quan-

tum cryptography without Bell’s theorem. Phys. re-

view letters.

Bhatia, V. and Ramkumar, K. (2020). An efﬁcient quantum

computing technique for cracking RSA using Shor’s

algorithm. In 2020 IEEE 5th int. conf. on computing

communication and automation (ICCCA). IEEE.

Buruaga, J. S., M

endez, R. B., Brito, J. P., and Martin, V.

(2025). Quantum-safe integration of TLS in SDN net-

works. arXiv preprint arXiv:2502.17202.

Dervisevic, E., Fehri

c, M., Pivac, D., Fazio, P., Voznak,

M., and Mehic, M. (2024). Simulations of selected

quantum key distribution network use-cases. In 2024

International Conference on Quantum Communica-

tions, Networking, and Computing (QCNC). IEEE.

ETSI, G. (2019). 014. Quantum Key Distribution (QKD);

protocol and data format of REST-based key delivery

API.

Housley, R., Hoyland, J., Sethi, M., and Wood, C. (2022).

RFC 9257: Guidance for external pre-shared key

(PSK) usage in TLS.

Huang, A., Navarrete,

A., Sun, S., Chaiwongkhot, P., Curty,

M., and Makarov, V. (2019). Laser-seeding attack in

quantum key distribution. Phys. Review Applied.

Huttner, B., All

eaume, R., Diamanti, E., Fr

owis, F., Grang-

ier, P., H

ubel, H., Martin, V., Poppe, A., Slater, J. A.,

Spiller, T., et al. (2022). Long-range QKD without

trusted nodes is not possible with current technology.

npj Quantum Information.

Kaluderovic, N. (2022). Attacks on some post-quantum

cryptographic protocols: The case of the Legendre

PRF and SIKE. Technical report, EPFL.

Liu, C., Che, X., Xie, J., and Dong, Y. (2024). A multi-path

QKD algorithm with multiple segments. Journal of

Cyber Security and Mobility.

Martin, V., Brito, J. P., Ort

ız, L., Mendez, R., Buruaga,

J., Vicente, R., Sebastian-Lombrana, A., Rincon, D.,

Perez, F., Sanchez, C., et al. (2024a). Madqci: a

heterogeneous and scalable SDN-QKD network de-

ployed in production facilities. npj Quantum Infor-

mation.

Martin, V., Peev, M., Brito, J., Ort

ız, L., Brito-M

endez, R.,

Vicente, R., Saez-Buruaga, J., Sebastian-Lombra

na,

A., Garc

ıa-Cid, M., Faba, J., et al. (2024b). Towards

large scale QKD networks. In 2024 24th Interna-

tional Conference on Transparent Optical Networks

(ICTON). IEEE.

Paul, S. (2022). On the transition to post-quantum cryptog-

raphy in the industrial Internet of things.

evost, T., Martin, B., and Alibart, O. (2024). Formal veri-

ﬁcation of the ETSI proposal on a standard QKD pro-

tocol. GTMFS.

evost, T., Martin, B., and Alibart, O. (2025). A secret key

spreading protocol for extending ETSI quantum key

distribution. In Proceedings of the 11th International

Conference on Information Systems Security and Pri-

vacy - Volume 2: ICISSP. INSTICC, SciTePress.

Rescorla, E. (2018). The transport layer security (TLS) pro-

tocol version 1.3. Technical report.

Tankovic, A., Burdiak, P., Dervisevic, E., Voznak, M.,

Mehic, M., and Kaljic, E. (2024a). Performance anal-

ysis of ETSI GS QKD 014 protocol in 5G/6G net-

works. In Future of Information and Communication

Conference. Springer.

Tankovic, A., Dervisevic, E., Voznak, M., Mehic, M., and

Kaljic, E. (2024b). Performance analysis of ETSI GS

QKD 014 protocol in multi-user environment. In 2024

23rd International Symposium INFOTEH-JAHORINA

(INFOTEH). IEEE.

Zygelman, B. (2018). No-cloning theorem, quantum tele-

portation and spooky correlations. A First Introduc-

tion to Quantum Computing and Information.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

710