Quantum Key Distribution Network Simulation Module (version 2.0)

The QKD network is an add-on technology and service to conventional telecommunications networks [Meh2023]. The sole purpose of the QKD network is to generate, manage, and distribute cryptographic keys among arbitrary QKD nodes and to provide keys as a service to standard communications network users or applications [Meh2020]. The main objective and motivation is to increase communications security. The functional requirements [ITU3801] of the QKD network are divided into several distinct layers: the quantum layer, the key management layer, the QKD network control layer, the QKD network management layer, and the service layer [ITU3802].The quantum layer comprises pairs of QKD modules connected by logical QKD links that implement both the quantum and classic steps of the QKD process.

Fig.1 Layered structure of the QKD network based on ITU-T recommendations.

Quantum Key Distribution Network Simulation Module (QKDNetSim) incorporates the major functional elements of QKD networks [Meh2020]:

• QKD key

• QKD Buffer (storage)

• QKD Control

• QKD Encryptor

• QKD Post-processing applications

• QKD Graph

• QKD Key Management System Application

• QKD Applications

The implementation of QKD Buffer, QKD Key is based on Austrian Institute of Technology (AIT) R10 post-processing software (https://sqt.ait.ac.at/software/projects/qkd).

Impresum

It has been developed by Emir Dervisevic (emir.dervisevic@etf.unsa.ba) and Miralem Mehic (miralem.mehic@ieee.org), and it is maintained by the Department of Telecommunications of the University of Sarajevo, Bosnia and Herzegovina (https://www.tk.etf.unsa.ba) and Department of Telecommunications of VSB Technical University of Ostrava, Czech Republic (https://www.vsb.cz).

Prerequisite

The latest version of the code is compatible with NS-3 version 3.41. Thus, one should follow installation requirements from the NS-3 official website (https://www.nsnam.org/wiki/Installation). The code has been successfully tested on Ubuntu 22.04. QKDNetSim v2.0 module is not compatible with QKDNetSim version 1.0. [Meh2017]. This module is written independently and from scratch.

QKDNetSim includes QKDEncryptor class that relies on cryptographic algorithms and schemes from Crypto++ open-source C++ class cryptographic library. Currently, QKD crypto supports several cryptographic algorithms and cryptographic hashes, including One-Time Pad (OTP) cipher, Advanced Encryption Standard (AES) block cipher, VMAC message authentication code (MAC) algorithm, and others.

Installing crypto++ (libcryptopp) and Universally Unique Identifiers (UUIDs) libraries on Ubuntu:

$ sudo apt-get install libcrypto++-dev libcrypto++-doc libcrypto++-utils gnuplot uuid-dev

In your scripts simple include required libraries using:

$ #include <crypto++/aes.h>;
$ #include <crypto++/modes.h>;
$ #include <crypto++/filters.h>;

CMakeLists.txt are updated to support crypto++ and uuid libraries.

Model Description

This section describes the essential components, or classes, of the QKDNetSim simulation environment:

• QKD core components (located in directory src/qkd) and

• QKD applications (located in src/applications) according to specific abstractions and purposes.

Fig.2 QKDNetSim Class diagram - Module organization

QKD Key

A discussion of QKD networks is primarily about keys and their generation, storage, management, and use. In QKDNetSim, keys are pseudo-random character sequences generated by QKD post-processing applications. They are uniquely identified at the quantum layer using UUIDs (Universally Unique Identifiers):rfc:4122, [Der2024], 36 character strings, and at the key management layer, using 8 character strings generated by a hash function. The truncated output of the hash function is sufficient to uniquely identify keys on a single QKD connection without collisions. In addition to unique identifiers, the keys are tagged with timestamps of their creation, length, and current state. The current state of the key assists the KMS in performing specific management tasks and can be set to INIT, READY, or OBSOLETE. The QKD key implements several parameters:

• key identification (ID)

• key size

• key value in std::string or byte format

• key generation timestamp

QKD Buffer

Due to the limited key generation rate of the QKD modules, keys are most commonly generated at the highest rate supported and then stored in a safe place for subsequent use in cryptographic processes. The purpose of the QKD buffer is to collect enough key material for its subsequent use for cryptographic purposes. Due to the limited charging key rate of QKD protocols, QKDPostProcessing applications strive to save keys in QKD buffers to generate as many keys as possible in advance. However, warehouses have a limited capacity defined with a maximum value. They also have a minimum capacity that describes the minimum amount of key required to establish initial post-processing operations. Also, the buffer implements a threshold value that may indicate the necessary actions are being taken before the buffer is completely emptied.

The following parameters characterize QKD buffers:

• QKD is also known as Quantum Key Growing since it needs a small amount of key material pre-shared between parties to establish a larger amount of the secret key material. The pre-shared secret key guarantees the protocol’s integrity in the first transaction and should not be used for any other purposes except to establish a new key material. The amount of pre-shared key material for that purpose is denoted with Mmin,

• The key material storage depth Mmax, used to denote the maximal amount of keys that can be stored in the QKD buffer,

• The current value Mcur(t), representing the amount of key material in QKD buffer at the time of measurement t, where it holds that Mcur(t)<=Mmax,

• The threshold value Mthr(t) at the time of measurement t is used to indicate the state of the QKD buffer where it holds that Mthr(t)<=Mmax. During the simulation, Mthr(t) can be static or variable depending on the state of the network. However, algorithms for calculating Mthr are out of the scope of this document.

Fig.3 Graphical representation of QKD buffer status generated using the QKD Graph

As shown in Fig.3, QKD buffer can be in one of the following states:

• READY - when Mcur(t)>=thr,

• WARNING - when Mthr>Mcur(t)>Mmin and the previous state was READY,

• CHARGING - when Mthr>Mcur(t) and the previous state was EMPTY,

• EMTPY - when Mmin >= Mcur(t) and the previous state was WARNING or CHARGING.

The states of QKD buffer do not directly affect the communication, but it can be used for easier traffic prioritization depending on the buffer’s state. For example, in EMPTY state, QKD post-processing application used to establish a new key material should have the highest priority in traffic processing. Constant monitoring of the state of the QKD Buffer is therefore needed and assists with key management and key provisioning operations.

Each QKD Buffer has a standard size for the keys it stores. The KMS is responsible for reformatting keys into the correct size before storing them. This is accomplished using the key storage function.

QKD Control

The QKD control implements essential network controller functions. We refer to it simply as the controller. The controller implements a subset only of the ITU-T functions defined for the control layer [ITU3803].

QKD Encryptor

The QKD encryptor is an entity that performs cryptographic operations such as encryption/decryption, authentication, and authentication checks. It is implemented using Crypto++, an open-source cryptographic library. It supports using the VMAC and SHA2 algorithms for authentication and OTP and AES for encryption. As cryptographic algorithms can place a significant computational load on the simulation machines, QKDNetSim allows their execution to be switched off to enable efficient simulations of more significant QKD topologies.

QKD Post-processing Application

Each of the numerous QKD protocols necessitates post-processing the information obtained from the quantum transmission. Because the simulator is designed to simulate large-scale QKD networks and management methods rather than establishing keys on the quantum channel, communications on the quantum channel are ignored. Therefore, the QKD post-processing application is implemented to simulate a QKD protocol’s network activity. This application only accurately mimics the traffic from existing post-processing systems and does not bear any computational load from executing operations. This approach reduces the simulation time and conserves computational resources while enabling the effects of different parameters, such as key generation rate, traffic volume, and network capacity, to be studied on the state of the entire network. The QKD post-processing application has many configurable parameters that allow a reasonable adoption of many use cases. These parameters include average key rate, key size, network packet size exchanged during the post-processing phase, and traffic intensity. The QKD post-processing application uses a simple ping-pong principle in which peers exchange counter values. The counter is reset regularly depending on the key rate setting, and packets are sent back and forth. Sifting packets are traded first when the counter is reset. At the end of the process, the generated keys are handed over to the KMS, where they are stored, managed, and consumed.

Fig.4 UML QKDNetSim Sequence diagram - Post-processing application

QKD post-processing application is characterized by the following parameters:

• KeySize - the amount of data to be added to QKD Buffer (in bits). Note that the key length must be divisible by 8 as specified in the ETSI 014 documentation.

• KeyRate - the average QKD key rate

• DataRate - the average data rate of communication

• PacketSize - the packet size of packets sent in post-processing state

• MaxSiftingPackets - the size of packets sent in the sifting state.

• Protocol - The default type of transporting protocol to be used (TCP by default)

• ProtocolSifting - The type of protocol to use for sifting (UDP by default)

• Remote - The address of the destination (Bob)

• Local - The local address on which to bind the listening socket

• Remote_Sifting - The address of the destination for sifting traffic

• Local_Sifting - The local address on which to bind the listening sifting socket

The user can set the addresses and ports used for post-processing, the size of the key to be generated, the average key rate, the size of network packets exchanged within post-processing traffic, and the average traffic intensity.

The application follows a simple ping-pong principle where Alice and Bob exchange counter values. Depending on the key rate setting, the counter is periodically reset, and packets carrying the information necessary to add the key of specified size to the QKD buffer are exchanged. Further, the application starts counter-counting again from zero until the next reset. Sifting packets are exchanged after resetting the counter. The figure x depicts the traffic flow within the post-processing application.

QKD Graph

QKD graphs are implemented to allow straightforward access to QKD buffers’ state and convenient monitoring of key material consumption. QKD graph is associated with QKD buffer, allowing graph plotting on each node with associated QKD link and QKD buffer. QKD Graph creates separate PLT and DAT files suitable for plotting using a popular Gnuplot tool in PNG, SVG, or EPSLATEX format. QKDNetSim supports the plotting of the QKD Total Graph, which shows the overall consumption of key material in the QKD Network. Fig.5 is plotted using QKDGraph.

Fig.5 QKDNetSim Total Graph

The QKD total graph shows summarized consumption/generation of the keys in the whole network.

QKD Helpers

QKDNetSim includes two helper classes, a QKD link helper and a QKD application helper, to simplify the installation of QKD entities at network nodes. The QKD link helper oversees the installation of controllers, configuration of buffer attributes for connections, collection of topology data, and creation of the topology graph. The QKD application helper oversees the installation of components assigned to the QKD Applications group.

QKD Key Management System

The QKD Key Manager System Application, or the KMS, implements major functional requirements for the key management layer. It is a stand-alone software application that oversees key management and supply to cryptographic applications. Because the supply of QKD-derived key material is limited, how KMS manages and provisions keys is critical. To function correctly, the KMS must communicate with other components of the QKD network. We assume that the KM links are secured using traditional methods that provide quantum-resistant authentication.

The KMS is an essential component of the QKD network’s overall framework. It provides simple access to the QKD network’s services for ITS key provisioning. Because the supply of keys is limited, the method of completing these tasks is critical. Producing this component demanded most of our work, mainly since methods at this layer are frequently overlooked or omitted in research papers. The article describes a custom implementation of the KMS and its methods for communicating with other components of the QKD network. We followed the ITU-T guidelines and applied standardized interfaces where possible (ETSI QKD 014 and ETSI QKD 004, in particular).

KMS is implemented as an application that listens on TCP port 80. The KMS can be installed on any node of the network. The local KMS is contacted to add the keys to the QKD buffer and is approached during the operation of the QKD application to retrieve the keys from the QKD buffer as described in the following section. The KMS application tracks REST-full design serving status and key retrieval requests from QKD applications.

Communications between the applications and KMSs is generally established over the HTTPS protocol. QKDNetSim, however, primarily uses HTTP without TLS security. Although QKDNetSim can be upgraded with HTTPS support, it does not benefit from this for its intended purpose. Implementing the HTTPS protocol in an NS-3 environment would require too much time and not contribute to the simulator’s functionality. The methods proposed in the HTTP variant are the same as those used with HTTPS; the only difference is that HTTPS protocol messages are transmitted over a secure TLS connection at the transport layer. Because the primary goal of the proposed simulator is to provide a foundation for developing advanced key and network management methodologies in trusted-repeater QKD networks, implementation of the HTTPS protocol is not critical. Any HTTP method defined here should, therefore, rely on HTTPS.

QKD Applications

QKDNetSim implements two cryptographic applications, QKD Application 014 and QKD Application 004, to test QKD network performance and assign it purpose and meaning. These applications simulate QKD-enabled secure communications in various cryptographic or network organization settings and are thus consumers of QKD services. The primary distinction between the two applications is the ETSI interface used for communicating with the local KMS and, consequently, for internal key management logic at the application level.

Fig.6 The general purpose of cryptographic applications. For illustration purposes, the diagram depicts only QKD Application 014.

The general purpose of the QKD cryptographic applications, or simply the applications, is to imitate the applications that consume cryptographic keys. It also evaluates the system’s performance as a whole under various conditions and illustrates which end-user services can be supported on the QKD network. Data communication is unidirectional; the applications function in a master/slave paradigm. The master is the application that sends confidential data to the peer-slave, and the slave is a simple receiving application. Protected user data is encapsulated with a QKD Application Header and sent over a public, unsecured channel. The QKD Application Header, contains key information (e.g., the applied cryptographic algorithms and the unique key identifiers of the cryptographic keys used for processing data) that assists the receiving applications in processing the protected (encrypted/authenticated) packets.

The QKD application is based on several parameters:

• NumberOfKeyToFetchFromKMS - the total number of keys per request to local KMS

• SizeOfKeyToFetchFromKMS - The size of keys per request in bits from KMS

• LengthOfAuthenticationTag - the default length of the authentication tag

• EncryptionType - The integer identifier of the used encryption type: 0-unencrypted, 1-OTP, 2-AES (default value 1)

• AuthenticationType - The integer identifier of the used authentication:

QKD app packet header that carries info about used encryption, auth tag, and other:

Fig.7 QKDNetSim QKDApp Header

with:

• Length: total size of packet, including the length field itself

• Msg-Id: message number (inside a channel)

• E: Type of used encryption cipher where value 0 means unencrypted packet

• A: Type of used authentication algorithm where value 0 means non-authenticated packet

• E-KeyId: Encryption Key Id

• A-KeyId: Authentication Key Id

• A-Tag: Authentication tag

QKD Application 014

This section describes the implementation of QKD Application 014, or simply App014, a key consumption application for communicating with the local KMS via the ETSI QKD 014 interface [ETSI014]. The application has numerous user-configurable parameters to support simulations of different use cases. Data rate, packet size, applied encryption and authentication protection, key lifetime, and the length of the authentication tag are examples of these parameters. App014 also lets users configure parameters related solely to the operation of this application; for example, users can specify the number of keys fetched by a single GET_KEY request or the time-out value that defines how long the application waits before issuing a new request if the previous request fails.

Fig.8 QKDNetSim Sequence diagram - QKDApp 014 application

Because the system may obtain multiple keys, some key management logic must be applied at the application layer. QKDNetSim implements key stores at the application layer, and keys are sorted according to their use. Temporary and outbound key stores are specified on the sender’s side and in the master App014, the latter being further subdivided into encryption and authentication stores. The receiver App014 only implements the inbound key store and applies a more straightforward key management logic. If both encryption and authentication algorithms require key material, both outbound encryption/authentication key stores must have valid entries before the application can securely transmit data. QKDNetSim implements a method mentioned in the ETSI interface standard on the service layer, i.e., key ID notification. It is the HTTP POST method – KEY_IDS with a request data model corresponding to a key_IDs data format.

QKD Application 004

The QKD Application 004, or simply App004, serves the same purpose as App014, but it communicates with the local KMS via an ETSI QKD 004 interface and employs distinct key management logic. App004 maintains a key queue for each established key stream session. It also tracks the key streams, denoted by KSID, for encryption and authentication. Before the application can begin secure communications, the queues must accumulate the desired amount of key material. Once formed, the queues are synchronized by sending a new GET_KEY request to replenish the queue when a key is removed (i.e., the key’s lifetime has expired). This design was inspired by the ideas presented in [Mar2015] for upgrading the IPsec protocol with QKD-derived keys [Der2021].

Fig.9 QKDNetSim Sequence diagram - QKDApp 004 application

To implement the ETSI QKD 004 interface [ETSI004], we selected the HTTP protocol and JSON data structures as obvious choices since we had already incorporated a variant of the HTTP protocol and combined it with JSON data formats. We used the same URI format defined in the ETSI QKD 014 standard. On the application link, two additional methods are defined, CONNECT and ESTABLISH_QUEUES, which address the necessary method mentioned in the standard itself, SEND_KSID. The latter is applied to signal the beginning and end of the queue establishment phase, after which the application can begin secure communications. These methods are implemented using the HTTP protocol, and both apply the GET method to submit requests. The CONNECT request includes the KSID value and the scope of the session in the URI, whereas ``ESTABLISH_QUEUES``consists of no additional parameters because it is presumed that the size of queues is known in advance by both peers. It is important to note that QKDNetSim currently does not permit the installation of App004 pairs on arbitrary nodes; it is only allowed on adjacent nodes.

Examples

The examples are in the src/qkd/examples/ directory. Copy file qkd_etsi_014.cc from src/qkd/examples/ to scratch and execute

$ ./ns3 configure --enable-mpi

If you wish to obtain more detailed info about the work of some particular module you can execute NS_LOG commands to track code execution. In example:

$ export NS_LOG=QKDApp:QKDKeyManagerSystemApplication

Start the example scripts

$ ./ns3 configure --enable-mpi
$ ./ns3 --run scratch/qkd_etsi_014.cc

The output result should be:

SystemId: 0
Number of CPUs:   1
Number of QKD Links: 1
Number of ETSI 014 Application Links:  1
Number of Nodes:  8

SrcKMSNode: 1 Source KMS IP address: 10.1.0.1
DstKMSNode: 2 Destination KMS IP address: 10.1.0.2

*********
*** Post-Processing Configuration
*********
randomNumber: 1957747793
QKD link: 4-5
SrcNode: 4 Source IP address: 10.1.5.1
DstNode: 5 Destination IP address: 10.1.5.2
SrcKMSNode: 1 Interface to Alice KMS IP address: 10.5.1.1
DstKMSNode: 2 Interface to Bob KMS IP address: 10.5.2.1
ppKeySize: 2048
ppKeyRate: 150000
ppPacketSize: 350
ppRate: 2500

*********
*** ETSI 014 Configuration
*********
randomNumber: 719885386
Alice NodeId: 6 Alice App IP: 10.1.7.1
Bob NodeId: 7 Bob App IP: 10.1.7.2
SrcKMSNode: 1 Interface to Alice KMS IP address: 10.7.1.1
DstKMSNode: 2 Interface to Bob KMS IP address: 10.7.2.1
EncryptionType: OTP
AuthenticationType: VMAC
AuthenticationType: 1
AESLifetime: 200000
AppRate: 500000
AppPacketSize: 300
NumberOfKeyToFetchFromKMS: 15
Start time: 33.4391
Stop time: 155
AliceQKDSystemOnNode:4
BobQKDSystemOnNode:5
Connections.size():2
Connection[0]:145b11b3-d0f4-4d81-be28-569b10f98ab9
Connection[1]:3e7c2b57-36f0-4660-bd16-f3512ccfc9a7

simTime: 50
appStartTime:  30
appStopTime:   155
qkdStartTime:  10
qkdStopTime:   155
useCrypto:  1
trace:   0
**********************************

QKD Application Entry  (etsi_014): 145b11b3-d0f4-4d81-be28-569b10f98ab9
Nodes:   6-7
Encryption: "OTP"
Authentication:   "Unauthenticated"
Packet Size (bytes): 300
Traffic Rate (bit/sec): 500000
QoS Priority:  0
QoS TTL: 0
QoS ChunkSize: 300
QoS Requested ChunkKeys:   0
QoS Available ChunkKeys:   0
QoS Provided ChunkKeys: 0
Number of Keys to Fetch From KMS:   15
Missed send packet calls:  3451
Sent (bytes):  0  Received (bytes): 0
Sent (Packets):   0  Received (Packets):  0
Key/Data utilization (%):  0.0
Ratio (bytes): -nan  Ratio (packets):  -nan
Start Time (sec): 33
Stop Time (sec):  155

- Signaling stats:
Sent (bytes):  2730  Received (bytes): 2500
Sent (Packets):   4  Received (Packets):  3

- QKDApps to KMS stats:
Sent (bytes):  5539  Received (bytes): 21370
Sent (Packet): 10 Received (Packet):   10

- KMS to QKDApp stats:
Key-pairs consumed:  15
Key-pairs consumed (bits): 36000
Average size of consumed key-pairs (bits):   2400

**********************************

QKD Application Entry  (etsi_014): 3e7c2b57-36f0-4660-bd16-f3512ccfc9a7
Nodes:   6-7
Encryption: "Unencrypted"
Authentication:   "VMAC"
Packet Size (bytes): 300
Traffic Rate (bit/sec): 500000
QoS Priority:  0
QoS TTL: 0
QoS ChunkSize: 300
QoS Requested ChunkKeys:   0
QoS Available ChunkKeys:   0
QoS Provided ChunkKeys: 0
Number of Keys to Fetch From KMS:   0
Missed send packet calls:  0
Sent (bytes):  0  Received (bytes): 0
Sent (Packets):   0  Received (Packets):  0
Key/Data utilization (%):  0.0
Ratio (bytes): -nan  Ratio (packets):  -nan
Start Time (sec): 33
Stop Time (sec):  155

- Signaling stats:
Sent (bytes):  0  Received (bytes): 0
Sent (Packets):   0  Received (Packets):  0

- QKDApps to KMS stats:
Sent (bytes):  0  Received (bytes): 0
Sent (Packet): 0  Received (Packet):   0

- KMS to QKDApp stats:
Key-pairs consumed:  15
Key-pairs consumed (bits): 1920
Average size of consumed key-pairs (bits):   128

**********************************

QKD key association link entry: 72e421cc-0a79-4d81-b258-2fbb4de52fd7
Nodes:   4-5
QKDBuffer Capacity (bits): 1000000
Link distance (meters):    0
Key rate (bit/sec):     150000
Key-pairs generated: 552   Key-pairs generated (bits):   1077248
Key-pairs consumed:  30 Key-pairs consumed (bits): 37920
Avg size of generated keys (bits):  1951
Avg size of consumed keys (bits):   1264
Start Time (sec):    30
Stop Time (sec):     155

elapsed process CPU time = 14117039022 nanoseconds

The output results show that the simulation included one QKD link between nodes 4 and 5 and one QKDApp014 between nodes 6 and 7. Since QKDApp014 included encryption (OTP) and authentication (VMAC), QKDNetSim implemented two independent sessions (145b11b3-d0f4-4d81-be28-569b10f98ab9 and 3e7c2b57-36f0-4660-bd16-f3512ccfc9a7) to peer KMSs to fetch needed keys. The results show the amount of key fetched, consumed, and exchanged signaling packets between QKD network entities.

You can plot and analyze the output graphs using gnuplot:

$ gnuplot *.plt

Scope and Limitations

What can it not do:

• At the moment, QKD Post-processing application simulates QKD AIT Post-processing application. That is, no real QKD protocol (BB84, B92 or other) is implemented in QKDNetSim.

• At the moment, QKDNetSim module v2.0 does not support key-relay KMS funcionality.

• QKDNetSim at the moment only supports IPv4 addresses

Troubleshooting

Please double-check that the Crypto++ library is installed correctly.

References

• Meh2023

  Mehic, M. et al., 2023. Quantum cryptography in 5g networks: A comprehensive overview. IEEE Communications Surveys & Tutorials. doi: https://doi.org/10.1109/COMST.2023.3309051

• Meh2020

  Mehic, M. et al., 2020. Quantum key distribution: a networking perspective. ACM Computing Surveys (CSUR), 53(5), pp.1-41., doi: https://doi.org/10.1145/3402192

• ITU3801

  ITU-T Y.3801, “Functional requirements for quantum key distribution networks,” (2020)

• ITU3802

  ITU-T Y.3802, “Quantum key distribution networks – Functional architecture,” (2020).

• ITU3803

  ITU-T Y.3803, “Quantum key distribution networks – Key management,” (2020).

• Meh2017

  Mehic, M. et al., 2017. Implementation of quantum key distribution network simulation module in the network simulator NS-3. Quantum Information Processing, 16, pp.1-23. doi: https://doi.org/10.1007/s11128-017-1702-z.

• ETSI004

  ETSI GS QKD 014, “Quantum key distribution (qkd); protocol and data format of rest-based key delivery api,” (2019).

• ETSI014

  ETSI GS QKD 004, “Quantum key distribution (qkd); application interface,” (2020)

• Mar2015

  Marksteiner, S. and Maurhart, O., 2015, August. A protocol for synchronizing quantum-derived keys in IPsec and its implementation. In 9th Int. Conf. Quantum, Nano/Bio, and Micro Technologies (pp. 35-40).

• Der2021

  Dervisevic, E. and Mehic M., 2021. Overview of Quantum key distribution technique within IPsec architecture. In Proceedings of the 18th International Conference on Information Systems for Crisis Response and Management ISCRAM 2021, (ACM, 2021), pp. 1–10

• Der2024

  Dervisevic, E., Voznak, M. and Mehic, M., 2024. Bases selection with pseudo-random functions in BB84 scheme. Heliyon, 10(1). doi: https://doi.org/10.1016/j.heliyon.2023.e23578

Cite

Dervisevic, E., Voznak, M. and Mehic, M., 2024. Large-Scale Quantum Key Distribution Network Simulator. Journal of Optical Communications and Networking, doi: https://doi.org/doi.org/10.1364/JOCN.503356