HKDF-Based Encryption Method with Very Long Keys for QKD and RKD

Abstract

Established symmetric encryption schemes rely on short keys, with their length typically ranging between 128 and 256 bits. However, well-known physical key exchange schemes such as QKD (Quantum Key Distribution) and RKD (Radio-signal Key Distribution) generate megabits of new key material on a regular basis (i.e., daily, weekly, or otherwise). This article presents a new encryption scheme, OTPH, which is specifically designed to handle these megabits of regularly generated new key material. In this scheme, the key material is treated as a very long key, and its enormous entropy is fully exploited. OTPH first uses a bit selection procedure that randomly selects bits from the circularly arranged key, thereby extending the key many times over. From this, an HKDF (Hash Key Derivation Function) derives many new keys, and the result is a bit sequence that serves as the key for encryption using an XOR operation. OTPH uses only the XOR operation and hash function, which are also used in QKD and RKD during postprocessing (albeit with a different hash function). An initial cryptanalysis is also performed. OTPH operates in a manner entirely contrary to established methods, requiring a completely new perspective. It will not compete with AES, ChaCha20, etc., but instead be used primarily in the context of QKD and RKD.

1. Introduction

Most available symmetric encryption algorithms are based on short cryptographic keys, as key exchange is typically performed using asymmetric methods which only allow for short keys. The cryptanalysis of these algorithms is fully accepted within the cryptographic community and confirms that many algorithms, such as AES [1] or ChaCha20 [2], provide sufficient security. However, despite the extremely advanced state of cryptanalysis, the security of these algorithms is partly based on assumptions—albeit significantly more advanced ones than in asymmetric cryptography. It is the established view in the cryptographic community that a key in the megabit range is practically useless for symmetric encryption algorithms for the following reasons:

• Key lengths of 256 bits are very secure in the long term, even against realistic attacks by quantum computers (with Grover’s reduction, the effective key length is approximately 128 bits).
• Key lengths in the megabit range do not provide any practically usable additional security compared to 256 bits and only increase storage requirements and significantly complicate key management, as effective security does not directly follow from key length.

However, some physical methods for key exchange, such as QKD (Quantum Key Distribution), RKD (Radio-signal Key Distribution, also known as physical-layer key generation in wireless networks), and MKD (key exchange using highly secure memories), enable the exchange of at least 2 megabits of key material on a regular basis (between a few minutes and one day for QKD, within a week for RKD). Notably, MKD may even require the exchange of terabytes of key material [3], thus enabling the use of a one-time pad (OTP) for data encryption [4]. However, the large amount of key material at QKD and RKD is not sufficient for an OTP. It is used for conventional symmetric algorithms with short keys, and the key may be changed very frequently (e.g., every 10 min). From a security standpoint, however, this constant key exchange offers only very limited improvement in the case of QKD and RKD. If there is full confidence in the security of the symmetric algorithm—such as AES-256 or ChaCha20—rapid key exchange is not necessary, and a short key is entirely sufficient over longer periods; conversely, if there is no confidence in the algorithm, even rapid key exchange is insufficient. In other words, the extremely high costs of exchanging large amounts of key material between two nodes (as in QKD) represent a poor investment [3]. With RKD, the cost situation is significantly better; however, the large amount of key material is also unnecessary. RKD is particularly interesting for highly secure communication between satellites and Earth as, in this context, MKD is not possible, QKD is extremely expensive, and asymmetric cryptography—with its cryptanalysis based on conjecture—should be avoided where possible.

Therefore, the large amount of key material at QKD and RKD requires either splitting into many subkeys or a sufficiently long extension of the key material. For this necessary and securely long enough extension, the OTPH provides a suitable solution with proc. step 1 (see below).

With current symmetric data encryption methods, it is generally assumed that a 256-bit key length is sufficient and that significantly longer keys, with the exception of OTP (One-Time Pad), offer no advantages. However, there is no scientific evidence supporting this claim. The security mechanisms are based primarily on confusion, diffusion, and multiple rounds of processing cycles, and have proven themselves for over 50 years. The longest key lengths in established algorithms range from 1024 to 2048 bits (e.g., Threefish-1024, RC4 through RC6), and the actual data encryption is usually performed using the XOR operation—as is the case, for example, with CTR mode in conjunction with established algorithms and ChaCha20. This means that a key—usually 256 bits long—is extended to an unlimited length for XOR encryption and the entropy can be based on a key length of 256 bits.

The method described below, OTPH, is adapted to the conditions in QKD and RKD, where megabits of new, non-deterministic key material are exchanged on a regular basis (daily, weekly, etc.) between two communication partners and must be used; otherwise, QKD and RKD are economically pointless. OTPH fundamentally treats the new key material as a single key, regardless of its length (even for lengths in the gigabit range). In OTPH, a non-deterministic key, called KeyInput, that is several megabits in length—which, in practice, usually originates from a QKD or RKD key exchange procedure—is used to select key bits via a special key bit selection procedure, whose selection parameters are non-deterministic random numbers. From these selected bits, a very large number of different intermediate keys—hereinafter referred to as Masterkeys—are generated for an HKDF (Hash Key Derivation Function) [5,6], which then generates the actual key for XOR encryption through key derivation. The entropy of the actual key used to encrypt the data is based on the MinEntropy of all Masterkeys and on the key length of the KeyInput, especially of InputEntropy. The central security function here, aside from the XOR encryption, is the HKDF, for which established cryptanalytic studies exist [5,6].

In summary, until a few years ago, there was no need for key lengths of several megabits and few encryption methods using very long keys have been reported to date. Among these, VME (Virtual Matrix Encryption) and extended LFSR-based stream ciphers are particularly noteworthy. These two solutions operate at very different levels.

• VME is a complete encryption scheme;
• Extended LFSR-based stream ciphers are a class of encryption algorithms or keystream generators.

Virtual Matrix Encryption (VME) [7]: VME was patented by Shaul O. Backal and describes an unusual approach. The encrypted message does not contain the encrypted data but, rather, pointers to positions in a mutually known “virtual matrix.” This matrix can be very large and is generated from a shared file or a shared dataset. In addition, an extremely large “virtual key” (millions of bits or more) is used, which is reconstructed from the same file by both the sender and the recipient. The basic idea is that the sender and recipient possess the same large file, from which the virtual matrix is generated. Plaintext symbols are then mapped to positions within this matrix, and positions or references are transmitted instead of traditional ciphertext. There is no generally accepted cryptographic security analysis for VME; information about it comes primarily from patent documents and promotional materials. Its security is based on the secrecy of the matrix, the secrecy of the shared file, and the size of the virtual key. However, the security assumptions have not been scientifically verified.

Extensions of LFSR-based stream ciphers [8]: An LFSR (Linear Feedback Shift Register) generates bit sequences through linear recursion. Pure LFSRs are cryptographically unsuitable because their linearity can be exploited relatively easily. Modern stream ciphers extend LFSRs by incorporating nonlinear combination functions, nonlinear filter functions, additional memory states, and multiple coupled LFSRs. The security gain does not result from large keys alone, but from the prevention of correlation attacks, algebraic attacks, fast correlation attacks, and state reconstruction. Security relies on nonlinearity and a large internal state.

To date, there have only been a few methods that use longer keys (as detailed above). However, with the advent of QKD and RKD, these methods can now be pursued scientifically. The OTPH method presented in this paper is a first attempt in this direction.

2. Contributions

The OTPH encryption scheme described below is designed for very large keys—that is, those with length in the megabit range—and was developed specifically for QKD and RKD. It is intended to enable QKD (Quantum Key Distribution) and RKD (Radio-signal Key Distribution) [3]; in particular, to exploit the full potential of long cryptographic keys on the basis of their extremely high entropy.

OTPH consists of three major processing steps. In the first, the key is read in a circular manner (i.e., without end). This circular arrangement is called a cyclic buffer. From this very large cyclic buffer, which contains the entire key, the bits are read out using a special mechanism such that the key becomes significantly longer. In the second processing step, this extended key is further extended using an HKDF (Hash Key Derivation Function) and stripped of identical bit sequences. Finally, in the third step, the actual data encryption process takes place via an XOR operation. Through this double key extension, the megabit keys generated via QKD or RKD can be expanded into terabit keys, which are usually sufficient for data encryption using XOR. OTPH is a one-way function that cannot be reversed.

Therefore, the OTPH encryption method employs a completely different cryptographic approach than the methods commonly used today. OTPH utilizes the extremely high entropy to generate an even longer key with almost the same entropy for XOR encryption. The method has the following specific properties:

• It adapts precisely to the entire key material supplied by QKD/RKD, regardless of whether it is, for example, 100 Kbit, 1 Mbit, or 16 Mbit.
• It always uses the entire key material supplied by QKD/RKD as a single unit, regardless of its length; that is, the very long key is not split into shorter subkeys.
• The method uses only the XOR operation and the hash function, which are also used in QKD and RKD during postprocessing (albeit with a different hash function). In other words, OTPH does not introduce any new insecure functions that are not already in use during key distribution.
• Cryptanalysis—and, thus, the security assessment—is very manageable due to the simplicity of the method and focuses on the HKDF and the XOR operation, for which established cryptanalyses which have been accepted by the cryptographic community are available [5,6]. This eliminates the disadvantage that no recognized cryptanalysis approach is yet available for this type of encryption method.
• OTPH can encrypt only a finite amount of data with a single key. As OTPH was developed specifically for QKD and RKD, where new key material is regularly supplied, this limitation does not pose a problem in this context.
• OTPH must store and process long keys—which is, in principle, a requirement for QKD and RKD—and QKD and RKD must already provide the necessary key protection.

RKD and, more so, QKD generate a large amount of non-deterministic random numbers per day or week, in the form of key bits for data encryption. However, the quantity can vary greatly, which must not affect the security of the encryption. For RKD, the values used at present range from approximately 512 Kbit to 2 Mbit per week. For QKD, the values depend heavily on the technology, the transmission method (fiber optic cable, free-space channel, satellite), and the operating and environmental conditions [3]. The values therefore currently vary between approximately 500 Kbit and 100 Gbit per day. As these values can also vary significantly during operation, the encryption method must be able to respond flexibly to them.

3. OTPH Encryption Scheme (One-Time Pad with HKDF)

3.1. Definition of Parameters

General information: All parameters are bitstrings or positive integers.

KeyInput: Input key of OTPH.

p: Length of KeyInput. p must be a prime number. If the key length is not a prime number, the corresponding number of bits are truncated at the end.

InputEntropy: A long non-deterministic random number, such as the KeyInput, is usually not perfect, and therefore neither is its entropy. For this reason, InputEntropy was introduced to specify the entropy of the KeyInput.

a: In the first processing step, individual bits are read from KeyInput according to the rules of OTPH. The result is a new Masterkey_ec. The length of this Masterkey_ec is a constant a. In practice, a = 512 is recommended.

bp₁, bp₂, …, bp_a: The individual bits of the KeyInput. That is, bp₁ (bit position 1) is the first bit of the KeyInput, and bp_p is the last bit.

mk₁, mk₂, …, mk_a: The individual bits of the Masterkey_ec. That is, mk₁ (bit position 1) is the first bit of the Masterkey_ec, and mk_a is the last bit.

ec: The value range is 1 ≤ ec ≤ (p² − p). After each derivation of a new Masterkey (reading a bits from KeyInput), ec (encryption counter) is incremented by 1.

Masterkey_ec: Result of the first processing step.

HKDF (Hash Key Derivation Function [5,6]): Second processing step. In this step, a KeyXOR_ec is derived from a Masterkey_ec, which is used to encrypt the data using the XOR operation.

ol: Each KeyXOR_ec has a length of ol (output length of the HKDF).

d_x: The valid range is 1 ≤ d_x < p. When deriving a new Masterkey_ec, a bits are read from KeyInput with a bit spacing of d_x. For a given d_x, a maximum of p different Masterkeys can be derived because p is a prime number. That is, a total of $p\times (p-1)=(p^2-p)$ different Masterkeys can be derived, which is therefore also the highest possible value of ec (see above). All d_x values are random numbers and are different.

y: The largest possible value of y is p. The value y indicates how many distinct d_x values exist; that is, there are values for d₁, d₂, d₃, …, d_y. All of these d_x values are random and distinct within the range specified above.

k: k = rounded down (p/a). The parameter k specifies how many Masterkeys for a given d_x do not contain any common subsets (overlaps). All of these k Masterkeys contain different bits from KeyInput, which is a non-deterministic random number.

g_x: The valid range is 1 ≤ g_x ≤ p. For a given d_x, only g_x Masterkeys are ever processed in the HKDF. All g_x values are random numbers. Section 3.7 describes how d_x and g_x are determined. The parameters a, p, y, and all d_x where 1 ≤ x < p, as well as all g_x where 1 ≤ x ≤ p, must remain constant at least until a new KeyInput is loaded into the cyclic buffer.

Salt_i: In the HKDF, the Extract function first uses an HMAC (HashMAC [9]) to derive the PRF_i from the Masterkey_ec and the key Salt_i. In particular, Salt_i is the hash value of 1024 bits of the KeyInput. The selection of the 1024 bits for Salt_i is carried out as follows: For every i in the range 1 ≤ i ≤ k ∗ a, 1024 bits are read starting at address (i − 1) ∗ 1024, from which Salt_i is then derived using a hash function [9,10]. This ensures that, in the HKDF’s Expand function, k Masterkeys—where all bits from KeyInput are distinct (when considered in terms of the bit addresses) (see k above)—are always processed with their own PRF_i.

Tj: Value range 1 ≤ j ≤ ol/256 (or ol/512, depending on the hash length). In the HKDF, keys—hereinafter referred to as T_j—are derived in the Expand function from the PRF_i and the Masterkey_ec. These derived keys T_j are concatenated to form the key KeyXOR_ec.

KeyXOR: A KeyXOR_ec of length ol is derived from each Masterkey_ec. All KeyXOR_ec together form the KeyXOR. During subsequent encryption with the KeyXOR, each bit of the key may be used only once.

General information: The parameters p, a, ol, all d_x and g_x, and y must be constant for a given KeyInput and are specified as an input parameter. The parameters d_x and g_x can be a part of KeyInput (see Section 3.7). Only the bit positions of the KeyInput are considered—not the actual bit sequence from KeyInput—and the Masterkeys are generated from them. It follows that all Masterkeys are different.

3.2. General Information on the Method

The OTPH encryption scheme (One-Time Pad with Hash Key Derivation Function for key generation) is based on three processing steps, as follows:

• Calculation of Masterkeys for an HKDF using a bit selection procedure with non-deterministic parameters. In this process, bits are read in a circular manner from the KeyInput key of length p.
• Determination of the key for XOR encryption through repeated key derivation using an HKDF (Hash Key Derivation Function).
• Data encryption using the XOR operation.

After every k steps, the extract function is used to calculate a new PRK_i for the expand function. In this process, 1024 new bits from the KeyInput are always hashed, and the result is used as a new Salt. As a result, Masterkeys that do not contain any common subsets are always grouped together and processed with the same Salt.

3.3. Processing Step 1

The KeyInput is treated as a cyclic buffer with modulo addressing, and the length of KeyInput must be a prime number p. This means that the key KeyInput, with length p, is read in a circular manner and therefore has no end. During each read operation, a bits are sequentially read from the cyclic buffer at a bit spacing of d_x (see Figure 1); that is, the bits are not read immediately one after another, but at a specified bit spacing of d_x. After g_x read operations with the specified d_x, the value of x is incremented by one; in the first processing step, the bits are read from the cyclic buffer with a bit spacing of d_x, and only g_x read operations of length a bits are performed with this d_x.

Figure 1. OTPH processing step 1.

The a bits, which are read from the cyclic buffer per read operation in the first processing step with a bit spacing of d_x and constitute a read block, are immediately processed as a Masterkey in the second processing step of the HKDF, and this then yields the key KeyXOR_ec for the third processing step. The read logic in the first processing step guarantees that all resulting read blocks of length a—i.e., all Masterkeys of the HKDF—are different, and that this holds for a maximum of (p² − p) read blocks (corresponding to maximum values of d_x times g_x). However, real Masterkeys may still be identical, depending on the actual bits of the KeyInput. For Masterkeys that belong to the same group of the k different Masterkeys, this is an extremely unlikely and therefore theoretical case due to the large length. The situation is different for Masterkeys in different groups. Here, there is a possibility in practice, even if it is very unlikely. However, the different Salt in processing step 2 ensures separation.

In a single read operation—i.e., using the same ec, a, d_x, and p—a bits are read from the cyclic buffer with the addresses bp₁, bp₂, bp₃, …, bp_a−1, bp_a (see Figure 1). The Masterkey has the bit addresses mk₁, mk₂, mk₃, …, mk_a (see Figure 1). The algorithm for calculating the individual bits in the Masterkey is given in Pseudocode at the beginning of Section 3.4.

The bits at positions mk₁, mk₂, …, mk_a−1, mk_a form a Masterkey_ec for the subsequent HKDF. Afterward, ec is incremented by one and the process is repeated. After g_x such read operations—and, thus, g_x Masterkeys for the HKDF—the value x is also incremented by one, and a values are read again using these formulas. At the latest, when x reaches the value p, the process is terminated because the results then begin to repeat. Up to this point, the procedure guarantees that all read results of a bits—and, thus, all Masterkey_ec—are different.

When decrypting the data, the same bp must be used as in the encryption process; that is, in the data storage application, the values of KeyInput, a, p, ol, ec, and (d_x║g_x) used during data encryption must be stored. In telecommunications applications, both parties (or more, in the case of multiple telecommunications partners) must use the same “bp;” i.e., they must use the same values for KeyInput, a, p, ol, ec, and (d_x║g_x). All possible values of (d_x║g_x)—i.e., (d₁║g₁), (d₂║g₂), …, (d_p-1║g_p−1)—are part of KeyInput, regardless of whether they are at the beginning of the cyclic buffer or separate from it (see Section 3.7 below). The KeyInput key is changed when the key generation is changed during data storage in the application, for example, when an authorized user leaves a role, or when a different role is involved (each role has its own key with its own generations), or when new key material is available from QKD/RKD for a key in the telecommunications application. Figure 2 schematically illustrates the three processing steps along with their respective relevant parameters.

Figure 2. OTPH encryption method.

3.4. Processing Step 2: HKDF

In processing step 2 (see Algorithm 1), an HMAC based on the RFC 5869 Key Derivation Function is used [5,6,9]. As an example, SHA-3-512 (ISO/IEC 10188 [9,10]) can be used as the hash function. The choice of HMAC is flexible in OTPH.

Algorithm 1: Processing steps 1 and 2

Input: KeyInput, a (Masterkey-length), p (KeyInput-length), y (number distinct dx), all dx and gx, ol (KeyXORec-length) Output: KeyXOR algorithm k = rounded down (p/a) ec = 1 for x = 1 to y do b = p − dx        //processing step 1 q = 0 r = 0 for i = 1 to gx do b = b + dx (mod p)     //processing step 1 for j = 1 to a do     //processing step 1 mkj = bpb+1     //processing step 1 b = b + dx (mod p)     //processing step 1 endfor          //processing step 1 Masterkeyec = mk1‖mk2‖mk3‖…‖mka−1‖mka if q = k then r = r + 1 if q = k then q = 0 ${\mathrm{PRK}}_{\mathrm{i}} = \mathrm{HMAC} \left(\mathrm{Hash}\right(\mathrm{KeyInput}(\mathrm{bit} \mathrm{r} \times 1024+1$ $\mathrm{mod} \mathrm{p} \mathrm{until} \mathrm{bit}\left(r+1\right)\times 1024$ mod p), Masterkeyec)  //the Hash corresponds to Salt, the Masterkey to IKM [5] T1 = HMAC (PRKi, “First Part”‖0x01)  //text First Part corresponds to CTXinfo [5] T2 = HMAC (PRKi, T1‖”Second Part”‖0x02)  //0x02 corresponds to counter i [5] T3 = HMAC (PRKi, T2‖”Third Part”‖0x03) . . Tm = HMAC (PRKi, Tm−1‖”u Part”‖0xvv) KeyXORec = T1‖T2‖T3‖T4‖T5‖T6‖……… q = q + 1 ec = ec + 1 i = i + 1 endfor x = x + 1 endfor KeyXOR = KeyXOR1‖KeyXOR2‖KeyXOR3‖………‖KeyXORec−1 return KeyXOR endalgorithm ol/512 or ol/256 is defined with m as an integer, u as text, and vv as a hex-number.

In other words, after every k steps, the Extract function is used to calculate a PRKi with a new Salt for the Expand function. In this process, 1024 new bits from the KeyInput are hashed, and the result is used as the new Salt. The Expand function calculates key derivations—ol/512 or ol/256, depending on the hash function used—referred to as T_i in OTPH. It uses PRKi as the key and a text string along with the previous T_i−1 value as info. All T_i values are then concatenated to form KeyXOR_ec, which provides the actual key bits for the XOR operation used in data encryption.

For the last data block—which may, of course, be shorter—a correspondingly smaller number of bits from KeyXOR_ec are used, and thus no padding is required.

Combining HKDF and d_x-variation makes it possible to significantly increase the key length—that is, the number of key bits—for example, from 1 MByte of KeyInput to TBytes of KeyXOR.

3.5. Processing Step 3

A classic OTP (One Time Pad) guarantees 100% security from an information-theoretical perspective. Ref. [11] illustrates the relationship between key entropy and the message and provides a proof of why the OTP is information-theoretically 100% secure and why every perfectly secure scheme must satisfy the same fundamental requirements as the OTP. It also includes a definition of perfect secrecy.

Implementing an OTP in practice presents a number of specific challenges, which are discussed in detail in publications [12,13,14].

Ref. [12] addresses topics such as synchronization loss between sender and receiver, consumption of the key stream, intentional shifting of the key state, recovery after communication errors, attacks on the operational state, and DoS attacks against OTP systems.

Ref. [13] addresses how the sender and receiver remain synchronized, how loss of synchronization affects security, which architecture supports OTP-like communication in the long term, how key material can be consumed in a coordinated manner, etc.

Ref. [14] addresses real-world weaknesses of OTP, such as accidental reuse of keys, operational errors, consequences of reusing key material, and protective measures against operational errors.

In processing step 3, a restricted OTP is implemented (the condition “the key must be completely random” is not met).

3.6. General Information

Processing steps 1 and 2 must be completed beforehand—which can be much earlier—and can run in parallel with other applications. The hash functions play a central role here. During the actual encryption, processing step 3 only needs to perform the XOR operation, which happens extremely quickly.

No padding is required for the last block, which means it can be shorter. If only one block is present and it is shorter, this does not pose a security risk. OTPH allows for partial encryption; i.e., the encryption and decryption of individual data blocks is possible, and identical unencrypted data blocks m_i = m_j result in different encrypted data blocks c_i ≠ c_j. These four properties are important advantages of the OTPH encryption method.

Since the first processing step yields only a finite number of Masterkeys of length a, the sequence becomes periodic after ${\displaystyle {\sum }_{x=1}^{p-1}}{g}_x$ read operations (depending on the KeyInput length p and the individual g_x values), which corresponds to an extremely long period. OTPH can therefore encrypt only a finite amount of data with a single KeyInput. As OTPH was developed specifically for QKD and RKD, where new key material is regularly supplied, this limitation does not pose a problem in this context. The central security issue therefore lies with the HKDF, which must eliminate statistical structures across all Masterkeys while, at the same time, not enabling any new attacks—even during key derivation.

The KeyInput is extended from a bytes (input length) to ol bytes (output length) per read operation with a theoretical maximum of (p² − p) read operations of a bits (if g_x = p holds for all values, which must not be the case in practice) until a repetition occurs; the maximum length of the KeyXOR used for encryption is

$$length KeyXOR={\displaystyle \sum _{x=1}^{p-1}}{g}_x\times ol$$

If all g_x are different, Gauss’s theorem yields

$$length KeyXOR={\displaystyle \frac{({\left(p-1\right)}^2+p-1)\times ol}{2}}$$

In practice, all g_x must be non-deterministic random numbers. With a key length KeyInput (i.e., p) of 10 Mbit—which the physical QKD process can achieve over a line connection within a single day—and an extension via the HKDF by approximately a factor of twenty key derivations, this results in a maximum of approximately 250 Tbyte of keys per day for data encryption using the XOR operation—an extremely high daily value.

However, this maximum should not be targeted because, at this value, every bit of the KeyInput key (i.e., the individual bits in the cyclic buffer) is used very frequently, even though the order of the bits used differs for each read operation. However, if g_x—which specifies how often d_x must be read—is limited, for example, to 16 bits (2 bytes), the key length in the above example decreases, and an initial key length of 10 Mbit still results in an approximately 2 Tbyte length of KeyXOR.

In the OTPH method, despite the repeated use of individual bits from KeyInput in the cyclic buffer, the following apply:

(1)

The bits read from the cyclic buffer represent a non-deterministic random number.

(2)

The order of the bits read changes after g_x read operations, with the read interval between bits determined by d_x, which also represents a non-deterministic random number.

(3)

The bits read from the cyclic buffer during each read operation, as described in (1) and (2), undergo a security-critical processing step via the HKDF; that is, they serve as the input to the HKDF and it is only from this that the actual key, KeyXOR, for data encryption using the XOR operation is derived.

For the security analysis, references [5,6] were considered the state of the art.

• The KeyInput is significantly extended with virtually no loss of entropy. The extension factor is at most (p² − p); i.e., megabits become terabits at most.
• All Masterkeys resulting from the first extension step are distinct because the length p of KeyInput is a prime number (theoretically, there could also be identical ones; see Chapter 3.3). However, these Masterkeys contain subsets of KeyInput.
• As the values of all d_x and g_x are random and secret, and the bits are selected from a non-deterministic random number, the bits in each of the k Masterkeys for every d_x are also non-deterministic, where k = rounded down (p/a). This results in the MinEntropy of $InputEntropie\times k\times a÷p$ for each d_x for the HKDF. All Masterkeys of the same d_x can therefore be divided into groups of k Masterkeys each, and these groups contain—when considered relative to one another—several subsets depending on the size of d_x. Therefore, to further improve security in the HKDF, a different and secret Salt is used for each of these groups; that is, a different key is used for the Masterkey in the HMAC calculation.
• The MinEntropy of the Masterkeys is crucial for the security of OTPH (see Section 4). The MinEntropy for all different values of d_x is always $InputEntropie\times k\times a÷p$, which is only slightly less than the maximum p. For two different values of d_x, the resulting Masterkeys are different and do not share any common subsets. This applies to all possible d_x. Nevertheless, the entropy of the Masterkeys does not increase across all d_x because the selection is always made from the same KeyInput. That is, the MinEntropy across all Masterkeys is also $InputEntropie\times k\times a÷p$, regardless of the number of different d_x.

Thanks to HKDF [5], processing step 2 manages to largely preserve the MinEntropy of processing step 1 for the KeyXOR; that is, the normally extremely high InputEntropy remains almost entirely intact for the KeyXOR and thus for the actual data encryption.

OTPH is a pure encryption algorithm. To calculate a MAC for integrity and authenticity in conjunction with OTPH, OTPM [15]—specially designed for OTPH—can be used, for example. However, other common MACs such as the GCM-MAC and CCM-MAC can also be used for this purpose.

3.7. Versions for the Application of d_x-Pairs

An important security measure is reading the bits from the cyclic buffer with a bit spacing of d_x and ensuring that only g_x blocks are read with this d_x; i.e., each d_x is applied only g_x times. Together, these two values form a d_x-pair (d_x║g_x). All d_x-pairs are non-deterministic random numbers and, thus, the read operation from the cyclic buffer is purely random.

When determining and storing all d_x pairs, there are four versions for OTPH:

• The key KeyInput, with a length of p, also contains all d_x-pairs; that is, every bit of the key is simultaneously part of a d_x-pair. This allows for ${\displaystyle \frac{p^2-p}{64}}$ distinct d_x pairs. Each d_x pair requires 48 bits (3 bytes per d_x and g_x), and dividing by 64 provides a sufficient reserve for identical d_x values that must be ignored (all d_x values must be different).
• The d_x pairs are stored separately. This would theoretically allow for all (p² − p) different d_x pairs. In practice, however, this version requires a very large number of additional non-deterministic random numbers, which are not available.
• The parameters (y₁, b, r, g₁) are stored separately. Each of these parameters requires only three bytes, meaning the number of additional bits is only 12 bytes, which are determined using QKD or RKD. As all d_x pairs must be distinct, but are not stored and therefore cannot be verified in this version, they are determined using a linear congruence generator of the form $y_{i+1}=b\times y_i+r (mod p-1)$.

For all y_i to be different, the following must hold:

r must be coprime to (p − 1), every prime factor of (p − 1) must divide (b − 1), and if (p − 1) is divisible by 4, then so must be (b − 1). Since the four parameters represent non-deterministic random numbers, but b and r must satisfy the above conditions, the parameters b and r must be increased until the conditions are met.

For the individual d_x pairs, the following then holds: d_x = y_x + 1.

The second value of the d_x pairs, g_x, is always determined from the previous read operation involving a d_x value—i.e., d_x−1—using the first three bytes of the a bytes to be read. The first g_x value, g₁, is part of the four parameters (see above).

4.

In this version, Version 1 is applied for up to ${\displaystyle \frac{p^2-p}{64}}$ read operations, after which Version 3 is used. Since identical d_x values must be ignored, Version 3 must now also check whether the new d_x value has not already been used in Version 1. Version 4 has the advantages that all (p² − p) read operations are possible and that all d_x values up to ${\displaystyle \frac{p^2-p}{64}}$ read operations are non-deterministic random numbers. Therefore, Version 4 is recommended. Up to $ec= {\displaystyle \frac{p}{a}}$, it provides only non-deterministic key bits as input for the HKDF; up to $ec= {\displaystyle \frac{p^2-p}{64}}$, all d_x are still non-deterministic; and thereafter—which will rarely occur in practice, because p is usually large enough—all d_x are deterministic due to the congruence generator. In other words, Version 3 serves only as a supplement for particularly large key requirements.

3.8. Implementation Notes

In practice, OTPH is usually implemented in HSMs (Hardware Security Modules). For this, the HSM must contain very fast memory for the KeyInput, as OTPH always treats the input as a whole. This requires at least 512 Kbit (with p $>{10}^6$ bit), since at least two versions must be available, which is not a problem for most HSMs on the market. However, the second version can also be stored on fast permanent storage, such as an SSD. This is the most important requirement for the implementation.

If the KeyInput is changed prematurely—that is, before the entire KeyXOR key has been processed—this must be synchronized in telecommunications. The required confidentiality of the key, the synchronization of the key change, etc., are necessary for all encryption methods and are not specific to OTPH; therefore, they are not addressed here (see [12,13,14]).

OTPH is also suitable for data storage on PCs, where data encryption is performed using the OTP. Temporary files, which, for example, are constantly generated by Office (e.g., every 10 min), require a large amount of key material when dealing with large files. The OTPH can limit the amount of key material used for temporary files, thereby solving this problem. These files are stored only internally on the PC and therefore do not require the highest level of security. The situation is different for data that leaves the PC and is therefore encrypted with the OTP (see in [3] Chapters 5 and 7).

The author implemented OTPH on a laptop, using NixOS as the base operating system and running multiple VMs on top of it, where the applications run. This allows the entire KeyInput and all processing to be highly securely protected within NixOS, and all data destined for permanent memory and for telecommunications with OTPH to be securely encrypted [3]. Laptops have sufficient main memory and permanent memory for an OTPH implementation.

Book [3], which is the result of a multi-year project, describes and compares QKD, RKD, and MKD in great detail. It also covers postprocessing and many other interesting topics in this field and also implementations of encryption.

4. OTPH Cryptanalysis

4.1. Formalization

Given the following:

• A secret key KeyInput of length p $>{10}^6$ bits.
• p is a prime number.
• KeyInput is treated as a cyclic buffer.
• For each read operation in the first processing step, a bits are read from KeyInput, and the result is a Masterkey for the HKDF of length a bits.
• After g_x read operations, the read interval d_x is changed by incrementing x by one.
• g_x and d_x exist for all $1\le \mathrm{x}\le \mathrm{y}$ and are non-deterministic random numbers, i.e., there are y different g_x and d_x, and the maximum value of y is (p − 1).
• ec (encryption counter) starts at ec = 1 and is incremented by one after each read operation of a bits. The maximum value of ec is ${\displaystyle {\sum }_{x=1}^y}{g}_x$
• A KeyXOR_ec with the length ol (output length) is derived from the Masterkey of length a bits with the function (see Section 3.4).
• All KeyXOR_ec combine to form the KeyXOR, which serves as the XOR keystream for encryption. KeyXOR = KeyXOR₁‖KeyXOR₂‖………‖KeyXOR_ec−1.

The total length of the KeyXOR is calculated as

$$length KeyXOR={\displaystyle \sum _{x=1}^y}{g}_x\times ol$$

Security depends primarily on whether the generated bit sequence KeyXOR is indistinguishable from a truly random sequence to an attacker and whether the same keystream KeyXOR_ec is never used twice.

4.2. Properties and Security Analysis

• Very high key entropy:

The non-deterministic key KeyInput > 1 Mbit possesses enormous entropy (called InputEntropy in this paper). Even if an attacker knows the complete algorithm, they would theoretically have to reconstruct a state with more than one million unknown bits.

2.

Prime number length of KeyInput:

The prime number length of the key KeyInput prevents certain periodic structures. If the number p is prime and $\mathrm{g}\mathrm{c}\mathrm{d}(d_x,p)=1$, the sequence $i,\hspace{0.25em}i+d_x,\hspace{0.25em}i+2d_x,\dots$ passes through all positions of the ring before it repeats. This prevents short cycles from forming.

3.

Key Reuse:

As with CTR mode, ChaCha20, etc., care must be taken with OTPH to ensure that the same KeyXOR, or parts of KeyXOR, is not used twice for encryption [14]. This risk cannot occur with proper use because the KeyXOR is very long and QKD and RKD constantly supply new key material.

4.

Critical Issue “Overlap Between Masterkeys”:

Here, the parameter k = rounded down (p/a) plays an important role. The value k specifies how many consecutive Masterkeys within a common d_x contain no common subsets; i.e., how many are formed exclusively from different bits of the nondeterministic KeyInput. The individual Masterkeys from different d_x generally contain no common subsets. Only the groups of k Masterkeys each within the same d_x contain common subsets when considered relative to one another. Therefore, these groups are processed in the HKDF with a different Salt of length a.

5.

MinEntropy:

The entropy of the KeyInput is based on its length p. However, a long non-deterministic random number is usually not perfect, and therefore neither is its entropy, which is specified as InputEntropy.

The following applies: MinEntropy = $InputEntropie\times k\times a÷p$ which—due to the rounding of k = p/a—is slightly less than InputEntropy.

The total MinEntropy across all Masterkeys is $InputEntropie\times k\times a÷p$. If the KeyXOR must be larger for given values of d_x and g_x, the number of T_i in the HKDF must be increased; i.e., ol (output length) must be increased. The HKDF handles this very well (see [5,6]). According to the HKDF standard [6], the number of T_i must not exceed 255.

As the HKDF can only extract entropy but not generate it, large values of g_x and the number of T_i do not result in any entropy gain. The HKDF conserves the existing MinEntropy and distributes it optimally. The HKDF allows this entropy of the KeyInput to be preserved as effectively as possible and enables the calculation of a very good deterministic key, KeyXOR, from the Masterkeys.

6.

Security Analysis of the HKDF:

The security analysis in [5,6], considering the current state of knowledge and well established techniques within the cryptography community, is directly applicable as a security analysis for OTPH. It is therefore not discussed in detail in this publication. In [5,6], the following sections are of interest for cryptanalysis: 2, “Statistical and Computational Extractors; 3, “Formalizing Key Derivation Functions,” which provides formal security definitions for KDFs; 5, “Random Oracles as Computational Extractors,” which covers the theoretical foundations of entropy extraction; 6, “The Security of HKDF,” which contains the actual security proof for HKDF; and 7, “The Key-Expansion Module,” which provides a separate analysis of the expand step. The central part of the cryptanalysis in [5] is thus Section 6. In Chapter 2 Krawczyk describes the significance of min-entropy (MinEntropy) and the extractor. The security analysis is explicitly based on the input source having sufficient MinEntropy. The Masterkey does not need to be randomly distributed, but it must contain sufficient uncertainty (MinEntropy). With a secret Salt—as was also briefly mentioned in [5]—the situation becomes even more difficult for the attacker in practice. The attacker would now have to guess or reconstruct not only the Masterkey (with length a, usually 512 bits) but also the Salt (e.g., 512 bits, depending on the hash algorithm). The HKDF does not generate any additional entropy, but with good parameterization, it also loses virtually no cryptographically usable entropy. In Chapter 3 of [5], where the security of a KDF is formally defined, the security formalism is based on the assumption that the Masterkey possesses a certain amount of entropy (referred to as MinEntropy). Chapter 5 then shows that, given a source with MinEntropy (in the case of OTPH the Masterkeys) the extractor can generate a nearly uniformly distributed key from it (in the case of OTPH the KeyXOR).

In OTPH, an arbitrary amount of key material for KeyXOR_ec is generated from a good Masterkey_ec in the HKDF. The claim “If HMAC is secure as a deterministic random number generator, then the generated output blocks are deterministic” is a classic reduction proof, which is a formal proof.

This means that references [5,6] do not directly show that the HKDF is secure, but rather, that “If someone can break the HKDF, they could also use it to break HMAC or the underlying hash function.” This traces the security back to better-studied primitives, which is particularly valuable because the security of OTPH does not rely on new, untested assumptions but, rather, on a construction that has already been extensively studied.

The analysis of the Extract function shows that “if the input material is not uniformly distributed but possesses sufficient MinEntropy, and if the attacker knows parts of the source, then HMAC can still derive a nearly random PRK from it.”

For the Expand function, the cryptanalysis in [5,6] shows that the individual outputs (KeyXOR_ec) remain deterministic random numbers even if other KeyXOR_ec values become known. This is important because longer plaintext segments may be identical.

Of course, the HKDF does not generate non-deterministic random numbers, which [5,6] do not prove either. References [5,6] demonstrate computational security based on assumptions about the HMAC, partly in the random oracle model and partly under PRF assumptions (pseudo-random function of HMAC) for HMAC. This is the standard type of proof for modern KDFs.

The key findings of the cryptanalysis in [5,6] are as follows:

• HKDF-Extract can generate a deterministic random number from entropy-rich but non-uniformly distributed material. In the case of OTPH, this material consists of the Masterkeys with a MinEntropy of $InputEntropie\times k\times a÷p$.
• HKDF-Expand generates deterministic KeyXOR_ec from this random number for subsequent XOR encryption.
• The security is attributed to formal reduction proofs regarding the extraction and PRF properties of HMAC.

With regard to the first processing step in OTPH, this means that if all Masterkeys in a sequence are different, but shorter or longer parts of them are the same, this has no effect on the KeyXOR_ec. The entropy across all Masterkeys remains the same; that is, it cannot be improved by increasing g_x or the number of T_i.

Greater similarities in the Masterkeys due to common subsets lead, via the avalanche effect, to a random change in KeyXOR, such that no practically usable correlation is detectable between different Masterkeys. Formally, this is justified by the PRF property of HMAC; namely, different inputs produce different outputs that are indistinguishable from independent random values.

The Salt does not make the key more random; rather, it makes the extraction of the already present entropy more robust and easier to analyze. This is precisely why [5,6] attribute significantly greater importance to the Salt than many older KDF constructions. In OTPH, the hash value of a portion of the KeyInput is used as the Salt. The random Salt destroys equal subsets in Masterkeys. The secret and random Salt helps convert the existing entropy more cleanly into a cryptographic key and provides an additional safety margin against errors in the key’s entropy estimation. To this end, the Salt is also changed for k Masterkeys, because any set of k Masterkeys never contains any common subsets.

The points below therefore follow from [5,6]:

• Common subsets in the various Masterkeys in the HKDF do not lead to similar outputs. The different values of the Salt further support this.
• Due to the avalanche effect of HMAC and the different Salts, the outputs appear practically independent.
• It is not the visual similarity of the Masterkeys that is decisive, but their remaining MinEntropy.

Krawczyk’s analysis shows that the HKDF “extract-then-expand” approach is a formally well-founded method for deriving cryptographically strong and mutually independent keys (in OTPH, the KeyXOR) from non-ideal key material (in OTPH, the Masterkeys). The security can be attributed to the proven properties of HMAC, by which in OTPH, the Salt that changes after k Masterkeys further improves robustness.

7.

XOR Encryption:

The requirements for a one-time pad to be provably 100% secure from an information theory standpoint are as follows [11]:

• The key must be completely random, i.e., generated by a non-deterministic random number generator.
• The key must be at least as long as the unencrypted data.
• New key bits must be used for each new encryption; that is, the key—or any part of it—must never be reused.

Of these three OTP conditions, the first—that the key must be completely random—can no longer be fully met with OTPH.

The third processing step is intended to function as a restricted one-time pad using XOR encryption. Historically speaking, an OTP does not require a non-deterministic random number. During the heyday of the OTP (i.e., between 1920 and the 1960s), the key was often deterministic due to a lack of suitable random number generators. Naturally, in such cases, the OTP is not absolutely secure from an information-theoretic perspective.

5. Conclusions

In practice, QKD and RKD are becoming increasingly important for the highly secure generation and distribution of cryptographic keys—and, consequently, for encryption methods that are optimally adapted to QKD and RKD. This article presents a new symmetric encryption scheme that was developed specifically for these two methods and their requirements. OTPH adapts precisely to their existing key material and can incorporate the extremely high available entropy into the encryption process.

OTPH is a one-way function that cannot be reversed. Only the KeyXOR used for XOR encryption can be determined from the initial key, KeyInput. The security analysis shows that processing step 1 for the Masterkeys guarantees a MinEntropy of $InputEntropie\times k\times a÷p$, which is very important for the security analysis of the second processing step, the HKDF. This analysis, presented in [5,6], demonstrates that the HKDF is a formally justified method for deriving cryptographically strong and mutually independent keys from non-ideal key material. The security can be traced back to the proven properties of HMAC. This is particularly valuable because the security does not rely on new, untested assumptions but, rather, on a construction that has already been extensively studied.

A new cryptographic method such as OTPH—especially given its novel design—must first be established as viable and secure within the cryptographic community; this has been and remains true for all new methods. However, thanks to the cryptanalysis of the HKDF [5,6], OTPH is well positioned to succeed.

In practice, OTPH is not expected to compete with conventional symmetric encryption algorithms such as AES or ChaCha20 but, instead, will be used primarily in the context of QKD and RKD, and possibly also MKD (key exchange via highly secure storage media).