## 2 CRP Mechanism Based on Digital Files
### Response Generation with File-Based CRP Mechanism  
The input data of the CRP mechanism is derived from file F. Its ciphertext C is concatenated with nonce \(\omega\) to generate a file C* of constant length \(d=2^{D}\), where D is the number of digits (for example, if a desired \(d=1\) million, then \(D=20\)). The resulting d bits are located at addresses varying from 1 to d. Changing a single bit in file F results in a totally different stream C*. This can be performed with a variety of methods; one possible implementation is the following:  
* [noitemsep,topsep=0 pt]
* Encrypt F with private key Sk, and a PQC scheme (PQC and DSA) under standardization by NIST [32] such as the Cryptographic Suite for Algebraic Lattices (CRYSTALS)-Kyber [33; 34], CRYSTALS-Kyber [35; 36], NTRU [37; 38; 39], Classic McElice [40], SPHINCS [41], and Falcon [42].
* The ciphertext is hashed with Standard Hash Algorithm (SHA)-512.
* The resulting steam is XORed with 512-bit long nonce \(\omega\).
* The function SHA algorithm and Kececack (SHAKE) is used to extend the 512-bit long stream to d-bits. The combination of SHA-3 and SHAKE is NIST-compliant [43; 44; 45].  
The CRP mechanism is based on the d-bit long stream C* to generate N responses from N challenges:  
* [noitemsep,topsep=0 pt]
* _Challenges_: A \"challenge\" is defined as the digital information needed to point at a particular position in the d-bit long stream C*. A stream of bits S* is generated by hashing and extending with eXtended output Function (XoF), creating a randomly selected seed S. The stream S* is segmented into N challenges \(\{q_{1},\ldots,q_{i},\ldots,q_{N}\}\) that are D-bit long. The D bits of each challenges q\({}_{i}\) are converted into number \(x_{i}\), with \(x_{i}\in\{1,d\}\), which is an address in C*, resulting in N addresses \(\{x_{1},\ldots,x_{i},\ldots,x_{N}\}\)
* _Resposes:_ The N addresses generate the P-bit long responses \(\{r_{1},\ldots,r_{i},\ldots,r_{N}\}\). From each address \(x_{i}\), P-bit long responses are generated from C*. The iterative method to find the P positions \(\{x_{i,1},\ldots,x_{i,j},\ldots,x_{i,P}\}\), and read the P-bits is the following:The first position is: \(x_{(i,j=1)}=x_{i}\). The other positions \(x_{(i,j)}\) are given by the linear congruent random number generator, \(i\in\{1,N\}\), \(j\in\{1,P\}\), see Equation (1):  
\[x_{(i,j)}=(\alpha x_{(i,j-1)}+\beta)mod(2^{D});\text{ with }\alpha\text{ and }\beta\text{ prime numbers} \tag{1}\]  
Algorithm 1 and the block diagram shown in Figure 1 summarize the above protocol. The output after response generation is {C, \(\omega\), S} and \(\{r_{1},\ldots,r_{i},\ldots,r_{N}\}\). Such a CRP mechanism is highly secure as three totally independent streams are requested to uncover the responses which are C, \(\omega\), and S. Protecting just one of the three provides acceptable security. The computing power, or \"gas price\", required to run the CRP mechanism is low.  
The probability to point several times to the same position in C* is non-negligeable. This exposes the protocol to a frequency analysis and creates collisions, as several responses \(\text{r}_{\text{i}}\) are then identical. One solution tracks the positions with an index to generate different responses when several challenges are pointing at the same position. For example, when a position is selected a second time, the \(\beta\) of Algorithm 1 step 3.7 can be replaced by \(\beta+1\) which is a sufficient offset to generate a distinct response; iterating, the \(\beta\) is replaced by \(\beta+2\) during the third collision, et cetera.  
Figure 1: Block diagram of a CRP mechanism generating a set of responses. The file F is encrypted and concatenated with a nonce to compute a crypto-file. A seed generates a set of challenges.