A Java approach for leveraging quantum entanglement in communication

In a previous post, I talked about leveraging quantum entanglement to create a secure communication channel. The post concluded with the following picture, which explains that if Alice and Bob each get one half of an entangled qubit pair (hence one qubit for each), they can use the value of their qubit to generate a secure key.

Alice and Bob sharing a pair of entangled qubits, provided by a “quantum entangler”

Before either Alice or Bob measures the value of the qubit they received, they have no idea if they will measure 0 or 1. In fact, because of the laws of quantum physics, nobody knows for sure. The entangled pair is in such a state that there is 50% chance that both Alice and Bob will measure 0, and 50% chance that they both will measure 1.

I wrote a simple Java application that demonstrates the different components of an end-to-end scenario in which Alice sends a message to Bob, and uses a key obtained by measuring the qubits she obtains from the Quantum Entangler service. She knows Bob has the same key, because the measurement he makes on his half of the entangled pair correspond to the measurement of Alice. In a simple scenario, Alice and Bob use one entangled qubit for each bit they transport. If Alice measures her qubit and she reads the value 0, she send the bit she wants to send unaltered. However, if the measurement of her qubit yields the value of 1, she flips the bit she wants to send. Bob applies the same rules, so Alice and Bob have a shared secret.

The application can be found at https://github.com/johanvos/qsocket. You can clone the repository, and run it as follows:

mvn javafx:run

This will show a bunch of output, where the most important statement is near the end:

Bob got bytes: [0, 1, 1, 0, 0, 1, 0, 0]

Those are the bytes that Bob is reading through his QSocket. They match the bytes Alice was sending, which can be seen in the Main class of the application:

    byte[] b = new byte[]{0,1,0,0,1,1,1,0};
    alice.getOutputStream().write(b);

Hence, the application demonstrates that the bytes sent by Alice are correctly received by Bob. The following high-level diagram demonstrates how this works:

high-level architecture

Alice and Bob talk to each other via a QSocket. While a QSocket does not directly extends a java.net.Socket, it has similarities. Most important is that a QSocket has an InputStream and an OutputStream that can be used to receive and send data. Bob and Alice send the data they want to send via these InputStream and OutputStream instances through the QSocket instance to each other. They don’t have to worry about encrypting the data, as this is done by the QSocket implementation. In order to do so, the QSocket implementation will request an entangled pair from the Entangler — that is, Alice’s QSocket will request half of the entangled pair and Bob’s QSocket will request the other half.

In the real world, the Entangler should be a physical device, that is capable of bringing 2 qubits in a Bell State, and send each of them to one of the parties in a conversation (Alice and Bob). In our simulation, the Entangler is a standalone service, which can run on a separate server — or on the same machine using a different port. The Entangler is the only component where quantum code is being executed — using the Strange quantum simulator.
The QSocket implementations use classical communication to talk to the Entangler, and to exchange commands. Keep in mind though that in practice, this component should be replaced by hardware capable of generating and transmitting entangled qubits.

I will go a bit deeper in the code in follow-up posts, but the interested reader is of course encouraged to have a look at the code in the github repository.

If you want to learn more about quantum computing for development, I highly recommend my book “Quantum Computing in Action“.

The code for the Strange quantum simulator can be found at https://github.com/redfx-quantum/strange