2

Many moons ago, I was working with a team that was building a public-facing website. We originally built the system using auto-incrementing numeric primary keys as the public identifier for each piece of content that was collected. Word came down from on high that exposing this number was a risk -- it would reveal how many objects the system held, and the delta between any two object IDs and their post dates would reveal growth/adoption rate.

A senior colleague declared that using an XOR cipher would solve this problem. We'd take the object IDs as we always did and XOR them with a closely-guarded numeric key to create a public identifier. We'd reverse the process to get our original number.

In our case, the private IDs and the key were both unsigned 32-bit integers. And, as you might expect, two items created close to one another showed changes in their least significant bits, but no change in the most significant bits. I thought at the time that it would be trivially easy for an adversary to post a few objects in succession, notice that the LSBs changed while the MSBs remained static, and conclude that we were simply XORing an incrementing integer. But I always wondered what it would take for them to derive the key, and tear the whole facade down.

Is it possible, if an attacker can reason that the plaintext is a monotonically increasing integer, to derive the whole key?

smitelli
  • 2,085
  • 3
  • 17
  • 19
  • 1
    Your "key" is 32 bits. You don't need clever tricks when the key can be trivially bruteforced. –  Jul 31 '15 at 15:15
  • @TerryChia Well, my understanding was that to successfully bruteforce, you'd need some way of telling when the correct key had been chosen. With this scheme, I could envision there being many possible keys that would decode "close enough" to the original value, but still be a few bits off. Especially the MSB side, as the attacker wouldn't necessarily know the absolute range of the private IDs. – smitelli Jul 31 '15 at 15:17
  • @smitelli If you're auto incrementing the ID, I would wait until I found two IDs that were one up from each other. Once the decoding gives me the result of 0x1234 and 0x1235, I have the key. – RoraΖ Jul 31 '15 at 15:21
  • As raz said, if the keys ALWAYS increase, you have a very easy means to detect if you have the right key. Even if you're not guaranteed to get the next key in order, just get 100 sequentially. If when you decode these IDs they all increase sequentially, you've found the right key. This is just one way, there's many ways to test if you have the correct key. – Steve Sether Jul 31 '15 at 15:31
  • @raz But the absolute range is not known. You could find a key that decodes to 0x00001234 and 0x00001235, and a different key that decodes to 0xFFFF1234 and 0xFFFF1235... Which one do you know is right? – smitelli Jul 31 '15 at 15:36
  • @smitelli In that specific case, the right one is the key that decodes two other sequentially gotten keys. You can keep doing that until whatever statistical measure satisfies you that it's not just a chance that you picked a false positive key. – Steve Sether Jul 31 '15 at 15:48
  • If the attacker can find "some really old object", with a lot of 0's at the start of its internal number, then that reveals a lot of bits at the start of the key. Seriously, just use random identifiers. – user253751 Aug 01 '15 at 04:39

2 Answers2

1

A clever attacker can probably find some information about the rate at which new content is being created.

Since you're always XORing the primary keys with the same secret key, you'll always see a bit flip in the ciphertext at the same time that it flips in the plaintext. This means that you can tell when the primary key rolls over to a larger number, such as here:

01111111 10000000

or, when ciphered with 11100010 as a key:

10011101 01100010

This leaks some information about the growth rate, especially if the attacker is capable of generating content at will.

...of course, if each ID corresponds to a piece of content, then can't the attacker just look at how many there is?

To get back to your original question, though, there shouldn't be a trivial way to find the key, as long as you never leak any private ID values. If an attacker gets a piece of plaintext and the corresponding ciphertext, you're hosed:

A XOR K XOR A = K

etherealflux
  • 780
  • 4
  • 12
1

As you point out in your question, an astute attacker may realize that your primary keys (i.e. the plaintext) are sequentially increasing numeric values, and that XOR encryption is being used, because the LSB's of the encrypted text are changing while the MSB's remain static.

At that point, it's game over. XOR encryption can be broken easily, as Bruce Schneier explains in 'Applied Cryptography'. See https://stackoverflow.com/questions/1135186/whats-wrong-with-xor-encryption for further information.

Community
  • 1
mti2935
  • 23,468
  • 2
  • 53
  • 73
  • This's a serious issue if the public key starts out at zero. Many of the high bits will be instantly revealed if that's the case, since you'll be XORing the key with a bunch of leading zeroes! – etherealflux Aug 01 '15 at 01:04
  • Breaking XOR encryption depends on knowledge about the plaintext. If you know nothing about the plaintext then you cannot even break XOR encryption simply because you have no way of determining whether the XOR key you think you found is correct. In the present case, the knowledge that it is a monotonic increasing binary number lets you determine quickly the least significant bits, but not the most significant ones as long as they don't flip. – Tilman Schmidt Aug 01 '15 at 02:30
  • See the answer by GeneQ in the link that I posted above. Breaking XOR encryption using this method yields the plaintext without solving for the key - the attacker only needs to find the key length. If the attacker has several encrypted samples, he can run the process in parallel with each of the samples, varying the key length, until he finds numeric plaintext values that differ only by small intervals. – mti2935 Aug 01 '15 at 12:48