# The optical Quantum Random Number Generator

As we all know AES and SHA-2 are perfectly secure – if (and only if) optimal key material is being used. In the moment where certain assumptions can be made regarding the keys in effect for encryption and decryption, the overall security is substantially degraded and can make brute force attacks possible within reasonable time.

Fortunately there are nowadays true random generators available at a reasonable cost and size which rely on a quantum physics effect using a beam splitter (a semi-transparent mirror) and single photon detectors.

The principle works as follows: A photon source ejects single photons directed to a semi-transparent mirror. Two distinct single-photon detectors are placed in a way that one detector detects the photons passing the mirror, and the other the photons that are being reflected. In fact, the actual presence of those single-photon detectors forces single photons to decide which way they take (if there were no such measurement devices, the photons would stay in a non-locality state which is quite hard to unterstand and to explain).

Since no semi-transparement mirror is exactly 50% semi-transparent, the so generated bitstream requires an additional step which removes this bias. The simplest of these unbiasing procedures was first proposed by Von Neumann [1]. The random bits of a sequence are grouped in subsequences of two bits. Whenever the two bits of a subsequence are equal, it is discarded. When the two bits are different and the subsequence starts with a 1, the subsequence is replaced by a 1. When it starts with a 0, it is replaced by a 0. This simple procedure removes any bias and works even if the bias is moving slightly over time due to thermal effects, for example.

For further information and readings see the following links:

- Generating random numbers (randomnumbers.info)
- ID Quantique White Paper – Random Number Generation using Quantum Physics

# TRKMp Overview and Definitions

# True Random Key Material File Format

The true random key material is kept in a file which needs to be identical on the two nodes that wish to communicate. The general format consists of a set of tuples, where the number of tuples (and thus the length of the true random key material file) may be chosen as needed. Each tuple consists of a 32 bit nonce and a 32 bit key. The index of the tuples directly corresponds with the sequence number of the protocol.

For example, sequence number 0 uses the tuple at index 0, sequence number 123 the tuple at sequence number 123 and so forth. If the sequence number exceeds the number of available tuples, the indexing simply wraps over starting from the beginning (modulo N being the number of available tuples).

The general true random key material file format looks as follows:

<- Tuple 0 -------------------> [32 Bytes Nonce] [32 Bytes Key] <- Tuple 1 -------------------> [32 Bytes Nonce] [32 Bytes Key] <- Tuple 2 -------------------> [32 Bytes Nonce] [32 Bytes Key] ... <- Tuple N -------------------> [32 Bytes Nonce] [32 Bytes Key]

The minimum length of the true random key material file is one tuple (64 Bytes), the maximum length depends on the file system restrictions of the host operating system. The overall length of the key material file needs to end at a 64 Bytes boundary.

Choosing larger true random key material files increases overall security.

The overall length of the key material file is not revealed by the protocol itself and is – so to say – a tiny additional secret shared by the communicating nodes.

This example shows the generation of 1GB True Random Key Material with EasyQuantis which takes about 35 Minutes with the Quantis USB device:

# TRKMp General Packet Format

The general TRKMp packet format is defined as follows:

<32 Bytes SHA-256 authentication hash> <8 Bytes sequence number> <2 Bytes packet type> <2 Bytes data length> <variable legth data padded to 16 byte boundary>

The **<32 Bytes SHA-256 authentication hash>** contains the SHA-256 hash starting with the sequence number up to the end of the packet adding the nonce of the key material with the index of the sequence number (modulo the number of available tuples in the key material). This hash value authenticates a valid sender on the receiver side.

The **<8 Bytes sequence number>** is always increased on the sender and receiver side thus allowing replay protection. A configurable window of older, not yet received sequence numbers allows accepting occurring packet disorder. Older packets outside this window are dropped.

The **<2 Bytes packet type>** in network order define the packet type of the TRKMp protocol.

The **<2 Bytes data length>** holds the length of the data without padding and is also in network order.

The **<variable legth data padded to 16 byte boundary>** holds the data AES-256 encrypted data in CTR mode:

- The CTR nonce is the key material nonce at the position of the sequence number (modulo number of available tuples) xored with the sequence number itself amd additionally xored with the counter starting at 0.
- The CTR AES key is the key material key at the position of the sequence number (modulo number of available tuples).

The encryption and decryption works as follows (see CTR Mode @ Wikipedia ):

# References

[1] Von Neumann, J., “Various techniques used in connection with random digits”, Applied Mathematics Series, no. 12, 36-38 (1951).