Revisiting and Improving Algorithms for the 3XOR Problem

Abstract

The 3SUM problem is a well-known problem in computer science and many geometric problems have been reduced to it. We study the 3XOR variant which is more cryptologically relevant. In this problem, the attacker is given black-box access to three random functions F,G and H and she has to find three inputs x, y and z such that F(x) ⊕ G(y) ⊕ H(z) = 0. The 3XOR problem is a difficult case of the more-general k-list birthday problem. Wagner’s celebrated k-list birthday algorithm, and the ones inspired by it, work by querying the functions more than strictly necessary from an information-theoretic point of view. This gives some leeway to target a solution of a specific form, at the expense of processing a huge amount of data. However, to handle such a huge amount of data can be very difficult in practice. This is why we first restricted our attention to solving the 3XOR problem for which the total number of queries to F, G and H is minimal. If they are n-bit random functions, it is possible to solve the problem with roughly

Computational records with aging hardware: Controlling half the output of SHA-256

“…Joux proposed an incremental improvement in [Jou09], which reduces the computational load by √ n at the expense of using an exponential amount of memory and increasing the number of queries to the random functions. Motivated by the potential cryptanalytic applications, several new algorithms were discovered by Nikolić and Sasaki [NS14] and then later by Bouillaguet, Delaplace and Fouque [BDF18].…”

“…After the three lists had been built, it remained to find the actual 3XOR triplet hidden in A × B × C. The lists have size 2 n /3 with n = 96, therefore using the quadratic algorithm would yield a solution with 2 64 probes in a hash table. In practice, we used the slightly improved algorithm of [BDF18].…”

“…Therefore, the cost of building the lists is essentially 2 Z N = 2 42.7+2Z/3 . Finding all 3XOR triplets in these lists using the quadratic algorithm or the improved algorithm from [BDF18] takes time N 2 = 2 85.3−2Z/3 . Balancing the cost of the two phases suggests to use Z = 32, which is, in any case, the minimum value for which bitcoin mining devices are efficient.…”

“…We considered implementing a distributed version of the algorithm of [BDF18], but we believed that this would have been impractical because of the communication complexity that this would have generated.…”

“…As such, the actual 3XOR subproblems we need to solve are the following: three input arrays of size 2 17 each containing 64bit random values. We used a specially tuned implementation of the algorithm of [BDF18], which requires frequent access to two of the three arrays. Each array requires 1MB, and with 16 cores on a PowerPC A2 CPUs each running an independent copy of the algorithm, the 32MB of L2 cache are enough to hold all the frequently accessed data.…”