1

I'm taking a quantum computing course in which, for our final project, we must create a proof-of-concept implementation of Grover Search for finding hash collisions up to a difficulty (similar to blockchain).

I need a (relatively) simple hash function. As this will be running on a quantum simulator, I'm limited in the number of qubits which I can simulate. Ideally, the hash function should output 8-bits for arbitrarily sized input, should not be crackable (trivially, for example by hand), and should be relatively fast as the hash function (although classical) will be implemented with quantum logic gates.

I was considering an 8-bit version of SHA-1, however I'm not sure how adaptable SHA-1 would be in this situation.

Squeamish Ossifrage
  • 49,816
  • 3
  • 122
  • 230
DontTurnAround
  • 113
  • 1
  • 5

2 Answers2

2

I suggest a derivative of the Pearson Hash. It can be implemented in two forms, using separate and independent random permutation tables as:-

  1. h1 = T1[h1 ^ x[i]] , h2 = T2[h2 ^ x[i]] and then finally h = h1 ^ h2,
  2. h = T1[h ^ x[i]] followed immediately by h = T2[h ^ x[i]] so effectively you run one lookup table into the other,

where h is the final 8 bit output. The latter form seems cooler and simpler. Construct the tables T1 and T2 any way you can think of. Both methods result in good uniform output distribution with the expected $ 1 \over e $ rate of collisions. It's well proven, not trivially crackable and extremely simple if you can spare the requisite 512 bytes for the two tables.

Note. As pointed out in the comments, free qubits may be scarce. Might it be possible to ignore the storage requirements for the hash algorithm itself? If the experiment is for "Grover Search for finding hash collisions", you're primarily looking at techniques for breaking the hash not making it. Therefore I would be minded to exclude any storage requirement for making the hashes from the total simulated qubit count. Only you can decide if this is an appropriate compromise.

Paul Uszak
  • 15,905
  • 2
  • 32
  • 83
2

Your requirement that it not be trivially crackable is already violated by the premise of an 8-bit hash function: for a uniform random 8-bit function it takes an expected 128 trials to find a preimage, and the time for an expected ${\sim}256/n^3$ trials to find the first preimage among $n$ targets if parallelized $n^2$ ways. But maybe you meant there are no better-than-generic attacks on it. (Similarly, it takes an expected ~20 trials to find a collision, although it's not clear that collisions are relevant to your application.)

You could use a Keccak sponge with 1-bit words for a total 25-bit state, 12 rounds, and an 8-bit capacity. I don't know 25-bit Keccak admits better-than-generic attacks—I wouldn't be surprised if it did—but it is structurally the same as the Keccak permutation used in SHA-3, with 64-bit words, 1600-bit state, 24 rounds, and either $4\lambda$- or $2\lambda$-bit capacity (respectively, for the fixed-size hashes like SHA3-256, or for the extendable-output functions like SHAKE128) for $\lambda$-bit collision resistance and $2\lambda$-bit preimage resistance.

Right now, the best collision attacks on 1600-bit Keccak[1][2] seem to be limited to 6 rounds, which justified the use of 12 rounds for KangarooTwelve. There are newer attacks on other aspects of Keccak, but 12 seems like a reasonable margin—and it's not clear that those attacks would be cheaper than Grover. If all you want is preimage resistance, a $\lambda$-bit capacity should suffice for $\lambda$-bit preimage resistance.

One nice thing about a permutation-based sponge like Keccak is that the fixed permutation is, well, a permutation, so it will require no ancillary qubits to implement; the only need for ancillary qubits will arise from xoring the message into the state to hash it.

Squeamish Ossifrage
  • 49,816
  • 3
  • 122
  • 230