# X-MAS CTF 2019 - Hashed Presents v1 & v2 Writeup

These two challenges were almost the same, so I’m doing the writeup together. In reality the first one was a lot more solved since it has an unintended vulnerability using the fact that the step value was an even number, but since the indended solution is necessary to solve the v2 we’ll ignore this.

## Hashed Presents v1 (25 solves)

We have to generate 10 collisions to a custom hash function that works like this

So basically we have that given a string where the ’s are digits (in their decimal representation) the hash function computes where is the step value in the code and is the hash value. The idea here is pretty simple: we want to find some such that there exists a string such that and such that the are small enough to keep a valid character. If we do this, we’ll have that and so we’ll have a collision string made by the string . So, how we can construct this vector? The easiest method (or, at least, the standard one) as far as i know is using the Lenstra-Lenstra-Lovász lattice basis reduction algorithm. I don’t want to go into the details of the algorithm (since it’s pointless here and it’s already implemented in Sagemath), but basically given a basis of a lattice in the algorithm gives you another basis that is short and nearly orthogonal in polynomial time. So, everything we need to do is to setup a basis for our lattice and then apply LLL. I choose the easiest base and setup the matrix in the following way

where (since the length of the given strings varies from 30 to 35) and is a parameter that we can let vary over the integers. So we generate some vectors like this from this matrix and we’re done, eventually trying to sum up the ’s with different values of the ’s in order to match some.

## Hashed Presents v2 (8 solves)

The problem here is quite similar, the only differences are: now the step is an odd number, and that there is a xor instead of an addition in the update function

So, what’s changes with the xor? From the theoretical point of view, almost nothing. In fact we can reconduct the first problem to the second one very easily: suppose that we have a collision for the first cipher and , then calling the value of after the th addition in the update function (i.e. when we are processing the th character), then since we can easily find a vector such that and do the same with and , obtaining a collision for the second hash function. So our strategy will be:

• Finding a string that matches the hash of the given string but for the other hash function
• Finding a collision on the first hash function
• Retrieving the collision for the second hash function using the collision on the first one
So that’s the end, right? No.

The problem here is that this method in general generates a collision, but we’ve no control on the size of the components of this collision (and, in general, we’ll have something that is 400+ and so not an ascii character).

What we need to do is to make the collision of the first hash as small as possible. We don’t care about it being positive, but we need to find a vector that is as close as possible to 0. So in practice we want to solve a Close Vector Problem in the lattice generated by our LLL vectors, and in particular we want to find the closest vector to (the vector we generated on the first point of our strategy). Since CVP is NP-Hard we’re going to approximate it. As far as I know the best way to do this is Babai’s algorithm, that is a polynomial time algorithm that works like this (in sage):

where B is a basis of the chosen lattice. So now that we have a small collision for the first problem we can simply generate the collision for the second one and solve the problem.