Quantum Key Distribution Simulation Using Qiskit Python — Complete Documentation & Simulation

Overview & System Context

Quantum Key Distribution Simulation Using Qiskit Python: Comprehensive Web-Sourced Technical Investigation Exhaustive Research Dossier · Pure Web-Scraped Content: ~9500 Words · Real Software Screenshots: 3 1. Executive Overview & Technical Background Qiskit (Quantum Information Software Kit) is an open-source, Python-based, high-performance software stack for quantum computing, originally developed by IBM Research and first released in 2017. It provides tools for creating quantum programs (by defining quantum circuits and operations) and executing them on quantum computers or classical simulators. The name "Qiskit" refers broadly to a collection of quantum software tools. It is centered around the core Qiskit SDK, and combined with a suite of tools and services for quantum computation, like the Qiskit Runtime service that enables optimized computations through the cloud. Qiskit allows users to write quantum circuits and execute them on real quantum processors (such as superconducting qubit systems) or on various other compatible quantum devices. Over time, Qiskit’s capabilities have expanded with new components and improvements, such as Qiskit Functions and Qiskit addons, while maintaining an open-source ecosystem for quantum computing research and application development.

Parallelize classical tasks that are part of a quantum workflow, such as preIprocessing of input data or postIprocessing of quantum results. By distributing these classical computations to cloud resources, users can speed up overall execution when working with many circuits or large datasets in tandem with quantum hardware. Persist long-running workloads in the cloud, allowing quantum jobs to continue executing and collecting results even if the user’s local environment (e.g., a laptop) is offline. This means a researcher can start a complex quantum experiment and not worry about maintaining a constant connection; the serverless system will handle the execution and retain the results until the user retrieves them. Deploy reusable programs (quantum applications or algorithmic routines) on the IBM Quantum Platform to invoke as needed. This turns custom quantum algorithms into services, enabling collaboration and reuse: for example, an optimization algorithm or a chemistry simulation routine could be uploaded once and then repeatedly executed with different parameters on demand. By abstracting away the details of managing cloud resources, Qiskit Serverless aims to make it easier to scale up quantum experiments and integrate them into larger computing workflows.

Approximate Quantum Compilation (AQC) – qiskit-addon-aqc-tensor. AQC uses tensorInetwork methods to compress a segment of a quantum circuit into a shorter equivalent circuit with high fidelity. MultiIProduct Formulas (MPF) – qiskit-addon-mpf. MPF reduces Trotter error in Hamiltonian simulations by combining the results of multiple circuit executions in a weighted formula. Operator Backpropagation (OBP) – qiskit-addon-obp. OBP shortens circuit depth by trimming off the final set of gate operations and compensating through additional measurements on the remaining circuit. SampleIbased Quantum Diagonalization (SQD) – qiskit-addon-sqd. SQD is a postIprocessing tool that classically analyzes bitstring samples from quantum circuit runs to estimate eigenvalues and eigenvectors of large operators (such as molecular Hamiltonians) more accurately under noise. Each of these add-ons is maintained as an open-source extension in the GitHub Qiskit organization, with documentation and tutorials provided by IBM Quantum. This modular approach allows researchers to opt into advanced algorithmic techniques as needed, keeping Qiskit’s core lightweight while still enabling cutting-edge features through add-ons.

Qiskit Aer (qiskit-aer) – A highIperformance simulator for quantum circuits, featuring multiple simulation backends and support for realistic noise models. It is maintained by IBM Quantum as the official simulation engine for Qiskit and is frequently used to validate algorithms before running on actual quantum processors. qBraid SDK (qbraid) – A platformIagnostic quantum runtime and cloud management framework that streamlines the full lifecycle of quantum jobs. Developed and maintained by the company qBraid, this tool abstracts away much of the complexity in managing quantum computing workloads across different providers, complementing Qiskit’s development tools with cloud deployment capabilities. mthree (mthree) – A library for MatrixIfree Measurement Mitigation (M3) that improves the accuracy of qubit measurement outcomes on real hardware. This IBM QuantumIdeveloped package tackles readout errors by constructing a reduced model of the noise in the measurement process and then solving for corrected outcome probabilities without needing to invert large calibration matrices. Through such ecosystem projects, Qiskit users can access extended functionality that is not included in the core SDK, thereby enhancing research and application development. For example, Aer enables thorough testing of algorithms in simulation, qBraid facilitates running Qiskit programs on diverse cloud hardware, and mthree helps in obtaining more accurate experimental data. A comprehensive catalog of Qiskit ecosystem projects is available on the Qiskit Ecosystem page, where users can discover other tools and libraries (and even contribute their own) that work in conjunction with Qiskit.

All these ecosystem efforts contribute to a more versatile and robust quantum computing toolkit centered around Qiskit. Figure 1: Created my first quantum circuit using Qiskit | Adwaitha V posted on ... Quantum programming refers to the process of designing and implementing algorithms that operate on quantum systems, typically using quantum circuits composed of quantum gates, measurements, and classical control logic. These circuits are developed to manipulate quantum states for specific computational tasks or experimental outcomes. Quantum programs may be executed on quantum processors, simulated on classical hardware, or implemented through laboratory instrumentation for research purposes. When working with quantum processor-based systems, quantum programming languages provide high-level abstractions to express quantum algorithms efficiently. These languages often integrate with classical programming environments and support hybrid quantum-classical workflows. The development of quantum software has been strongly influenced by the open-source community, with many toolkits and frameworks—such as Qrisp, Qiskit, Cirq, PennyLane, and qBraid SDK—available under open licenses. Quantum programming can also be used to model or control experimental systems through quantum instrumentation and sensor-based platforms. While some quantum computing architectures—such as linear optical quantum computing using the KLM protocol—require specialized hardware, others use gate-based quantum processors accessible through software interfaces. In both cases, quantum programming serves as the bridge between theoretical algorithms and physical implementation.

OpenQASM is the intermediate representation introduced by IBM for use with Qiskit and the IBM Quantum Platform. Quil is an instruction set architecture for quantum computing that first introduced a shared quantum/classical memory model. It was introduced by Robert Smith, Michael Curtis, and William Zeng in A Practical Quantum Instruction Set Architecture. Many quantum algorithms (including quantum teleportation, quantum error correction, simulation, and optimization algorithms) require a shared memory architecture.

An open source project developed by Google, which uses the Python programming language to create and manipulate quantum circuits. Programs written in Cirq can be run on IonQ, Pasqal, Rigetti, and Alpine Quantum Technologies. Figure 2: Sneha Patil - Software Engineer Portfolio An open source project developed by IBM. Quantum circuits are created and manipulated using Python. Results are obtained either using simulators that run on the user's own device, simulators provided by IBM or prototype quantum devices provided by IBM. As well as the ability to create programs using basic quantum operations, higher level tools for algorithms and benchmarking are available within specialized packages. Qiskit is based on the OpenQASM standard for representing quantum circuits. It also supports pulse level control of quantum systems via QiskitPulse standard.

Qrisp is an open source project coordinated by the Eclipse Foundation and developed in Python programming by Fraunhofer FOKUS Qrisp is a high-level programming language for creating and compiling quantum algorithms. Its structured programming model enables scalable development and maintenance. The expressive syntax is based on variables instead of qubits, with the QuantumVariable as core class, and functions instead of gates. Additional tools, such as a performant simulator and automatic uncomputation, complement the extensive framework. Furthermore, it is platform independent, since it offers alternative compilation of elementary functions down to the circuit level, based on device-specific gate sets.

In Guppy, qubits are linear types, and the compiler tries to enforce linearity (preventing qubits from being leaked or copied, for example). The Guppy compiler is packaged with an emulator. Programs are compiled to an intermediate representation called HUGR, suitable for submission to Quantinuum's quantum devices. The computation process is executed using a provided simulator. Noisy environments can be simulated using parameters of the simulator.

Figure 3: Quantum Computing with QisKit and Raspberry Pi's - Project help ... Quantum Computation Language (QCL) is one of the first implemented quantum programming languages. The most important feature of QCL is the support for user-defined operators and functions. Its syntax resembles the syntax of the C programming language and its classical data types are similar to primitive data types in C. One can combine classical code and quantum code in the same program.

Quipper was published in 2013. It is implemented as an embedded language, using Haskell as the host language. For this reason, quantum programs written in Quipper are written in Haskell using provided libraries. For example, the following code implements preparation of a superposition IBM Quantum Platform (previously known as IBM Quantum Experience) is an online platform allowing public and premium access to cloud-based quantum computing services provided by IBM. This includes access to a set of IBM's quantum processors, a set of tutorials on quantum computation, and access to interactive courses. As of June 2025, there are 12 devices on the service, all of which are freely accessible by the public. This service can be used to run algorithms and experiments, and explore tutorials and simulations around what might be possible with quantum computing. IBM's quantum processors are made up of superconducting transmon qubits, located in dilution refrigerators at the IBM Research headquarters at the Thomas J. Watson Research Center. Users interact with a quantum processor through the quantum circuit model of computation, typically through code written in Qiskit. This code can be compiled down to OpenQASM for execution on real quantum systems. Circuits can be created either graphically with the Quantum Composer, or programmatically through Jupyter notebooks on IBM's approved platforms for cloud-based quantum computing: qBraid and OVHCloud.

The Quantum Composer is a graphic user interface (GUI) designed by IBM to allow users to construct various quantum algorithms or run other quantum experiments. Users may see the results of their quantum algorithms by either running it on a real quantum processor or by using a simulator. Algorithms developed in the Quantum Composer are referred to as a "quantum score", in reference to the Quantum Composer resembling a musical sheet. The composer can also be used in scripting mode, where the user can write programs in the OpenQASM-language instead. Below is an example of a very small program, built for IBMs 5-qubit computer. The program instructs the computer to generate a quantum state | Ψ I = 1 2 ( | 000 I + | 111 I ) {\displaystyle |\Psi \rangle ={\frac {1}{\sqrt {2}}}\left(|000\rangle +|111\rangle \right)} , a 3-qubit GHZ state, which can be thought of as a variant of the Bell state, but with three qubits instead of two. It then measures the state, forcing it to collapse to one of the two possible outcomes, | 000 I {\displaystyle |000\rangle } or | 111 I {\displaystyle |111\rangle } .

Every instruction in the QASM language is the application of a quantum gate, initialization of the chips registers to zero or measurement of these registers. For this Qiskit in Classrooms module, students must have a working Python environment with the following packages installed: To set up and install the packages above, see the Install Qiskit guide. In order to run jobs on real quantum computers, students will need to set up an account with IBM Quantum® by following the steps in the Set up your IBM Cloud account guide.

This module was tested and used 5 seconds of QPU time. This is an estimate only. Your actual usage may vary. Watch the module walkthrough by Dr. Katie McCormick below, or click here to watch it on YouTube. There are infinitely many ways of encrypting and decrypting information, and literally thousands of ways have been well-studied. Here, we will restrict ourselves to a very early and very simple method of encryption, called "simple replacement", in order to focus on the quantum part of this protocol. The quantum part could be adapted to many other protocols with relatively few changes.

A simple replacement encryption is one in which one letter or number is replaced with another, such that there is a 1:1 mapping from the letters and numbers in a message, to the letters and numbers being used in an encrypted sequence. A pop-culture instance of these is the cryptoquote or cryptogram puzzle, in which a quote or phrase is encrypted using simple replacement, and the player is tasked with decrypting it. These are easy to solve if they are long enough. Consider the example: R WVXRWVW GSZG R’W YVGGVI NZPV GSRH KIVGGB OLMT. GSZG DZB, KVLKOV DROO SZEV ZM VZHRVI GRNV HLOERMT RG. R SLKV R NZWV RG HRNKOV VMLFTS.

People who solve these by hand mostly use tricks involving familiarity with the structure of the language of the original message. For example, in English, the only one-letter words like the encrypted "R" are "a" and "I". The double letters encrypted in, for example, "KIVGGB" can only take certain values. There are subtler things that give clues like the most common word fitting the "GSZG" pattern is "that". People using code to solve this have many more options, including simply scanning through possibilities until an English word is recovered, and updating while preserving that word. One simple but powerful method is using letter frequency, especially when the message is long enough to constitute a representative sample of English.

Try your hand at decrypting this if you like, though it is not necessary for the rest of the module. Click the "Answer" below to see the message. I decided that I’d better make this pretty long. That way, people will have an easier time solving it. I hope I made it simple enough.

The example above is associated with a "key", a mapping from the encrypted to the decrypted letters. In this case, the key is: And so on. To put it mildly, this is not a good key. Keys in which the encrypted and decrypted letters are simply shifted version of the alphabet (like A->B and B->C) are called "Caesar shift" ciphers. Note that these are very difficult if they are short. In fact, if they are very short, they are indeterminate. Consider: There are many possible decryptions, using different keys: HELLO, PETTY, HAPPY, JIGGY, STOOL. Can you think of others? But if you send many messages like this, eventually, the encryption will be cracked. So, you shouldn’t use the same “key” too often. In fact, best is if you use a certain substitution only once. Not in only one message, but only for one single character! By this, we mean you’ll have an encryption scheme or key for each character used in the message, in order. If you want to send a message to a friend using this message, you and your friend would need a pad a paper (in ye olden times) on which this ever-changing key is written. You will use this only once. This is called a “one-time pad”.

Let’s see how this works with an example. One could do this entirely with letters, but it is common to convert from letters to numbers, say, by assigning A=0, B=1, C=2…. Suppose we are friends involved in clandestine activities and we have shared a pad. Ideally, we would share many pads, but today’s is: We don’t want to send the above code; that is a simple substitution, which is not at all secure. We want to combine this with our key in some way. A common way is addition modulo 26. We add the value of the message to the value of the key, mod 26, until we reach the end of the message. So, we would send Note that if someone intercepts this and does NOT have the key, decrypting it is utterly hopeless! Not even the two “u”s in "quantum" are encoded with the same number! The first is a 3, and the second is a 16… in the same word! So, I send this to you, and you have the same key I do. You undo the addition modulo 26 which you know I carried out: Note that if the key is shorter than the message, we start to repeat our encoding. That would still be a hard decryption problem to solve, but not impossible if it is repeated enough times. So, you need a long key (or “pad”).

In many contexts, students will already be familiar with this encryption, such that this activity can be skipped. But it is a relatively quick, simple refresher. Step 1: Get a partner, and share a sequence of 4 letters to use as a key. Any class-appropriate 4-letter sequence will do. Step 2: Select a 4-letter secret word you want to send to your partner (both partners do this so you send each other different secret words) Step 3: Convert the 4-letter key/pad and each of the 4-letter secret words to numbers using A = 1, B = 2, and so on.

Step 4: Combine your 4-letter word with the one-time pad using modulo 26 addition. Step 5: Hand your partner the sequence of numbers encoding your secret word, and your partner will hand you theirs. Step 6: Decode each other’s words using modulo 26 subtraction. Step 7: Verify. Did it work? 2. System Architecture & Core Working Principles Swap encrypted words with a different group, that does not have access to your one-time pad. Can you decrypt it? Explain why or why not? Hopefully the activity above makes it clear that a one-time pad is an unbreakable form of encryption, given a few assumptions, like: So this is great. We have unbreakable encryption... unless someone gets our key. If someone gets our key, everything is decrypted. This difference between unbreakable encryption and having all our secrets exposed makes the sharing of a secure key extremely important. The goal of quantum key distribution is to leverage constraints that nature has imposed on quantum information to secure a shared key/one-time pad.

Let's assume we are working with qubits (emphasizing that qubits have two eigenstates). One could use quantum systems with higher numbers of quantum states, but the state-of-the-art quantum computers at IBM® use qubits. It’s no problem to encode our A, B, C, into sequences of 0’s and 1’s. So, it is sufficient for us to share a key of 0’s and 1’s and do addition modulo 2 on each bit storing a letter.

Our friends, Alice and Bob would like to share a quantum key in such a way that no one else can intercept it (at least not without them knowing). They need to have a way of sending quantum states to each other. Doing this with high fidelity and no noise/errors is NOT trivial. But there are two approaches tha we should be able to understand at this point: For this module, we don't want to require you to have high-fidelity optic setups for sharing photons, so we will use the second method for sharing quantum states. But this is not to say that it is the most realistic for long-distance sharing of quantum keys.

We will now explore a protocol first laid out by Charles Bennett and Gilles Brassard in 1984 for sharing states measured in different bases from Alice to Bob. We will use a clever measurement regimen to build up a key for use in later encryption. In other words, we are distributing a quantum key between two parties who wish to communicate, hence "quantum key distribution" (QKD).

Alice will start out by generating a random sequence of 0's and 1's. She will then randomly select a basis in which to prepare a quantum state, based on each random bit, using the table below (a table that Bob also has): For example, let us suppose Alice randomly generated a 0, and randomly selected the X basis. Then she would prepare a quantum state I ψ I = I + I x = 1 2 ( I 0 I + I 1 I ) |\psi\rangle = |+\rangle_x = \frac{1}{\sqrt{2}}(|0\rangle+|1\rangle) I ψ I = I + I x I = 2 I 1 I ( I0 I + I1 I) . One can certainly leverage quantum randomness to generate a random set of 0's and 1's, and a random basis choice. For now, let's simply assume a random set has been generated, as follows: This set of random bits, bases, and resulting states would continue in a long sequence, to give a key of sufficient length.

Bob also makes a random choice of bases. However, whereas Alice was using the basis choice to prepare her state, Bob will actually make measurements in these bases. If Bob makes a measurement in the same basis in which Alice prepared the the state, then we can predict the outcome of Bob's measurement. When Bob happens to pick a different basis from the basis Alice used in preparation, we cannot know the outcome of Bob's measurement.

In the table below, consider the first column. Alice has prepared the state I + I \vert +\rangle I + I , which is an eigenstate of X. Since Bob has also randomly chosen to measure in the X basis, there is only one possible outcome for Bob's measured state: I + I \vert +\rangle I + I . In the second column, however, they have chosen different bases. The state Alice sent is I − I = 1 2 ( I 0 I − I 1 I ) \vert -\rangle = \frac{1}{\sqrt{2}}(\vert 0\rangle-\vert 1 \rangle) I − I = 2 I 1 I ( I0 I − I1 I) .

This has a 50% chance of being measured by Bob in the I 0 I \vert 0\rangle I0 I state, and a 50% chance of being measured in I 1 I \vert 1\rangle I1 I . So the row showing what we know, a priori, about Bob's measurements cannot be filled in for column 2. But Bob will make a measurement and obtain an eigenstate of (in that column) Z. In the bottom row, we fill in what these measurements happened to yield.

Alice and Bob can now share with each other what basis they chose in each case. For all the columns in which they happened to choose the same basis, they each know for certain what state the other had. Bob can convert the state and basis to a 0 or 1 according to the convention shared by both parties. We can rewrite the table above to show only the instances where Alice's and Bob's bases matched: Alice has successfully transmitted the bit string 00100... to Bob. If the friends agreed ahead of time to use 5-bit strings as numbers in their one-time pad, these first five bits would give them the number 4 = 0 × 2 4 + 0 × 2 3 + 1 × 2 2 + 0 × 2 1 + 0 × 2 0 4 = 0\times2^4+0\times2^3+1\times2^2+0\times2^1+0\times2^0 4 = 0 × 2 4 + 0 × 2 3 + 1 × 2 2 + 0 × 2 1 + 0 × 2 0 .

Before Alice and Bob go any further, they should choose a subset of their classical bits to compare. Since they have only kept measurements of qubits which were prepared and measured using the same basis, all the measured values should agree. If there were a very small percentage that did not agree, this could be attributable to quantum noise or errors. But if many do not agree, something has gone wrong! Here we will not address what fraction of the key should be used for verification. For now, we will assume that this check goes well; we will revisit this in the section below on eavesdropping.

The friends would then send an encrypted message to each other using classical channels. They would then use the numbers in their one-time pad to encrypt/decrypt secret messages, without ever transmitting the one-time pad from one location to another. For the next section on eavesdropping, please keep in mind that all this sharing of the key happens prior to the revelation of the encrypted secret via classical channels.

Alice and Bob communicated their basis of choice via classical channels, so couldn't that be intercepted? Yes! But knowing the basis they used for measurement does not tell you what bit they sent or obtained. That is only possible if you also know Alice's starting bits. But then you would be in Alice's computer, where the secrets are stored, and secret communication of the secrets becomes moot. So interception of the classical communication does not break the encryption. But what about intercepting information in the quantum channel? Alice and Bob have a friend Eve, who is notorious for eavesdropping. Eve wishes to intercept Alice's and Bob's quantum key, so that she may use it to decrypt messages sent between the two. This would necessarily happen between Alice's preparation of the states and Bob's measurement of the states, since the measurement collapses the quantum state. In particular, this means the eavesdropping would have to occur before there has been any sharing or comparison of bases.

Eve must guess which base was used in encoding each bit. Again, if she is not able to access Alice's computer, she has nothing on which to base this guess, and it will be random. Let us assume Alice's start is the same as before, and let us further assume that Bob's random choice of measurement basis is the same as before. Let's fill in what Eve obtains if she makes measurements of the quantum channel. As before, if Eve happens to choose the same basis as Alice, we know what she will obtain. If not, she could obtain either of two outcomes, each with a 50% probability.

Now because Eve has no idea whether she matched Alice's basis or not, she does not know what to transmit on to Bob to match Alice's original states. When Eve measures, for example, I 0 I |0\rangle I0 I , all she knows for certain is that Alice did not prepare the state I 1 I |1\rangle I1 I for that qubit. But Alice could have prepared I 0 I |0\rangle I0 I , I + I |+\rangle I + I , or I − I |-\rangle I − I . All could be consistent with Eve's measurement. So Eve must make a choice. She might send on exactly the state she measured, or she might try to guess instances in which her measurement was not the eigenstate sent by Alice. We will include a mixture in our table: At this point, it is reasonable to ask, "Why doesn't Eve just make a copy of Alice's quantum state, keep one to measure, and transmit the other on to Bob?" The answer is the "no-cloning" theorem . Informally, it says that there is no unitary (quantum mechanical) operation that can make a second copy of an arbitrary quantum state, while preserving the first copy. The proof is relatively simple, and is left as a guided exercise. But for now, understand that Eve making copies of the quantum state is forbidden by fundamental laws of nature, and this is a principle strength of QKD.

As before, Alice and Bob would call each other and compare bases. They will reduce this table to the cases where the two friends selected the same bases: Alice and Bob have once again communicated a bit string... but the strings don't match. The far left and middle bits are flipped. Looking at the previous table, you can trace this mismatch to the interference from Eve. Critically, note that we can do statistics on the match between our bitstrings now, while setting up the key, long before sharing our encrypted secret. Alice and Bob are free to use as many of their one-time pad bits as they like to check the security of their channel. If a single bit, or a very small percentage of bits did not match, this might be attributable to noise or errors. But a substantial fraction of mismatches indicates eavesdropping. The meaning of "substantial" here depends a bit on the noise in the setup being used; what is means for IBM® quantum computers is discussed below when we implement this protocol. If excess errors are detected, Alice and Bob do not share the secret, and they can begin hunting the eavesdropper.

Proving security is extremely difficult. In fact the protocol loosely described here was proposed in 1984, and wasn't proved secure until 16 years later Shor & Preskill, 2000 . There are many subtleties that are beyond the scope of this introduction. But we will briefly list a few to demonstrate that the topic is more complex than illustrated here. Let us implement the above protocol in the absence of an eavesdropper. We will do this first using a simulator, simply to understand the workflow.

First, a note on quantum simulators: Most quantum problems involving more than ~30 qubits cannot be simulated by most computers. No classical computer, supercomputer or GPU can simulate the full range of behavior of a 127-qubit quantum computer. Usually, the motivation for using real quantum computers is that the many entangled qubits cannot be simulated. In this case, there is no entanglement of qubits, unless we use the teleportation scheme to move information. In this case, the motivation for using real quantum computers is different: it is the no-cloning theorem. A classical computer simulating a qubit could send information about a quantum state from Alice to Bob, but if this classical information were intercepted, it could easily be duplicated, and Eve could keep a perfect copy, while sending another to Bob. This is not possible with real quantum states.

IBM Quantum recommends tackling quantum computing problems using a framework we call "Qiskit patterns". It consists of the following steps. In this case, the mapping of our problem to quantum circuits reduces to simply preparing Alice's states, and then including Bob's measurements. We start with the random bit and random basis selection.

Let's visualize the bits, bases, and circuit. Note that sometimes the bases match, and sometimes they do not. This step takes the operations we want to perform and expresses them in terms of the functionality of a specific quantum computer. It also maps our problem onto the layout of the quantum computer. We will start by loading several packages that are required to communicate with IBM quantum computers. We must also select a backend on which to run. We can either choose the least busy backend, or select a specific backend whose properties we know. Although we will momentarily use a simulator, it is important to use a reasonable noise model in simulation, and it is good to keep the workflow as close as possible to what we will use later for real quantum computers.

There is code below for saving your credentials upon first use. Be sure to delete this information from the notebook after saving it to your environment, so that your credentials are not accidentally shared when you share the notebook. See Set up your IBM Cloud account and Initialize the service in an untrusted environment for more guidance. Here we interpret our results and extract useful information. We might try visualizing the output of our sampler, but we have used sampler in an unconventional way. Rather than making many measurements of our circuit and developing statistics on the states, we have made only one measurement (Bob's). Any qubit with a state that was prepared and measured in the same basis should have a deterministic outcome, such that only one measurement is necessary. Those qubits with states prepared and measured in different bases (which would have probabilistic outcomes and would require many measurements to interpret) will not be used to build up our one-time pad/key.

Let us extract a list of measurement outcomes from this bitstring. Take care to reverse the order if comparing with Alice's bit array we used to generate the circuit. Let's compare the measurement bases randomly chosen by Alice and Bob. This was step 3 in our QKD protocol (public discussion of bases). Any time they chose the same basis for a qubit, we add the bits associated with that qubit to a list of bits for generating numbers in a one-time pad. When the bases do not match, the results are thrown out. Let us also check to see the two lists of bits agree, or if there were any losses due to noise or other factors.

Alice and Bob each have a list of bits, and they match with 100% fidelity. They can use these to generate numbers in a one-time pad. They can then use this in QKD step 4: sending and decrypting a secret. The present array of bits is too short to decrypt much of anything. We will return to this after including eavesdropping. Assume you need digits large enough to facilitate shifting letters in the English alphabet by that alphabet's full length, or more, although there are certainly other encoding schemes. (a) How many letters long could a message be for it to be decrypted using the bits in the key above? (b) Must your answer agree with your classmates'? Why or why not? (a) The answer depends on how many randomly-chosen bases matched between Alice and Bob. Since there is roughly a 50-50 chance of the bases matching for any given qubit, we expect close to 10 of our bits to be useful. 9 or 11 will be perfectly common. Even 4 or 15 are not outside the realm of possibility. 5 bits are required to shift by a number greater than or equal to the length of the English alphabet, meaning you can apply the shift to one letter for every 5 bits you have. If you have at least 5 bits shared by Alice and Bob, you can encode a single letter. If you have at least 10, you can encode 2 letters, and so on.

3. Software Implementation, Frameworks & Protocols We will implement exactly the same protocol as before. This time, we will insert another set of measurements, by Eve, between Alice and Bob. Qiskit patterns step 4 (post-processing) is simple in this case. There is no need to visualize the distribution of measurements, since we made only one measurement. Eve has the following bits: Now Eve must reconstruct states to send on to Bob. A described in the introduction, she has no way of knowing if she guessed the encoding bases correctly, so she is not able to prepare exactly the same states that were sent. She could assume every basis choice was correct and encode exactly what she measured, or she could assume she chose the basis incorrectly and choose either eigenstate of the opposite basis. Here, we assume the former, for simplicity. We accomplish this by constructing a whole new quantum circuit, repeating Qiskit patterns steps as before.

Previously, there was a perfect match between the bits in Alice's and Bob's keys. Now, from Eve's interference, we see the bits of Alice and Bob are different in 14% of cases that should match due to Alice and Bob selecting the same bases. This should be easy for Alice and Bob to detect. However, relying on a percentage of errors like this does mean that there is a limit to how much noise we can tolerate in the quantum channel.

Let's run this on a real quantum computer. That way we can leverage the no-cloning theorem. At the same time, real quantum computers have noise, and have higher error rates than classical computers. So let's compare loss in fidelity of our key bits with and without eavesdropping, to make sure the difference is detectable when using a real quantum comptuter. We'll start in the absence of eavesdropping: With no eavesdropping, we obtained 100% fidelity over this set of 127 trial bits, resulting in 55 matched bases and usable key bits. Now let's repeat this experiment with Eve listening in: Here we found almost 23% loss of fidelity in shared bits due to eavesdropping! This is very detectable! Note that transferring quantum information over long distances could still introduce additional noise and errors. Assuring that eavesdropping can be detected, even in the presence of noise, and even when Eve uses all tricks at her disposal is a complex field beyond this introduction.

Instructors can request versions of these notebooks with answer keys and guidance on placement in common curricula by filling out this quick survey on how the notebooks are being used. Assume all basis choices are random for all participants, Alice, Bob, and Eve. Assume that after Eve listens in, she sends a state to Bob that is prepared in the same basis in which she measured, and which is consistent with that measurement.

Convince your partners that 12.5% of all qubits initialized by Alice will yield measurement mismatches between Alice and Bob, indicating eavesdropping (ignoring quantum errors and noise). Hint 1: Since there is no preferred basis, if you consider just one initial choice for Alice, the ratio for that one choice should be the same as the ratio for the sum of all choices. Hint 2: It may not be sufficient to count the number of ways something could happen, since some outcomes may occur with different probabilities.

Assume again that all basis choices are random for all participants, Alice, Bob, and Eve. But now, consider that Eve is free to send along any state she likes after her measurement. She could even try sending states that are inconsistent with her own measurements. Discuss with your partners/neighbors whether you think there is any choice of bases that could reduce the average percentage of qubits that indicate eavesdropping to Alice and Bob.

A Python and Qiskit based implementation of a simulated quantum key distribution (QKD) protocol , inspired by concepts such as BB84. This project was originally created during IBM's QxQ Coding School quantum computing course and demonstrates secure key exchange, basic encryption, and eavesdropper detection. Quantum Key Distribution allows two parties to establish a shared secret key using quantum mechanical principles. This project simulates the process with: Simulated Quantum Key Distribution (QKD) Protocol implementation in Python and Qiskit, created during IBM's QxQ Coding School Quantum Computing course. Showcases key distribution and eavesdropper interception scenarios in secure communications.

Welcome to the documentation for Qiskit , its related packages, and IBM Quantum® Platform. This documentation includes how-to guides to get you started on our tools, specific use-case tutorials that include end-to-end examples, and a collection of API references. Qiskit provides a modular and extensible framework for quantum research and development across algorithms, high-performance computing, and quantum information science. With it, researchers can build, optimize, and execute quantum workflows with specialized addons , software tools, and extensive resources. Through IBM Quantum Platform, users can access IBM Quantum Compute Service and the Qiskit Functions Catalog to run workloads efficiently on the IBM® fleet of quantum computers.

Beyond Qiskit and its related packages is the Qiskit ecosystem , a catalog of open-source projects that interface with Qiskit to extend its functionality. Explore curated sequences of learning, documentation, and tutorial content designed to facilitate knowledge and skill-building in specific interest areas.

Construct high-fidelity circuits with reduced depth that are ready for execution with the Qiskit SDK transpiler. Explore the available error mitigation and suppression techniques available from IBM Quantum. Refine your results by using post-processing techniques for specialized applications available as Qiskit addons. Accelerate quantum workload creation with pre-built tools created by partner organizations.

Find answers to frequently-asked questions, learn how to report bugs, discover communities to join, and more. A comprehensive Python simulation of the BB84 protocol using Qiskit, demonstrating secure key exchange, eavesdropper detection, and the impact of quantum noise. This project was developed for the Qiskit Hackathon. It provides an end-to-end simulation of the BB84 Quantum Key Distribution protocol, a foundational method for establishing information-theoretically secure communication channels.

To run this project, first clone the repository (or download the files) into a local directory. Then, install the necessary Python packages using the requirements.txt file. # Create and activate a virtual environment (optional but recommended) python -m venv qiskit_env source qiskit_env/bin/activate # On Windows, use `qiskit_env\Scripts\activate` The notebook will automatically execute all simulation scenarios, print the results, and display the corresponding plots inline.

The primary goal of this project was to create a fully functional and educational simulation of the BB84 Quantum Key Distribution protocol. My approach was centered around clarity, reproducibility, and fulfilling all requirements of the hackathon prompt. The complete, commented implementation can be found in the bb84_notebook_complete.ipynb file.

A key part of the logic is the simulation of the qubit exchange, which handles the presence of an eavesdropper: def simulate_exchange(self, eavesdropper_present=False): """Simulates the qubit exchange between Alice and Bob.""" self.bob_results = [] for i in range(self.key_length): qc = QuantumCircuit(1, 1) encode_qubit(qc, self.alice_bits[i], self.alice_bases[i]) The simulations successfully demonstrated the principles of the BB84 protocol. The key results are summarized below: The main challenge encountered during development was related to Qiskit's evolving package structure.

A comprehensive Python simulation of the BB84 protocol using Qiskit, demonstrating secure key exchange, eavesdropper detection, and the impact of quantum noise. In 2026, quantum computers capable of breaking RSA-2048 in hours will exist in research labs. Are your communications prepared? Quantum Key Distribution (QKD) offers information-theoretic security guaranteed by the laws of physics, not computational complexity. By 2030, QKD networks will form the backbone of global financial systems, government communications, and critical infrastructure. This guide shows you how to implement QKD in Python using Qiskit today, preparing you for the quantum-secured communications landscape of tomorrow.

This prevents eavesdroppers from copying quantum states without introducing detectable disturbances. Note: In a real implementation, error correction and privacy amplification would follow the sifting phase to extract a secure key even with small error rates. Quantum Key Distribution represents a paradigm shift in cryptographic security. Unlike classical public-key cryptography, which relies on the computational difficulty of problems like integer factorization, QKD's security is guaranteed by the fundamental laws of quantum physics. The no-cloning theorem ensures that an eavesdropper cannot copy quantum states without introducing detectable disturbances, while the Heisenberg uncertainty principle prevents perfect measurement of conjugate variables simultaneously.

The BB84 protocol, developed by Bennett and Brassard in 1984, remains the most practical QKD implementation. It encodes information in the polarization states of single photons, using two mutually unbiased bases (rectilinear and diagonal) to detect eavesdropping through increased error rates. 4. Practical Deployment, Analysis & Case Studies Below is a complete Python implementation of the BB84 protocol using Qiskit, demonstrating the fundamental principles of quantum key distribution.

The basic BB84 protocol is vulnerable to photon number splitting (PNS) attacks when using practical photon sources that sometimes emit multiple photons. The decoy state protocol, proposed by Hwang in 2003 and refined by Lo, Ma, and Chen in 2005, solves this by randomly varying the intensity of laser pulses to detect PNS attacks. By 2027, decoy state QKD will be standard in commercial systems, enabling secure key distribution over 100+ km of optical fiber. The protocol works by transmitting three types of pulses: signal states (µ), decoy states (ν), and vacuum states (0). An eavesdropper cannot distinguish between these states, making PNS attacks detectable through statistical analysis of detection rates.

This implementation extends the basic BB84 protocol with decoy states for enhanced security against photon number splitting attacks. Understanding the performance characteristics of QKD compared to classical cryptographic methods is crucial for deployment decisions in the 2026-2030 timeframe. While QKD offers information-theoretic security, it comes with distinct performance trade-offs that must be carefully considered.

The development of QKD technology follows a clear trajectory toward higher performance, lower costs, and broader integration with existing communication infrastructure. Understanding this roadmap is essential for planning secure communication systems that will remain viable through 2030 and beyond. The relationship between quantum computing and QKD is complex and symbiotic. While quantum computers threaten classical cryptography, they also enable more advanced QKD protocols and quantum networks. Understanding this dual impact is crucial for future-proof security architectures.

As Artificial General Intelligence capabilities emerge in the 2028-2030 timeframe, they will profoundly impact QKD systems in both implementation and security dimensions. AGI could either enhance QKD security or introduce new vulnerabilities, depending on how it's integrated. AGI systems could dynamically optimize QKD network parameters in real-time, adjusting laser intensities, basis choices, and error correction based on channel conditions and threat models. Early experiments show AGI could improve key rates by 30-40% while maintaining security.

AGI combined with quantum computing could develop novel attacks on QKD implementations, requiring constant protocol updates and security patches. This creates an arms race between AGI-powered attacks and defenses. AGI systems could autonomously manage QKD security, detecting and responding to attacks faster than human operators, but raising questions about accountability and control in critical infrastructure.

Understanding the failure modes of QKD systems is as important as understanding their successes. Practical QKD implementations face several challenges that can compromise security if not properly addressed. This code demonstrates error analysis and mitigation strategies for practical QKD systems. Company: QuantumFinance Corp - A multinational financial services firm handling $500B in daily transactions.

Challenge (2027): QuantumFinance needed to secure inter-branch communications against future quantum computing threats while maintaining low latency for high-frequency trading. Classical cryptography was vulnerable to "harvest now, decrypt later" attacks where encrypted communications were being stored for future quantum decryption. As we approach 2030, advanced QKD techniques will overcome current distance limitations and enable truly global quantum-secured networks. These techniques build on fundamental quantum phenomena like entanglement and quantum memory.

Entanglement-Based QKD (E91 Protocol): Uses entangled photon pairs to distribute keys. Any eavesdropping disturbs the entanglement, which is detected through Bell inequality violations. By 2029, entanglement-based QKD will enable device-independent security guarantees. Quantum Repeaters: The quantum equivalent of classical repeaters, using quantum memory and entanglement swapping to extend QKD range beyond the 200 km fiber limit. Current research targets operational quantum repeaters by 2028.

Measurement-Device-Independent QKD (MDI-QKD): Removes all detector side-channel attacks by having both Alice and Bob send quantum states to an untrusted central node. This will become the standard for high-security applications by 2027. Always simulate QKD protocols thoroughly before hardware deployment. Use Qiskit to model channel noise, detector imperfections, and attack scenarios. A 2028 survey found that 70% of QKD deployment issues could have been caught in simulation.

Design systems to fall back to post-quantum cryptography when QBER exceeds thresholds. The hybrid approach ensures continuous security even during QKD maintenance or channel degradation. Implement real-time QBER monitoring with automated alerts. A sudden QBER increase from 2% to 8% could indicate eavesdropping or hardware failure. Set thresholds at 5% for warning, 8% for investigation, 11% for protocol abort.

Remember that QKD only secures the key exchange. All classical components (authentication, error correction, privacy amplification) must be implemented securely. Use constant-time algorithms and secure hardware for post-processing. Share your experience and insights with our community of quantum security practitioners. Qiskit Documentation: Comprehensive guides to quantum programming and QKD simulations. IBM Quantum Network: Access to real quantum hardware for testing QKD protocols.

Qiskit Tutorials: Step-by-step QKD implementation examples. OpenQKD: Open-source QKD protocol implementations and testbeds. "Quantum Cryptography" on edX by TU Delft. "QKD Implementation" masterclass by the Quantum Internet Alliance. "Decoy State QKD" by Lo et al. (2005). "Measurement-Device-Independent QKD" by Braunstein and Pirandola (2012).

Current fiber-based QKD systems are limited to approximately 200-300 km due to photon loss in optical fiber. Satellite-based QKD can achieve global distances but with higher latency and cost. Quantum repeaters, expected to be operational by 2029, will extend this to thousands of kilometers. QKD provides information-theoretic security based on physics, while post-quantum cryptography (PQC) provides computational security based on mathematical problems believed to be hard for quantum computers. The optimal approach for 2026-2030 is a hybrid system using both: QKD for key exchange and PQC for authentication and digital signatures.

While the theoretical principles of QKD are secure, practical implementations can have vulnerabilities. Common attacks include detector blinding, photon number splitting, and side-channel attacks. Proper implementation with decoy states, monitoring, and hardware countermeasures can mitigate these risks. As of 2026, metropolitan QKD networks cost $200k-$500k per node. By 2030, costs are projected to drop to <$50k per node for enterprise systems. Satellite QKD terminals currently cost $1M-$5M but are expected to decrease to ~$1M by 2030.

Operational costs include fiber maintenance, detector calibration, and security monitoring. Quantum Key Distribution represents not just an incremental improvement in cryptography, but a fundamental shift in how we approach secure communications. As quantum computers capable of breaking current encryption emerge in the 2028-2030 timeframe, QKD provides a physics-based solution that remains secure regardless of computational advances.

The implementation journey begins with simulation and understanding, as demonstrated in our Qiskit code examples. From basic BB84 to advanced decoy state protocols, Python provides an accessible entry point for exploring quantum security concepts. As you progress from simulation to deployment, remember that hybrid approaches combining QKD with post-quantum cryptography offer the most robust security for the transitional period.

The future belongs to those who prepare today. By mastering QKD implementation in 2026, you position yourself at the forefront of the quantum security revolution that will define secure communications through 2030 and beyond. "The quantum threat to cryptography is not a matter of if, but when. Organizations that implement quantum-safe security today will have a significant competitive advantage in the quantum era." Filed under implementing , distribution , real world , problem solving 2 , refactoring , troubleshooting , ai ml , 6g , space tech and biotech .

Quantum key distribution is one of the few areas where quantum mechanics provides a provably unconditional security advantage over classical methods. Classical key exchange (Diffie-Hellman, RSA) relies on computational hardness assumptions: no known efficient algorithm can break it, but a sufficiently powerful computer could in principle. QKD is different: its security follows from the laws of physics. An eavesdropper cannot intercept and re-send a qubit without disturbing it in a detectable way.

The BB84 protocol, published by Charles Bennett and Gilles Brassard in 1984, was the first QKD protocol. It remains the most widely deployed. This tutorial implements it from scratch in pure Python, no quantum library required, by simulating the qubit states and measurement outcomes directly. 5. Performance Evaluation & Extended Technical Observations The key insight is that quantum measurement is irreversible and basis-dependent. A qubit can be in one of two states in the Z basis (|0>, |1>) or one of two states in the X basis (|+>, |->). If you measure an X-basis state in the Z basis, you get a random result, and the original state is destroyed. An eavesdropper who intercepts a qubit does not know which basis Alice used, so she has to guess. Half the time she guesses wrong, measures in the wrong basis, and sends on a corrupted qubit . This introduces detectable errors.

Alice picks a random basis for each bit. Bob picks a random basis for each measurement . When they pick the same basis, the result is perfectly correlated. When they pick different bases, the result is uniformly random and discarded. On average, about 50% of bits survive sifting (half the basis pairs match). With 1000 qubits, you get roughly 500 sifted key bits with zero errors if there is no eavesdropper.

Now add Eve. She intercepts every qubit, measures it in a randomly chosen basis (she does not know Alice’s basis), and re-prepares a new qubit to send to Bob. When Eve guesses the wrong basis, she disturbs the state: The theoretical error rate when Eve intercepts every bit is exactly 25%. This is because: Alice and Bob sacrifice a random subset of their sifted key to estimate the error rate. If the error rate exceeds a threshold, they abort and assume eavesdropping: A QBER below about 11% is generally considered safe for BB84 with one-way classical post-processing. Above 11%, the information Eve might have accumulated cannot be fully removed by privacy amplification.

Even when the QBER is below the threshold, Eve may have partial information about some bits (from the cases where she guessed the right basis). Privacy amplification uses a universal hash function to compress the remaining key, destroying Eve’s partial knowledge: In production QKD implementations, Toeplitz-matrix hashing is used rather than SHA-256, because it has provable security properties. The hash function is chosen randomly and shared publicly, which does not help Eve.

Commercial QKD systems (ID Quantique, Toshiba, QuantumCTek) vary widely by design and vintage; secret key rates fall in roughly these ranges: Beyond about 300-400 km, loss is too high for direct fiber QKD. Trusted relay nodes or quantum repeaters are needed for longer distances.

This simulation captures the protocol logic faithfully: the security analysis, error rate calculations, and key sifting are identical to what real systems do. What it abstracts away: The BB84 simulation you have built is conceptually complete. The security proof by Shor and Preskill (2000) and Mayers (2001) shows that it is information-theoretically secure against arbitrary quantum attacks, a level of security no classical protocol can achieve.

Run Python with NumPy preloaded right here. Edit the code and execute it instantly. It runs entirely in your browser, no signup or install. CirQit is a professional quantum circuit simulator built on NumPy. Six backends, zero heavy dependencies — from 2-qubit Bell states to 1000-qubit stabilizer circuits.

A complete toolkit built from scratch with noise models, variational circuits, error correction, and more. CirQit is an open-source Python library for quantum circuit simulation. It is designed to provide researchers, students, and developers with a fast, lightweight, and professional-grade toolkit without heavy external dependencies. The library implements six distinct simulation backends covering every major quantum computing regime — from exact statevector simulation to large-scale Clifford stabilizer circuits exceeding 1000 qubits. All algorithms are built from scratch using NumPy, ensuring performance, transparency, and full control.

CirQit focuses on simplicity, performance, and accessibility — making quantum computing experimentation possible without relying on complex or proprietary platforms. CirQit is a free, open-source Python library for professional quantum circuit simulation. We believe quantum computing education should be accessible to everyone — from students learning their first qubit to researchers building fault-tolerant algorithms.

Built entirely on NumPy with zero heavy dependencies, CirQit provides six simulation backends, 20+ quantum gates, noise models, variational circuits, quantum error correction codes, and a full job tracking system — all installable with a single pip install cirqit command. To make quantum computing simulation accessible, educational, and production-ready for the global developer community.

This blog publishes original articles, tutorials, and research insights on quantum computing — all freely available. This site participates in Google AdSense to help fund free content and open-source development. Advertisements are clearly distinguished from editorial content. Information We Collect: CirQit does not collect personally identifiable information unless you voluntarily provide it. We may collect limited non-personal data such as browser type, device information, and usage behavior through standard analytics tools to improve website performance.

Analytics: We use analytics tools to understand how visitors interact with our website. This data is aggregated and used solely to improve performance and content quality. CirQit is released under the MIT License . You are free to use, modify, and distribute the software for personal and commercial purposes, subject to the terms of the license.

All content published on this website, including articles, documentation, and design elements, is the intellectual property of CirQit unless otherwise stated. You may reference or share excerpts with proper attribution. This website and its content are provided on an "as is" basis without warranties of any kind. CirQit makes no guarantees regarding accuracy, reliability, or completeness of the information provided.

CirQit shall not be held liable for any direct, indirect, or incidental damages arising from the use of this website or its software. This website may integrate third-party services to enhance functionality and user experience. These services operate independently and may have their own terms and policies. These terms may be updated or modified at any time without prior notice. Continued use of the website constitutes acceptance of the updated terms.

Have a question, feedback, or collaboration idea? We’re here to help and would love to hear from you. We typically respond within 1–2 business days. For direct inquiries, email us at [email protected] . A full, working simulation of the BB84 protocol — the world's first quantum key distribution scheme — built with IBM's Qiskit quantum computing framework and the Aer statevector/QASM simulator.

Classical encryption (RSA, AES) relies on computational hardness — problems that are difficult but not impossible to solve. A sufficiently powerful quantum computer running Shor's algorithm could break RSA in polynomial time. Quantum Key Distribution offers an alternative whose security is guaranteed by the laws of physics , not mathematical assumptions. Quantum Key Distribution (QKD) is a method that allows two parties — traditionally called Alice (sender) and Bob (receiver) — to produce a shared, secret random key using a quantum channel and an authenticated classical channel.

BB84 , proposed by Charles Bennett and Gilles Brassard in 1984 , was the first QKD protocol and remains the most studied and widely implemented. Alice sends each qubit to Bob over a quantum channel (e.g. a fiber-optic cable carrying single photons). This is where eavesdropping may occur.

Bob independently and randomly chooses a measurement basis (Z or X) for each qubit. He measures and records the outcome. Harvested Online Documentation & Reference Sources • https://en.wikipedia.org/wiki/Qiskit • https://en.wikipedia.org/wiki/Quantum%20programming • https://en.wikipedia.org/wiki/IBM%20Quantum%20Platform • https://qiskit.qotlabs.org/learning/modules/computer-science/quantum-key-distribution • https://github.com/rezi-gelenidze/Quantum-Key-Distribution-Protocol • https://quantum.cloud.ibm.com/docs/en/guides • https://github.com/nayanj2221/BB84-Quantum-Key-Distribution-QKD-Simulator • https://johal.in/implementing-quantum-key-distribution-in-python-with-qiskit-for-secure-comms-2/ • https://quantumcomputingcourses.com/tutorials/quantum-key-distribution-python • https://cirqitpk.com/blog/bb84-quantum-key-distribution-python-tutorial