# decrypt numbers multiplied by a certain floating point number

A friend has about 10K numbers in a an excel sheet. He wanted to encrypt these numbers in order to share the file with a 3rd party that will help him reorganize the tables. What he did, to hide the numbers, is to multiply all the numbers by a floating point number.

Based on my limited knowledge of encryption I argued that this method seems fairly weak (compared to other methods of encryption). My question is - Am I right in my argument or is it really difficult to decipher this sort of encryption.

• Presuming that the description of the articles is unique, you could use the article description and hash it to create a nonce. Then use the hash as input for a KDF, and use the resulting derived key for a format preserving encryption scheme of sorts. Just an idea... – Maarten Bodewes Feb 26 '15 at 1:52

There is a line between encryption and obfuscation, I would say this is on the latter side.

If someone knows the method, and is able to correctly guess even 1 of the original values, simple math will reveal all the original values. Additionally, depending on the type of data in the field, guessing the floating point number may only take seconds even with no 'plaintext' guess, and you have thousands of values to test it on.

Most encryption is based on some kind of permutation and is reversible, floating point values have a maximum level of precision, and can cause the original value to be lost in some cases. Rounding may be able to recover them, but if the original values also have a certain level of precision, there may be no way to recover them, assuming you are not recovering from a backup, but rather trying to decode in Excel.

Examples
Here is an example of an information disclosure that recovers the key.

Say 2 of the encoded values are $388874698.219672$ and $293536403.581274$. If a strong assumption can be made by the table format or header names that these are relatively small integers, say dollar values, you can multiply the ratio by successive values until you find another value with the same relative rounding error. Lets assume they are prices under $1000:$R = 388874698.219672/ 293536403.581274R = 1.32479206488609$Multiply$R\$ by an incrementing integer counter and round to 6 decimal places till we get an integer. We can even implement the attack in Excel and visually compare, say on the victim's laptop. Extend the following down 100000 rows:

A1 = ROUND(ROW(A1)*1.32479206488609,6)

Then page down till you see an integer. We run into one at row 19357, with a value of 25644. It can be reasonably assumed these translate to 193.57 and 256.44. A little bit of math recovers the 'key' used hide them, which will probably have rounding errors. Testing this against more values and averaging out some more guesses will narrow down which digits of the key are significant and verify if it is correct. An automated attack will take a fraction of a second, even with much larger values.

Since the ratio of values is preserved when using multiplication, guesses can be made about the nature of the data, and information can be exposed even without knowing the real value. mikeazo's example regarding salary information will expose if someone makes more or less, and by what percentage that difference is.

• Thanks for the answer, very interesting. The dataset is a price list btw. I was thinking of checking the spreadsheet for some functions that could reveal correlations between the different columns (ex. net/gross price etc.) PS. My friend mentioned that he copy/pasted the numbers without functions, yet something might come up by comparing the values. – Ando Feb 26 '15 at 1:12
• I am adding an example attack on a price list – Richie Frame Feb 26 '15 at 1:37

In addition to what Richie has noted, here are some problems with the encryption method that you normally don't like to see in encryption.

It preserves order (if a > b, then E(a) > E(b)). So, say the cells encode salary information. Even if it doesn't reveal the salary, it still reveals a lot of information.

It is not semantically secure. In other words, I can tell if two cells encrypt the same value.

From the information we can describe the encryption algorithm as follows. Given a floating point number (m) and there is some number (nx) where m * nx = kx.

kx is the encrypted number where x is some position in the list of 10,000 numbers.

So know that nx is going to be some realistic data. In this case you pointed out it was a money value. Money values are probably very common in different data today. Then we can assume nx is some number with two decimal places from .00 to 999999999.99, or bigger if we need.

Let's just consider the first two encrypted numbers for now, n1 and n2.

If n1 is .01, then m = k1,/.01

Then if in n2 we would know n2 = (k2)/(k1,/.01)

If n2 is an expected value like 100.05, because it only has at most two decimals, we may have found they key m. If n2 is an obvious bogus number like 1515.14041, we know that is not an expected value and throw it out and .01 was not n1. If we get a nice number such as 100.05, we can calculate m and plug it in and solve for other values of nx and based of the results come to a conclusion that we have found the original values.

If .01 didn't work, the number would increase to .02 and then for as long as you would want.

Then number of times needed to do this is probably going to be small and may be done in a small or reasonable amount of time.