4

I want to represent a hash function in z3, something like SHA(x). After doing some research, it appears z3 doesn't support injectivity very well, so I can't have a constraint like (and while I realise this isn't strictly speaking true because of collisions, as a heuristic it would be useful for my project)

forall([x, y],Implies(SHA(x)==SHA(y), x==y))

and expect the solver to terminate.

My question is, are there any known best practice workarounds for this problem? For instance, if I added a Implies(SHA(x)==SHA(y), x==y) constraint for every pair of x and y without using a quantifier, would this solve the problem?

dirtyfilthy
  • 53
  • 3

1 Answers1

4

For uninterpreted functions we use encodings of the form:

Forall([x], inverse_f(f(x)) = x)

so when f is injective, we can introduce a function that realizes the partial inverse on the range of f. The quantified axiom with pairs of equalities is so common that Z3 looks for them and adds the above axiom instead. It gets instantiated for every occurrence of f. Of course, for SHA, which is typically encoded using bit-vectors, introducing an uninterpreted function means that Z3 doesn't use the pure SAT solver. It would in the best case revert to Ackerman encoding, that just re-introduces the original pair-wise encoding.

Nikolaj Bjorner
  • 8,229
  • 14
  • 15
  • Using the partial inverse I still have exactly the same problem of using the naive approach of Implies(f(x)==f(y), x==y), namely that the solver can't find a solution to simple problems. For example: `import z3 a=z3.BitVec('a', 32) b=z3.BitVec('b', 32) x=z3.BitVec('x', 32) hash=z3.Function('hash', z3.BitVecSort(32), z3.BitVecSort(32)) hash_inv=z3.Function('hash', z3.BitVecSort(32), z3.BitVecSort(32)) hash_pred=z3.ForAll([x], hash_inv(hash(x)) == x) s=z3.Solver() z3.set_param(verbose=10)s.add(hash_pred) s.add(hash(a)!=hash(b)) s.add(a!=b) s.check()` – dirtyfilthy Sep 27 '17 at 10:42