Revealing Encryption for Partial Ordering

Abstract

We generalize the cryptographic notion of Order Revealing Encryption (ORE) to arbitrary functions and we present a construction that allows to determine the (partial) ordering of two vectors i.e., given $E(\varvec{x})$ and $E(\varvec{y})$ it is possible to learn whether $\varvec{x}=\varvec{y}$, $\varvec{x}>\varvec{y}$, $\varvec{x}<\varvec{y}$ or whether $\varvec{x}$ and $\varvec{y}$ are incomparable. This is the first non-trivial example of a Revealing Encryption (RE) scheme with output larger than one bit, and which does not rely on cryptographic obfuscation or multilinear maps.

Work done while visiting Aarhus University.

Appendices

Appendices

A Efficiency of PORE

In this section we analyze the efficiency of our PORE construction.

1.1 A.1 Theoretical Efficiency

Let $\kappa$ be the security parameter, d the number of dimensions and n the bit length of each entry. Then we can compute the storage and computational complexity of our scheme.

Storage Complexity. The bit length of a ciphertext in our PORE scheme is exactly:

$$ 1.6(n+1)^d + nd = O(n^d) $$

Computational Overhead. Performing an encryption requires

$$ 2(n+1)^d + nd=O(n^d) $$

calls to a PRF (with unbounded domain). Note that running the evaluation algorithm requires no invocation of the PRF (only d binary searches into vectors of n bits each and a single addition modulo 3).

1.2 A.2 Implementation Choices

In this section we describe the result of our experimental validation of the efficiency of our PORE scheme.

Plaintext Space. We have implemented our scheme for a range of parameters d and n. We report here the results for all combinations (d, n) with $d\in \{2,\ldots ,8\}$ and $n=2^i$ for $i \in \{1,\ldots ,13\}$ s.t. the ciphertext size is less than 20 MB.

PRF Choice. We implement the PRF $F: {\{0,1\}^\kappa }\times \{0,1\}^* \rightarrow {\{0,1\}^\kappa }$ using AES-CBC mode, with key size $\kappa =128$ bits. This is a particularly convenient choice thanks to the AES native instruction in modern CPUs.

Note that in the theoretical analysis we stated that the complexity of the encryption is $O(n^d)$ when measured as the number of calls to a PRF with unbounded domain. However in practice, when instantiating F with AES in CBC mode the running time (in terms of number of calls to AES) grows linearly with the number of blocks needed for the plaintext, namely $\lceil dn/128 \rceil$. Therefore, a naïve implementation would be significantly slower than promised. We notice, however, that thanks to the special structure of the inputs of our PRF it is possible to get rid of this extra factor. In particular, we note that in our matrix of ciphertexts we evaluate the PRF on inputs of the form

$$ F_K({\mathsf {prefix}}(x_{\varvec{1}},i_1),\ldots ,{\mathsf {prefix}}(x_{\varvec{d}},i_d)) $$

where each value ${\mathsf {prefix}}(x_{\varvec{k}},i_k)$ is given as input to n different PRFs. Therefore we modify the way we evaluate the PRF by first precomputing

$$ u_{k,i}= F_K^k({\mathsf {prefix}}(x_{\varvec{k}},i)) \forall k\in [d],i \in [n] $$

and then implement

$$\begin{aligned} F_K({\mathsf {prefix}}(x_{\varvec{1}},i_1),\ldots ,{\mathsf {prefix}}(x_{\varvec{d}},i_d)) = F^0_K(u_{1,i_1}\oplus \cdots \oplus u_{d,i_d}) \end{aligned}$$

so that the inputs to $F^0_K$ is of fixed length 128. Therefore (even adding the $O(n^2d)$ extra AES invocations on “long” n-bit values used to precompute the u’s), the total number of calls to AES and hence the running time is $O(n^d)$ as initially promised.

Note, the XOR operation over d strings takes O(d) time. However, the points which are in the same position in the first k dimensions shares the value $u_{1,i_1}\oplus \cdots \oplus u_{k,i_{k}}$. By making these values reusable, we can reduce the amortized complexity to $\sum _{i=1}^d\frac{1}{n^{i-1}}=O(1)$.

Table 1. Encryption time and standard deviation

Table 2. Evaluation time and standard deviation ($\upmu s$)

Table 3. The size of a ciphertext

1.3 A.3 Experimental Setup

The reported encryption timings (Table 1) are the average taken over 100 executions of the encryption algorithm. For the evaluation timings (Table 2), we randomly pick 500 pairs from the 100 ciphertexts and take the average of the 500 executions of the evaluation algorithm. To measure the size of the ciphertexts (Table 3), we keep track of the size of the required space each time the encryption algorithm applies the memory.

Hardware. The experiments were executed on a machine with the following characteristics:

• OS: Linux TitanX1 3.19.0-15-generic #15-Ubuntu SMP

• CPU: Intel(R) Xeon(R) CPU E5-2675 v3    1.80 GHz

• Memory: 128 GB

• GCC: gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13) (Compile option -O2)

1.4 A.4 Results

Encryption Complexity. Table 1 shows how long it takes to encrypt a single plaintext for different values of d and n. As expected, we observe that the encryption time grows as the dimension d and bit lengths n increases.

Evaluation Complexity. Note that the theoretically complexity of the evaluation algorithm is O(d). However, the actual running time of the evaluation algorithm from Table 2 indicates that the algorithm is so fast that for most choices of parameters it is hard to appreciate the theoretical complexity.

When the combined size of all 100 ciphertext from the experiments does not exceed 6MB (i.e. each ciphertext does not exceed 60 kB), then all ciphertexts fits inside the L2 cache of the CPU. By observing the variation of the evaluation timings in Table 2 and the ciphertext size in Table 3, we can conclude that there is a tendency that when the ciphertexts fits inside the L2 cache, then the variation stays below 0.07 $\upmu$s (this observation is indicated in the tables by splitting the columns in two).